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

Sat Nov 1 14:46:43 UTC 2014

Oeps! Mijn fout. Door het omzetten van huisnummerlabel naar een lijst 
van huisnummerlabels ging het verkeerd als die lijst niet aanwezig was 
in de JSON. Ik heb twee checks toegevoegd rond regel 360. Als het goed 
is is het probleem nu verholpen.

Glenn Plas schreef op 1-11-2014 15:07:
> Der zit een probleem in de js:
>
>
> 	sourceHnr = uniformise(sourceAddr.housenumber);
> 	sourceHnrLabel = uniformise(sourceAddr.hnrlbls[0]);
> 	compHnr = uniformise(compAddr.housenumber);
> 	compHnrLabel = uniformise(compAddr.hnrlbls[0]);
> 	
>
> compAddr is not defined, dus ook geen array.  De map laad niet meer.
>
> Glenn
>
> On 01-11-14 13:12, Thomas wrote:
>> 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
>>>>
>>
>> _______________________________________________
>> Talk-be mailing list
>> Talk-be at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>