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

Sat Nov 1 14:07:39 UTC 2014

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

-- 
"Everything is going to be 200 OK."