De juiste aanpak is om testdata aan te leveren die je nu ziet falen, zodat die in de unit-test erbij gezet kunnen worden. Dan kan danfos op basis van de falende test de regex verbeteren.
01 wordt gematcht en volgens de BAG specificatie is het huisnummer een natuurlijk getal van 1 t/m 99999. Dus voorloopnullen zouden niet voor mogen komen.
Je matcht nu twee toevoegingen van maximaal 4 tekens, is dat correct? Als ik de specificatie lees heb je
huisnummer (numeriek 1-99999)
huisletter (één letter)
huisnummertoevoeging (maximaal vier alfanumerieke tekens)
Dan zou ik zeggen dat het ^1-9([A-Za-z])?([-]{1}[0-9A-Za-z]{1,4})?$ moet zijn.
De koppelstreepjes worden niet genoemd in de BAG specificatie, maar ik ga er ook van uit dat die er moet staan (ook omdat dat de praktijk is).
Maarten, dan maak je vrees ik dezelfde denkfout als danfos in de issue die Ad opent: OSM behandelen als een kopie van de BAG. De BAG limiteert op basis van (sterk verouderde) ontwerpprincipes. Wij hoeven die ontwerpprincipes niet over te nemen, ook al komt 99,9% van de adressen nu regelrecht uit de BAG.
Belangrijk is ook dat valide adressen die niet in de BAG staan en mensen zelf toevoegen geen waarschuwing geven als ze verder gewoon correct zijn volgens Nederlandse conventies. Dat geldt natuurlijk niet voor adressen uit de BAG, maar daar beperkt deze controle zich niet toe.
Het Pekela-voorbeeld is een mooie. Stel dat we de BAG-import voor Nieuwe en Oude Pekela willen repareren om de juiste straatnamen en huisnummers te krijgen? Door een conversie uit te voeren bij deze dorpen bijvoorbeeld. Nu mag C53 niet in de BAG, dus kopiëren wij het systeemdenken van de BAG op exact dezelfde wijze.
Voorbeeld:
Huisnnummer C52 aan de Dominee Sicco Tjadenstraat in Nieuwe Pekela (Google StreetView: hier)
Is in BAG en OSM:
addr:housenumber 52
addr:postcode 9663RC
addr:street Dominee Sicco Tjadenstraat C
De enige reden: ooit heeft het huisnummer in een numeriek databaseveld gestaan, en werd de huisnummertoevoeging los opgeslagen in een alfanumeriek veld. C52 kon niet, dus werd die C maar aan de straatnaam geplakt.
Nu valt die aanpak wel iets te verdedigen, maar het is ook iets wat juist op OSM kunnen herstellen. Dan helpt het als validatietools niet gelijk nee roepen op basis van regels bedoeld voor een striktere context dan alle geldige huisnummers in Nederland.
Met 123–A3 ben ik het eens, de rest is in principe valide, ook al komen ze nu niet voor. De laatste (X-737) komt in de buurt van het Pekela-voorbeeld (C53).
Ik heb 123–A3 toegevoegd aan de tests en de regex verbeterd op dat punt.
Maar dat is juist het probleem hier: wat zijn de Nederlandse conventies. Het enige wat op papier staat is de BAG, en de gemeente kan waarschijnlijk alleen dat ingeven.
Moet je dan geen controle doen want “alles is mogelijk” of moet je de controle aanpassen op datgene dat “on the ground” gebruikt wordt?
Ik maak verder geen denkfout, ik was mij niet bewust dat het ook anders gedaan wordt.
Een facultatieve voorloopletter kun je toevoegen:
^([A-Za-z]{0,1})1-9([A-Za-z])?([-]{1}[0-9A-Za-z]{1,4})?$
Als er meer wordt gebruikt dan kun je dat ook in een regex proberen te modelleren.
Het punt is: je moet een correcte regex hebben of je moet geen controle doen. Vooral als er teveel false positives komen zullen mensen die niet gaan gebruiken.
Waarom moet de regex alles uitsluiten wat niet kan? Osmose wordt gebruikt om te acteren op waarschuwingen, niet omgekeerd. Het is al behulpzaam als alles wat buiten de conventionele notaties valt (met die Wikipediapagina en de BAG-regels samen kom je een heel eind) afvalt. Ook spaties rondom een nummer worden nu opgepikt als fout, en dat is prima.
#11
De ‘grappenmaker’ / trol die 1234567890abcdefghijklmnopqrstuvwxyz invult wordt nog niet gesignaleerd.
Getest op https://regexr.com/
aanbeveling: ^(t</del>/o ) → ^(t/o ) ←escaped forward slash
zonder escape kan het problemen in de praktijk geven
Edit: kopiëren/plakken zonder edit corrigeren + toevoeging
Je moet geen regex hebben die te te strikt is of sowieso fout, want met te veel false positives haken mensen die iets willen controleren af.
Ik heb hier een regex gezet die volgens mij de BAG volgt en die zelfs uitgebreid met de praktijk om een letter voor het huisnummer te zetten.
Wat wil je nog meer? Wil je nu een regex die niets uitsluit of wil je een regex die de BAG-regels en de praktijk volgt? Ik kan dat even niet uit je reactie halen.
Er wordt nu een aantal keer aangehaald dat de weergave van het adres uit de BAG komt. Volgens mij klopt dat niet en is de momenteel gehanteerde schrijfwijze (1a-A2C4) tot stand gekomen door overleg binnen de community. Het moet vast ergens terug te vinden zijn in dit forum vermoed ik.
In bijvoorbeeld de BAG viewer zie je dat huisnummer, huisletter en huisnummer toevoeging door een spatie van elkaar gescheiden worden weergegeven en afwijkt van hoe we het in OSM weergeven.
Kijkend naar de huidige BAG adressen met de voor OSM gekozen schrijfwijze voldoet de regex die Maarten Deen voorstelt:
Buiten de officiele adressen zijn er natuurlijk ook zelf verzonnen adressen waarvan degene die in het pand zit blijkbaar niet door de administratieve molen heen wil om een officieel adres te regelen. Van mij mogen deze best tegen een osmose validatie aanlopen als we het toch de moeite vinden deze in OSM vast te leggen. Ze zijn altijd te markeren als false-positive en daarmee op te lossen, dusom hiervoor nou .* als regex te gaan gebruiken lijkt me een brug te ver.
Ik snap je opmerking niet. De aanpassing van mij op de door danfos aangedragen regex lost de door AdVerburg gemelde problemen op. Ik maak de regex juist minder strikt.
Heb je de PR bekeken? De test-cases en de regex zouden duidelijk moeten maken wat ik voorstel. Draag gerust test-cases aan als je iets mist, of doe een PR op mijn PR.
Iets strikter gezegd: de meeste huisnummers komen geautomatiseerd uit de BAG-import.