Osmose: addr:housenumber test

AdVerburg · 2019-12-18T15:13:25.000Z

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?

JeroenHoek · 2019-12-18T15:43:07.000Z

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

Dit is gewoon correct namelijk: 73-320

JeroenHoek · 2019-12-18T15:44:43.000Z

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

JeroenHoek · 2019-12-18T15:45:43.000Z

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.

AdVerburg · 2019-12-18T21:28:39.000Z

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}

Maarten_Deen · 2019-12-19T06:54:54.000Z

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/

JeroenHoek · 2019-12-19T07:35:07.000Z

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.

JeroenHoek · 2019-12-19T07:42:18.000Z

AdVerburg:

123–A3, 125 A, 1279-appel, 9999ABCD, 44bis, X-737 ← zijn fout

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.

Maarten_Deen · 2019-12-19T08:03:14.000Z

JeroenHoek:

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.

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.

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.

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.

JeroenHoek · 2019-12-19T08:56:59.000Z

Maarten Deen:

of moet je de controle aanpassen op datgene dat “on the ground” gebruikt wordt?

Natuurlijk, maar dat doet de BAG niet.

Maarten Deen:

Het punt is: je moet een correcte regex hebben of je moet geen controle doen.

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.

JeroenHoek · 2019-12-19T08:58:38.000Z

Maarten Deen:

Als er meer wordt gebruikt dan kun je dat ook in een regex proberen te modelleren.

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.

AdVerburg · 2019-12-19T10:46:40.000Z

#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

JeroenHoek · 2019-12-19T11:10:01.000Z

AdVerburg:

aanbeveling: ^(t/o ) → ^(t/o ) ←escaped forward slash

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

JeroenHoek · 2019-12-19T11:13:39.000Z

AdVerburg:

De ‘grappenmaker’ / trol die 1234567890abcdefghijklmnopqrstuvwxyz invult wordt nog niet gesignaleerd.

Aangepast.

JeroenHoek · 2019-12-19T11:14:59.000Z

AdVerburg:

escaped forward slash

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

Maarten_Deen · 2019-12-19T14:52:22.000Z

JeroenHoek:

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.

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.

Sander_H · 2019-12-19T17:01:03.000Z

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:

Maarten Deen:

Dan zou ik zeggen dat het ^[1](\d{0,4})([A-Za-z])?([-]{1}[0-9A-Za-z]{1,4})?$ moet zijn.

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-9 ↩︎

JeroenHoek · 2019-12-19T19:30:47.000Z

Maarten Deen:

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.

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.

Sander H:

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.

Iets strikter gezegd: de meeste huisnummers komen geautomatiseerd uit de BAG-import.

SvenSp66 · 2023-10-11T10:56:08.945Z

^(\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.

Kin_Sapalot · 2023-10-11T18:36:04.126Z

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