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 <sander...@gmail.com
<mailto:sander...@gmail.com>>:
Op 25 oktober 2014 14:48 schreef Sus Verhoeven <sus...@gmail.com
<mailto:sus...@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
