Op 25 oktober 2014 20:57 schreef Thomas <o...@aptum.nl>: > > 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. >
CRAB:source=* lijkt me goed. Als de waarden enigszins duidelijk zijn, dan is alles ok. > > 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. > > 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 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. > 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. > > 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). > 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? > > 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. Host je het onder je eigen server (desnoods je eigen github account) of wil je toegang tot de repo die ik nu heb? Groeten, Sander >
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
