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

Sat Oct 25 16:46:55 UTC 2014

Ik ben inmiddels bijna klaar met het nieuwe script dat de adressenlijst 
(in plaats van de adresposities) moet beschikbaar stellen via de website 
die Sander gemaakt heeft.

Het oude script kon ik maar voor kleine stukjes hergebruiken omdat het 
bestandsformaat en de datastructuur toch redelijk anders zijn. Ik ben 
uitgegaan van precies dezelfde JSON-uitwisselbestanden te genereren 
zodat de website wel volledig compatibel is (op misschien wat extra tags 
in javascript na dan). Het was niet eenvoudig om een goed werkend script 
op te zetten vanwege de door Sander genoemde coderingsproblemen en 
vanwege het feit dat deze adressenlijst in feite 1 grote tabel is 
tegenover de adresposities die in feite een 'database' zijn of een 
collectie van kleinere tabellen. Daardoor liep ik tegen nogal wat 
geheugenprobleempjes aan.

De beschikbare modules om GML in te lezen in python bleken niet robuust 
genoeg om én met de vreemde codering om te gaan én met de enorme omvang 
van het bestand (ca. 3GB). Daarom heb ik ervoor gekozen om als bron het 
shp-bestand te gebruiken (dat 'slechts' 1GB in omvang is, door een 
efficiëntere datastructuur). Daarmee kreeg ik wel alles aan de praat.

Ik ben nu een aantal extra checks in de code aan het inbouwen en te 
kijken wat handig is qua extra tags (evt. gekoppeld aan wat CSS). Het 
blijft ook wat worstelen met de omvang. Mijn eerste tests werken in elk 
geval bij mij. Als het een beetje wil komt dat dus dit weekend af. Ook 
alle gemelde 'problemen' met de huidige dataset ga ik bekijken in deze 
nieuwe dataset.

Voor alle duidelijkheid: voor de gebruikers verandert er weinig tot 
niets tegenover de huidige versie. Belangrijkste wijzigingen zijn het 
feit dat er punten zonder positie zullen zijn en dat er misschien wat 
extra tags automatisch ingeladen worden in JOSM als je een straat 
importeert. Die extra tags moeten helpen om de informatie naar waarde te 
schatten. In elk geval in deze eerste test-fase kunnen ze zeer handig 
zijn om beter bepaalde zaken te begrijpen.

Ik heb nu voor het patroon “CRAB:key” gekozen als key voor de tags die 
ik in JOSM inlaad maar die niet in OSM thuishoren. Zijn er alternatieve 
patronen voor dit soort “tijdelijke” werk-tags die OSM nooit mogen 
bereiken? In de link die Marc eerder doorstuurde lees ik vooral dat onze 
Nederlanders een aantal overbodige tags in OSM hebben zitten n.a.v. een 
aantal imports. Het lijkt me op zich een mooi streven om al dat soort 
tags buiten OSM te houden, wat onze 'import' betreft.

Moet er overigens nog een “source=CRAB”-tag toegevoegd worden, of willen 
we dit juist vermijden omdat het toch al niet om een automatische import 
gaat?

Groeten,
Thomas

Sander Deryckere schreef op 25-10-2014 17:52:
> Hmm, blijkbaar hebben alle tabellen een mogelijkheid tot deleten via 
> "einddatum".
>
> En blijkbaar gaat dat niet altijd samen.
>
> Ik heb nu net eens het script laten lopen met alle records waar 
> "einddatum" bijstond genegeerd, en dat resulteert vooral in 
> terreinobjecten die genegeerd worden, waardoor er vooral extra 
> adressen zonder positie zijn :/
>
> Heb ook eens de Koningin Louisa-Marialaan bekeken met die nieuwe data, 
> en daar blijkt er nu geen verschil te zijn O_o
>
> Dus denk ik dat ik het script nog niet zal aanpassen.
>
> Groeten,
> Sander
>
> Op 25 oktober 2014 16:11 schreef Sander Deryckere <sanderd17 at gmail.com 
> <mailto:sanderd17 at gmail.com>>:
>
>
>
>     Op 25 oktober 2014 14:48 schreef Sus Verhoeven <susvhv at gmail.com
>     <mailto:susvhv at gmail.com>>:
>
>         In Leopoldsburg 3970 op de Koningin-Louisalaan is er in CRAB
>         een hele reeks huizen met dubbele huisnummers niet op dezelfde
>         plaats, in GRB staat er maar een van deze reeksen.
>         Eigenaardig.
>
>         Sus
>
>
>     Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude
>     nummers nog niet verwijderd zijn.
>
>     Ook de GRB basiskaart is niet volledig duidelijk. Zo is er daar
>     een nummer 13-125 te zien, wat een veel te grote range is om te
>     kunnen kloppen. Ik zou voorstellen om eens ter plaatse te gaan
>     kijken wat er nu echt juist is.
>
>     Volgens de documentatie van de databases zouden ze verouderde
>     nummers moeten deleten door er een "einddatum" aan te geven. In
>     het extract script test ik ook op die einddatum, dus als ze
>     correct verwijderd zijn, dan zouden ze niet meer in de data mogen
>     voorkomen.
>
>     Het is natuurlijk niet eenvoudig om in dit geval te controleren
>     als het script of de data fout is, omdat het nu eenmaal niet vaak
>     gebeurt dat een straat hernummerd wordt.
>
>     In Leuven werd onlangs een straat hernummerd (zie
>     http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793)
>     en ik denk dat de CRAB data overeenkomt met de huidige data, dus
>     dat de verwijderde nummers wel degelijk niet meer zichtbaar zijn.
>     Maar 1 voorbeeld is natuurlijk wat weinig om op voort te gaan.
>
>     Groeten,
>     Sander
>
>
>
>
> _______________________________________________
> 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/20141025/17c9afc3/attachment.htm>