Ik heb het script nu verder uitgerust met een aantal
data-integriteits-checks rond postcode / gemeente. Daaruit blijken toch
nog wat bijzondere dingen waar ik het script op moet aanpassen. Zo
blijkt dat een straat (zoals geïdentificeerd door zijn ID in de
adressenlijst) in meerdere postcodes kan voorkomen, maar nooit in
meerdere gemeenten. Een gemeente bestaat uiteraard uit meerdere
postcodes. Daarnaast kan 1 postcode zich in meerdere gemeenten bevinden.
Halleluja; lees deze alinea nog maar 3 keer opnieuw...
Op dit moment identificeren we op basis van postcode → straat. Dat houdt
in dat we nu een aantal straten splitsen over de postcode, terwijl we op
basis van de data die straten zouden kunnen samenhouden. Mogelijk
(nouja; dat ben ik wel zeker) zijn straten ook gesplitst op
gemeentegrenzen, maar deze dataset biedt daar geen mogelijkheden voor.
Mijn script pikt nu deze over-postcodes-heen-gesplitste-straten op; het
gaat om 1920 unieke straten die meestal over 2 maar soms over 3
postcodes heen gesplitst zijn. Mijn script biedt al heel wat
mogelijkheden om hier mee om te gaan, maar we moeten het natuurlijk wel
eens zijn over wat wenselijk is.
Concreet betekent het in feite dat als we onderscheid maken op basis van
een postcode, we onherroepelijk straten zullen splitsen. We kunnen
ervoor kiezen om de data per gemeente te ordenen, maar dan wordt de
hoeveelheid data per gemeente bijna 2 keer zo groot als de data nu per
postcode (er zijn in totaal 308 gemeenten en 519 postcodes). Gezien de
nu vaak al grote hoeveelheid straten per postcode is dit misschien
onwenselijk. Zeker omdat het volgens mij vaak al de stedelijke gemeenten
zijn die meerdere postcodes hebben. Die gemeenten gaan dan van zeer
grote stratenlijsten naar enorme stratenlijsten. Een alternatief is die
straten in beide postcodegebieden op te nemen. Dat vind ik ook geen
nette uitwerking omdat je dan redundancy krijgt in de de JSON-bestanden.
Volgens mij is dan de beste optie om per straat in de
postcode-JSON-bestanden een extra JSON-attribuut mee te geven die
aangeeft of de straat doorloopt in een andere gemeente. Dat zie ik in de
vorm van een lijst van postcodes per straat waar de straat in doorloopt.
Dat kan met wat javascript uitgelezen worden. Die specifieke straat kan
in datzelfde stuk javascript opgehaald worden en aan de betrokken straat
toegevoegd worden. Als je het meer handmatig wil houden kun je vrij
eenvoudig een knop toevoegen voor de gebruiker om die straat in de
andere gemeenten mee in te laden. Op deze manier kan de opdeling per
postcode gehandhaafd worden, maar is toch duidelijk op straat-niveau
waar mappers mee rekening dienen te houden. Daarnaast is deze informatie
mogelijk ook zeer belangrijk voor de scripts van Jo rond het koppelen
van adressen/gebouwen aan een straat. Wat denken jullie hiervan?
Daarnaast speelt dus het tweede punt dat er een aantal postcodes over
meerdere gemeenten heen lopen. Althans: dat er adrespunten zijn met
dezelfde postcode die tot een andere gemeente behoren. Voor mijn script
en onze opzet is dat op zich geen probleem, maar ook hier kan ik deze
punten specifiek eruit lichten. Het gaat overigens 54 van de 519
postcodes; toch zo'n 10%. Daarbij zijn 81 gemeenten betrokken; een kwart
van het totaal aantal gemeenten. Het totaal aantal adrespunten draait zo
rond de 250 adrespunten in totaal. Ik moet mijn script nog wat aanpassen
om preciese cijfers hierover te hebben. Ruimtelijke samenhang is er
niet: het komt nergens in aanzienlijk grotere mate voor dan elders.
Hoewel soms gesteld wordt dat postcodes helemaal niet samenvallen met
gemeenten, blijkt dat dit dus maar in 1 op de 15.000 gevallen NIET zo
is. Meestal gaat het over 1 postcode die over twee gemeenten valt. In 7
van de 54 gevallen gaat het om een postcode die binnen 3 gemeenten valt.
Nooit gaat het om meer dan 3 gemeenten.
Kort samengevat: op basis van de bij de adrespunten behorende gemeente
kunnen we straten die door een postcode gesplitst worden weer aan elkaar
plakken. Mijn idee is om een lijst van postcodes aan de straat te
koppelen in de JSON, zodat in het javascript die gegevens verwerkt
kunnen worden. Daarnaast zijn het postcodesysteem en de gemeentelijke
indeling gescheiden systemen. Wordt daar in de verdere verwerking in OSM
rekening mee gehouden? Onder andere bij de verschillende scripts die
matching regelen is dat een belangrijk punt. Met mijn script kan ik
“afwijkende” punten aangeven, maar dan moeten we wel weten op welke
manier. Wat moeten we hiermee?
Groeten,
Thomas
Sander Deryckere schreef op 29-10-2014 12:06:
Hoi Thomas,
Net het script wat verder aangepast voor de nieuwe data, en geuploaded
naar jouw repo. Dus aan iedereen, gelieve vanaf nu vooral
http://aptum.github.io/import.html te testen,
Kan je de appartementsnummers en busnummers als aparte lijsten in de
JSON zetten? Dan kan ik ook het script updaten om addr:flats te
ondersteunen. Lijsten zijn het best aangezien ze gemakkelijker
omgevormd kunnen worden naar de correcte formaat. Ook die best
alfabetisch sorteren voor de diffs. En misschien enkel de lijsten aan
de JSON toevoegen indien wel degelijk (dat zal bandbreedte sparen voor
de vele adressen die geen busnummers of appartementsnummers hebben).
Aangezien de overlappende en de niet overlappende nummers nu in
verschillende kolommen staan, is daar geen verschillende CSS voor
nodig. Een verschillende CSS voor de herkomst kan wel helpen.
Momenteel staat die herkomst nog in CRAB:source om de waarden
gemakkelijk te kunnen aflezen. Dus momenteel die tags nog niet gaan
uploaden.
Als het goed is voor iedereen, dan breng ik die tags naar de vorm
* odbl:note=CRAB:manueleAanduidingVanGebouw
* odbl:note=CRAB:geinterpoleerdObvNevenliggendeHuisnummersGebouw
* ...
odbl:note lijkt mij de meest neutrale van alle discardable tags, en
het voorvoegsel CRAB: kan zorgen voor unieke CSS selectors.
De grootste problemen momenteel zijn de huisnummers met een
underscore. Ik kan moeilijk beslissen als ik die naar bis, ter, ... of
naar /1, /2, /3, ... breng. Maar het overlaten aan de mapper kan er
voor zorgen dat de huisnummers met een underscore rechtstreeks
geuploaded worden.
Het andere grote probleem is de spelling van de straatnaam. Dat is
moeilijk om af te leiden met de beperkte OSM data die ik heb in de
webpagina (vooral als er nog geen adressen in OSM zijn). Een
spellingsverschil kan er voor zorgen dat huisnummers geuploaded worden
waarbij addr:street verschilt van de straatnaam in OSM. Wat natuurlijk
voor problemen zal zorgen. Maar hierbij kan Jo misschien helpen, of de
JOSM validator.
Als die problemen opgelost zijn, dan lijken de tools klaar, en wordt
het tijd om enkele definitieve beslissingen te maken:
* Huizen tekenen of niet
* Aparte gebruikersnaam of niet
* Welke tags moeten op de changeset
* Hoe contacteren we het AGIV met opmerkingen?
* ...
Groeten,
Sander
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
