<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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...<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.
<br>
<br>
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?<br>
<br>
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. <br>
<br>
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? <br>
<br>
Groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 29-10-2014 12:06:<br>
</div>
<blockquote
cite="mid:CABUOUO_J8MWNgxLoJYcUW1r-cMd+gmRjv88T=PVt=8sAKrtkkA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>Hoi Thomas,<br>
<br>
</div>
Net het script wat verder aangepast voor de nieuwe data,
en geuploaded naar jouw repo. Dus aan iedereen, gelieve
vanaf nu vooral <a moz-do-not-send="true"
href="http://aptum.github.io/import.html">http://aptum.github.io/import.html</a>
te testen,<br>
<br>
</div>
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).<br>
<br>
</div>
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.<br>
<br>
</div>
Als het goed is voor iedereen, dan breng ik die tags naar de
vorm <br>
<ul>
<li>odbl:note=CRAB:<span class="">manueleAanduidingVanGebouw</span></li>
<li><span class=""></span><span class="">odbl:note=CRAB:<span
class=""></span></span><span class=""><span class=""><span
class="">geinterpoleerdObvNevenliggendeHuisnummersGebouw</span></span></span></li>
<li><span class="">...<br>
</span></li>
</ul>
<span class="">odbl:note lijkt mij de meest neutrale van alle
discardable tags, en het voorvoegsel CRAB: kan zorgen voor
unieke CSS selectors.</span> <br>
<div><span class=""><br>
</span></div>
<div><span class="">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.<br>
<br>
</span></div>
<div><span class="">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. <br>
<br>
<br>
</span></div>
<div><span class="">Als die problemen opgelost zijn, dan lijken
de tools klaar, en wordt het tijd om enkele definitieve
beslissingen te maken:<br>
</span>
<ul>
<li><span class="">Huizen tekenen of niet</span></li>
<li><span class="">Aparte gebruikersnaam of niet</span></li>
<li><span class="">Welke tags moeten op de changeset</span></li>
<li><span class="">Hoe contacteren we het AGIV met
opmerkingen?</span></li>
<li><span class="">...</span></li>
</ul>
</div>
<div><span class="">Groeten,<br>
Sander<br>
</span></div>
<div><span class=""><br>
</span></div>
</div>
</blockquote>
</body>
</html>