De validator geeft inderdaad netjes melding van de meerdere punten op
elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van
de adressen zonder positie uit jouw script vallen nu samen met een ander
punt. Voor wat ik zo snel even kon bekijken zijn dat toch best veel
punten. Daar moet dus sowieso handmatig op ingegrepen worden (zoals
eigenlijk op heel veel punten).
Moeten we nog iets doen met een hulptag over appartementsnummer,
busnummers of huisnummerlabels? Over dat laatste zegt het AGIV in de
documentatie: “Opgelet: Komen er op de coördinaat van het CRAB adres
meerdere huisnummers voor die in dezelfde straat liggen, dan bevat het
label het laagste en het hoogste huisnummer (bv. label 10-14 voor het
perceel met de huisnummers 10, 12 en 14 in de Molenstraat).”. Het zou
ook mogelijk moeten zijn om voor deze punten automatisch een
samengestelde addr:housenumber-value te maken die een samenstelling is
van de verschillende punten die samenvallen. Dat valt nog wel te coderen.
Los van de technische vraag is de inhoudelijke vraag dus eigenlijk: wat
doen we met die samenvallende punten? Schuiven we de punten handmatig
uit elkaar, of voegen we ze samen met een samengesteld label als 15A-B
voor de adressen “15A” en “15B”. Dat laatste kan automatisch, maar het
is dan weer de vraag of dat wenselijk is. Er zullen vast situaties zijn
waarin je die punten niet wil mergen maar juist individueel houden. Het
hele idee is ook dat we puur adressen (en eventuele bisnummers) in OSM
stoppen en geen subadressen (busnummers en appartementnummers). Dus:
indien de adrespositie voor twee adrespunten gelijk is, moeten deze dan
automatisch worden samengevoegd tot 1 punt met een samengesteld label,
of laten we dat ter beoordeling van de mapper?
Ik ga nog even kijken naar wat checks op die straatnamen met een
gelijkaardige naam en een verschillende id. Het zou interessant zijn als
die gevallen opgepikt worden. Ik ben het ermee eens dat veel van de
foutopsporing in het algemeen best aan de JS-kant gebeurt. Daar heb je
ook je overpass-query beschikbaar. Aan de andere kant vind ik dat een
aantal basis-integriteits-dingen toch al door het python-gedeelte mogen
worden opgepikt. De loopduur van het script moet aan de andere kant ook
weer zo kort mogelijk gehouden worden. Ik denk dat het een beetje
zichzelf wijst. Een aantal checks (zoals zelfde straatnaamid,
verschillende straatnaam) hebben geen of een zeer lage kost, terwijl
deze toch een zekere basiskwaliteit van de dataset opleveren.
De scripts eerst vergelijken en evalueren lijkt me prima. Ik heb een
eigen github aangemaakt zodat het onderscheid tussen beide scripts nu
eerst helder is. Ik heb de data van de laatste conversie alvast
opgeladen samen met de webpagina en het JS. Aan de webpagina heb ik
helemaal niets gewijzigd. Aan het JS heb ik enkel de extra tag
toegevoegd, binnen een conditional.
Ik ga nog wat kleine puntjes aanpakken en het python-script wat
robuuster opbouwen. Misschien dat ik met een parallelle architectuur nog
wat snelheidswinst kan boeken. Vanaf nu kan er in elk geval weer getest
gaan worden. Ook alle problemen met de dataset die in de laatste mails
gemeld werden ga ik nader bekijken.
Bij deze dus het verzoek aan al diegenen die mee willen testen: jullie
kunnen op http://aptum.github.io/import.html mijn script testen. Het
verschil met de pagina van Sander is dat mijn pagina gebruik maakt van
de adressenlijst in plaats van de adresposities. Uiterlijk is er niets
veranderd, maar het conversiescript is vrijwel compleet nieuw. Daarnaast
heb ik een extra tag toegevoegd (CRAB:source) die weergeeft waar de
informatie uit het CRAB vandaan komt. Deze geeft aan hoe het adrespunt
bepaald is, en zegt daarmee iets over de nauwkeurigheid van de plaats
van het label. Deze tag mag niet naar OSM opgeladen worden! Graag hoor
ik het als er nog problemen gesignaleerd worden. Bij deze ook credits
voor het vele en goede werk van Sander en voor het ter beschikking
stellen van alle code!
Groeten,
Thomas
Sander Deryckere schreef op 25-10-2014 21:17:
Op 25 oktober 2014 20:57 schreef Thomas <[email protected]
<mailto:[email protected]>>:
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
[email protected]
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-be
