<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Op 25 oktober 2014 20:57 schreef Thomas <span dir="ltr"><<a href="mailto:osm@aptum.nl" target="_blank">osm@aptum.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<br>
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. <br>
<br>
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.<br>
<br>
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. <br></div></div></blockquote><div><br></div><div>CRAB:source=* lijkt me goed. Als de waarden enigszins duidelijk zijn, dan is alles ok. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
<br>
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. <br>
<br></div></div></blockquote><div>De JOSM validator kan hier ook nuttig zijn. Als de coordinaten volledig overeenkomen, dan zal de validator sowieso klagen denk ik. Dus is een fixme tag misschien niet volledig noodzakelijk<br><br>De straatnaam id is in de posities database de enige manier om de straatnaam te vinden. Dus als er enige overeenkomst tussen de databases is, dan is het normaal dat je geen straatnaam-id vindt met twee verschillende namen. De andere kant kan wel voor komen: dezelfde straatnaam (of bijna dezelfde) met een verschillende straat id.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
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.<br>
<br></div></div></blockquote><div>Ik zou het foutopsporen vooral voor de JS kant houden. Dan kunnen we dat gemakkelijker aanpassen (zonder een script van een uur te draaien om dan een klein tikfoutje te ontdekken). <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
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?<br>
<br></div></div></blockquote><div>Ik zou het nog even naast elkaar houden, kwestie van vergelijking. Na het evalueren van de tools kunnen die dan onder een beter adres beschikbaar gesteld worden.<br><br></div><div>Host je het onder je eigen server (desnoods je eigen github account) of wil je toegang tot de repo die ik nu heb?<br><br></div><div>Groeten,<br></div><div>Sander<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div><br></div></div>