[OSM-talk-be] import AGIV CRAB-data

Thomas osm at aptum.nl
Sat Nov 1 12:12:48 UTC 2014


De nieuwe reeks JSON-bestanden staat inmiddels online.

Zoals eerder gezegd is de voornaamste wijziging die invloed heeft op de 
huidige werking het feit dat huisnummerlabels nu in een array meegegeven 
worden, zodat bij meerdere huisnummer-labels per huisnummer, deze 
allemaal doorgegeven kunnen worden. Dat kan Sander misschien helpen bij 
het matchen met de gegevens uit OSM.

Verder wordt er per adres nu ook, indien aanwezig, een lijst met 
busnummers en appartementnummers op dat huisnummer meegegeven (allen 
gesorteerd en gefilterd zodat de lijsten geen dubbele waarden bevatten). 
Hoe beide lijsten zich tot elkaar verhouden kan nu in de praktijk 
bekeken worden. Mogelijk is er soms overlap. Daarnaast zijn er 4 keer 
zoveel busnummers als appartementnummers. Wanneer voor welke gekozen 
wordt, is mij niet duidelijk.

De “message” (die in tekstvorm informatie gaf over busnrs en apptnrs) 
die in de laatste varianten van de javascript niet meer ingeladen werd 
heb ik uit de JSON weggehaald.

Ik heb een element “municipality” toegevoegd die de gemeentenaam 
weergeeft. De postcode was eerder al ontsloten via het element “postc”. 
Er kan nu gekeken worden of en onder welke tags deze gegevens in JOSM 
ingeladen moeten worden. Daarnaast kunnen de gegevens gebruikt worden 
voor een verificatie van bestaande gemeente- en postcodegrenzen in OSM, 
hoewel dat natuurlijk los staat van deze import.

Tot slot heb ik een lijst “otherPCs” toegevoegd aan de 
postcode-JSON-bestanden, die (indien aanwezig) een lijst geeft met de 
andere postcodes waar de betreffende straat in doorloopt. Hoewel dat in 
het huidige systeem niet nodig is, kan het interessante informatie zijn 
om bepaalde vreemde zaken te analyseren.

Ook heb ik een overzicht gemaakt van de gebruikte JSON-elementen zodat 
voor iedereen duidelijk is welke informatie beschikbaar wordt gesteld 
via de JSON-bestanden en op welke manier dat gebeurt. Daarnaast heb ik 
ook de data-specificatie van de adressenlijst zelf opgenomen. Het 
bestand staat nu op http://downloader.aptum.nl/data_format.pdf maar ga 
ik netjes integreren met de rest van de documentatie en vervolgens als 
verzamelde documentatie op github plaatsen.

Dan over die vreemde postcode-gemeente overlap. Ben gaf eerder aan dat 
er situaties zijn waarin postcode-straatnaam-huisnummer niet uniek zijn 
en dat de gemeentenaam daarbij noodzakelijk is om het adres te 
identificeren. Uiteraard heb je per postcode-straatnaam-huisnummer een 
hele verzameling subadressen (met elk een eigen busnummer / 
appartementnummer) maar dat was uiteraard niet wat er bedoeld werd. Ik 
heb de volledige dataset expliciet doorzocht naar een situatie waarbij 
er voor een combinatie van postcode-straatnaam-huisnummer meerdere 
gemeenten geregistreerd waren, maar die heb ik niet kunnen aantreffen.

Als deze situatie zich zou voordoen, dan kan dit enkel voor de gevallen 
waar een postcode zich over meerdere gemeenten uitstrekt. We weten al 
dat deze situatie zich slechts voor 253 adressen binnen de volledige 
dataset (2.639.893 echte adressen) voordoet. Van die 253 adressen die 
een gemeentenaam hebben die je niet bij die postcode verwacht, lijkt het 
meestal om vergissingen te gaan. Ik heb het idee dat wat Sander aanhaalt 
wel eens de systematisch fout kan zijn: iets met gemeentelijke 
herindelingen. Dat is de enige logica die in de collectie fouten lijkt 
te zitten.

Om dat verder uit te zoeken heb ik volgend document opgesteld: 
http://downloader.aptum.nl/multiple_NIS_per_PC.pdf . Daarin heb ik de 
betreffende 253 adressen per straat gegroepeerd en het aantal adressen 
per straat aangegeven. De postcode en gemeente zijn de gegevens zoals 
die voor dat adres in de CRAB-adressenlijst zijn opgegeven. De 
Gemeente_verwacht is de gemeente zoals mijn script die zou verwachten 
voor de opgegeven postcode. De vraag is dus hoe beide gemeenten 
gerelateerd zijn. Zoals Sander al schreef is de kans zeer aanwezig dat 
de opgegeven postcodes nog “oude” postcodes zijn van voor de 
gemeentelijke herindeling, en dat de opgegeven gemeente dus wel klopt, 
maar dat de postcode verouderd is. Ik ga dat proberen systematisch na te 
zoeken. In elk geval betreft het hier fouten in de CRAB-adressenlijst.

In de adressenlijst zitten geen gegevens over de status van het adres 
(zie ook de data-specificatie hierboven). Mogelijk is dat wel een 
achterliggende reden: dat de adressen in de praktijk geschrapt zijn en 
daarmee niet bijgewerkt worden, maar dat ze niet formeel een 
statuswijziging gekregen hebben in de database. Dat zal het Agiv echter 
moeten uitzoeken.

Verdere analyse moet uitwijzen of er ook “correcte” gegevens in de lijst 
staan. Dat zal aangeven of de situatie van een postcode die over 
meerdere gemeenten loopt ook daadwerkelijk voorkomt. Ik ben geneigd te 
denken van niet. In totaal hebben we nu maximaal 253 adressen waarvan 
toch zeker een aanzienlijk deel gewoon fouten zijn. Stel dat er 50 
plausibele gevallen overblijven in de totale dataset, dan lijkt mij dat 
eerder op een fout te wijzen in de postcodeverdeling zelf. Ik zie hier 
in elk geval geen bewijs in dat postcodes over meerdere gemeenten kunnen 
lopen (en dat in de praktijk ook doen).

Los daarvan moeten we natuurlijk kijken hoe we deze gevallen in de 
praktijk verwerken. Dit levert wel degelijk een “probleem” op voor ons 
huidige systeem, omdat de gegevens per postcode en per straat 
gegroepeerd worden. Als een postcode fout is (bijvoorbeeld omdat het de 
“oude” postcode is van voor de gemeentelijke herindeling) dan komen die 
adressen onder de nieuwe postcode te staan, die in een heel ander gebied 
kan liggen. Met ons huidige systeem zullen we echter geen fouten 
introduceren in OSM, aangezien de locatiegegevens van de adressen wel 
kloppen, en we de postcode niet expliciet van een tag voorzien. Op zich 
lijkt het mij dus aanvaardbaar de situatie zo te laten en vooral bij het 
AGIV aandringen op het corrigeren van de gegevens.

Het voornaamste wat nu nog moet gebeuren is de integratie van de nieuwe 
gegevens in de JSON-bestanden in de javascript.

Groeten,
Thomas

Glenn Plas schreef op 1-11-2014 12:31:
> Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast.  De
> problemen die ik zag zijn zo te zien allemaal ondertussen opgelost.
>
>
> De wiki handleiding is handig ook.  Tijdens het gebruiken heb ik
> eigenlijk vooral problemen bij nr notaties van dit type:
>
> vb1:
>
> nr is 100 , bus 4
>
> varianten die je ziet:
>
> - 100b4
> - 100/4
>
>
> vb2:
>
> nr is 26 / A
>
> - 26A
> - 26/a
> - 26a
>
> vb3 (moeilijker)
>
> - 46 / 0001 en 46 / 0101 (2-woonst... op het gebouw zo op de plaatjes),
> vind ik maar rare nummering.  Ik ben al even op zoek in de wiki over wat
> de consensus nu is over dit soort adressen.
>
> Die vind je ook niet terug in CRAB.  Maar zo'n nodes zie ik de meeste
> 'missing in crab' terugkomen.
>
> Ik hou me nog wel wat in tot ik iets echt nuttig kan toevoegen.
>
>
> Glenn
>
>
> On 01-11-14 11:36, Thomas wrote:
>> Vooraleer iemand in het komende uur of zo een pull of push wil gaan
>> uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het
>> enige punt waarop ze niet backwards-compatible zijn is het feit dat het
>> huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al
>> aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel
>> gelezen wordt in het script gewoon het eerste element uit de array
>> genomen wordt. Die nieuwe variant van de javascript zit als het goed is
>> mee in die push.
>>
>> Gelieve dus nog even een uurtje te wachten met andere acties, anders
>> komen er mogelijk een hele hoop conflicten.
>>
>> Van zodra de push klaar is, stuur ik nog een mailtje met wat meer
>> informatie over die postcode-gemeente problematiek en wat inhoudelijke
>> informatie over de extra gegevens in de JSON. Het kan even duren; de
>> diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even...
>>
>> Groeten,
>> Thomas
>>
>> Sander Deryckere schreef op 1-11-2014 11:25:
>>> Op 1 november 2014 10:30 schreef Glenn Plas <glenn at byte-consult.be
>>> <mailto:glenn at byte-consult.be>>:
>>>   
>>>
>>>      @Sander Accepteer je de occasionele commits of pull requests?
>>>
>>> Zeker, waarover gaat het?
>>>   
>>
>>
>> _______________________________________________
>> Talk-be mailing list
>> Talk-be at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>





More information about the Talk-be mailing list