Inmiddels ook de codering in gehoorzaamheid gedwongen. Blijkt dat de
codering van de shapefile gewoon Latin-1 is en niet die vage CP-720. Dat
scheelt ook maar weer.
De snelheid van mijn script valt me al bij al wel mee. Op dit moment
gebruikt hij maar 1 thread. Het inlezen van het bestand in de
dictionaries duurt zo'n 50 minuten. Het schrijven naar de JSON-bestanden
een kleine 10 minuten (op een SSD'tje). Het schrijven gaat volgens mij
wat trager omdat ik de adres-dictionary vervangen heb door een tuple.
Dat scheelt toch een kleine 500MB in geheugengebruik. In totaal gebruikt
het script maar iets van 2GB ram dacht ik, maar dat moet ik nog even
nakijken. Sinds die wijziging heb ik in elk geval geen geheugenproblemen
meer gehad.
Qua tags hoeven we inderdaad enkel de addr:housenumber en addr:street
over te nemen. Daarnaast wil ik graag het herkomst-veld als tag
invoeren, zodat de punten gestyled kunnen worden op basis daarvan. Naar
mijn idee is die herkomst zeer bepalend voor de “nauwkeurigheid” van de
punten. Ik heb dat nu geïmplementeerd als een “CRAB:herkomst”-tag. De
Engelse variant “CRAB:source” vond ik een beetje misleidend. Aan de
andere kant gaat het natuurlijk wel over hoe ze de locatie van het punt
bepaald hebben. Dat kun je dus wel als “source” zien.
Daarnaast misschien nog iets van een tag om waarschuwingen mee te
communiceren, bijvoorbeeld over de schrijfwijze van de straatnaam. Aan
de andere kant heb ik geen enkel geval kunnen vinden waar twee adressen
een zelfde straatnaam-id hebben maar een verschillende straatnaam
(bijvoorbeeld een andere spelling). Dat soort fouten lijken me maar
beperkt aanwezig en kunnen dus waarschijnlijk allemaal opgevangen worden
met de FIXME-tag. Het huidige gebruik (om punten zonder locatie mee aan
te geven) is in feite overbodig, omdat alle punten een locatie hebben.
Ik ben nu nog wat aan het kijken welke fouten ik met het python-script
moet opsporen en welke best in de javascript naar boven gehaald kunnen
worden in combinatie met de overpass-query. Het belangrijkste zijn de
punten die samenvallen. Dat is een situatie die niet ingevoerd mag
worden in OSM, dus ook hier lijkt een FIXME-tag mij het meest geschikt.
Dat ga ik in elk geval nog even netjes documenteren.
Nog een praktisch punt: hoe willen we deze tweede variant beschikbaar
stellen? Moet dat naast de huidige komen te staan zodat we kunnen
vergelijken, of moeten we juist vermijden dat er twee varianten in
gebruik zijn en dat er verwarring ontstaat? Voor de gewone gebruiker is
er eigenlijk geen verschil tussen beide systemen, dus dat is potentieel
verwarrend. Anderzijds is het in de huidige beperkte opzet niet zo'n
punt en misschien juist handig. Wat zijn jullie ideeën hierover?
Groeten,
Thomas
Sander Deryckere schreef op 25-10-2014 20:17:
Op 25 oktober 2014 18:46 schreef Thomas <o...@aptum.nl
<mailto:o...@aptum.nl>>:
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.
Geweldig nieuws ;)
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 had ook al wat zaken opgezocht om het GML bestand te splitsen en
pas daarna te verwerken, om zo slechts XML kind per kind in het
geheugen te laden en geen geheugen tekort te komen. Maar dat werd een
serieus gepruts, en ik verwachtte ook dat het te traag zou zijn door
de vele lees en schrijf operaties.
Geheugenproblemen had ik sowieso verwacht, want zelft met het huidige
script moet ik zorgen dat Firefox en JOSM alletwee gesloten zijn voor
ik het script start. Anders loopt mijn computer onherroepelijk vast in
het page-swapping.
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?
source=* tags zijn beter op hun plaats op het changeset object dan op
objecten in de DB. Natuurlijk kan een specifieke bron (zoals afkomstig
van de voordeur, gebouw or perceel) wel op het object zelf.
Postcode en gemeente zijn sowieso niet nodig, die kunnen gerust uit de
JSON gelaten worden. Welke andere keys twijfel je nog over?
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 <mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org <mailto: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
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
