De code staat op https://github.com/aptum/aptum.github.io. De code van
het python-conversiescript staat er nog niet op omdat ik nog wat dingen
aan het omschuiven ben. Ik probeer dat script zo snel mogelijk ook
daarbij te zetten. De nieuwste variant van het javascript en de website
(met uitzondering van die twee regels code om 'mijn' tag in JOSM in te
laden; regels 358-359) kun je bij Sander vinden:
https://github.com/sanderd17/sanderd17.github.io/
Het inladen van gegevens uit de overpass is op zich wel mogelijk, maar
we moeten denk ik wel heel erg opletten dat het geen allegaartje wordt.
CRAB en OSM strikt gescheiden houden heeft misschien ook wel voordelen;
tenzij je een specifiek doel voor ogen hebt?
Groeten,
Thomas
Jo schreef op 26-10-2014 12:58:
Hallo Thomas,
Waar staat de broncode nu? Ik had het graag nog 's bekeken. Ook de JS
die ik de vorige keer gemist heb... Is er een mogelijkheid om wat je
afhaalt met Overpass ook mee te geven naar JOSM? Of is dat niet zo'n
goed idee.
Van zodra duidelijk is welke discardable tags je gebruikt, zal ik een
MapCSS-stijl maken.
Jo
Op 26 oktober 2014 10:20 schreef Thomas <o...@aptum.nl
<mailto:o...@aptum.nl>>:
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 <o...@aptum.nl
<mailto: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 <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
