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

Sat Nov 1 19:15:21 UTC 2014

Op 1 november 2014 13:12 schreef Thomas <osm at aptum.nl>:

> De nieuwe reeks JSON-bestanden staat inmiddels online.
>
> Bedankt, zal eens kijken als alles nog werkt, en wat er toegevoegd is ;)

> 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.
>
> Gebeurt dit vaak? Het lijkt me sowieso een fout in CRAB als dit gebeurt.
Ik weet niet goed hoe ik foute data kan vergelijken, buiten melden dat er
ergens een fout zit. Zal het verder onderzoeken.

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20141101/96270a0c/attachment.htm>