Osmose: addr:housenumber test

Osmose controleert o.a. op de geldigheid van de in OSM genoteerde huisnummers.
De regels voor die controle zouden zijn gebaseerd op https://imbag.github.io/catalogus/hoofdstukken/attributen–relaties#734-huisnummertoevoeging
(ik zie daarin zo snel niet hoe dat er dan uitziet).
Ik heb er melding van gemaakt dat er toch wel erg veel meldingen van foute nummer-aanduiding zijn bij Osmose, zie: https://github.com/osm-fr/osmose-backend/issues/711

Daarop komt vervolgens de vraag van de onwikkelaar(s) wat te doen:
① hun test proberen te verbeteren, of
② die (strikte) test eruit halen

Wat is de mening van de Nederlandse gebruikers?

Ik zie danfos geen rekening houden met koppelstreepjes in zijn regex. Klopt dat?

Dit is gewoon correct namelijk: 73-320

De betreffende regex:

^[1-9][0-9]{0,4}[0-9A-Za-z]{0,4}$

Daar wordt wel naar elk onderdeeltje van het huisnummer gekeken, maar niet naar de manieren waarop je die kan samenvoegen (spaties, koppeltekens).

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.

Na wat gepuzzel kom ik tot de volgende regex:

^(\d{1,5})([A-Za-z])?([-]{1}[0-9A-Za-z]{1,4})?([-]{1}[0-9A-Za-z]{1,4})?$

123–A3, 125 A, 1279-appel, 9999ABCD, 44bis, X-737 ← zijn fout
123a-M, 19p-8, 1A-847, 29, 31a, 44-bis, 10-BY, 10-PG3, 54-CORS, 1-TRAF, 201-121, 3-0072 ← worden goedgekeurd.
Iemand een beter idee?

Edit: aanpassing \d+ → \d{1,5}

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).

Gecontroleerd met regex checker op https://regex101.com/

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.

Heb je mijn verbtersuggestie gezien in https://github.com/osm-fr/osmose-backend/issues/711 ? (in https://github.com/osm-fr/osmose-backend/pull/713))

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.

Natuurlijk, maar dat doet de BAG niet.

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.

Dat doe ik al in de PR, zie https://github.com/osm-fr/osmose-backend/pull/713. Noem gerust extra test-cases die behulpzaam kunnen zijn.

#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

Ik zie geen verschil, misschien even in een code-blok zetten?

Aangepast.

Oh zo. Die is hier in deze Python-code niet nodig.

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.


  1. 1-9 ↩︎

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.

^(\d{1,5})(?=(([A-Za-z]{0,1})?|([-/ ]{0,1}[0-9A-Za-z]{1,5})?$)) werkt voor mij,
waarbij het koppelteken er wel of niet of - in plaats daarvan - een spatie of slash forward kan zijn.
Het werkt met alle voorbeelden behalve X-737, maar die lijkt me sowieso fictief.

*Off topic: maar doet me denken aan deze klassieker, voor wie dit niet kent :wink:
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/