<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8">
<title></title>
<meta name="GENERATOR" content="LibreOffice 4.0.3.3 (Windows)">
<style type="text/css">
<!--
@page { margin: 2cm }
P { margin-bottom: 0.21cm }
A:link { so-language: zxx }
-->
</style>De code staat op <a class="moz-txt-link-freetext" href="https://github.com/aptum/aptum.github.io">https://github.com/aptum/aptum.github.io</a>. 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: <a class="moz-txt-link-freetext" href="https://github.com/sanderd17/sanderd17.github.io/">https://github.com/sanderd17/sanderd17.github.io/</a> <br>
<br>
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?<br>
<br>
Groeten,<br>
Thomas<br>
<br>
Jo schreef op 26-10-2014 12:58:<br>
</div>
<blockquote
cite="mid:CAJ6DwMDC5sZYsbR3T=iH2mM-PTsHEcnjcnx8r-B2Nk4mstj-qg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Hallo Thomas,<br>
<br>
</div>
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.<br>
<br>
Van zodra duidelijk is welke discardable tags je gebruikt, zal
ik een MapCSS-stijl maken.<br>
<br>
</div>
Jo<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 26 oktober 2014 10:20 schreef Thomas
<span dir="ltr"><<a moz-do-not-send="true"
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> 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). <br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Bij deze dus het verzoek aan al diegenen die mee willen
testen: jullie kunnen op <a moz-do-not-send="true"
href="http://aptum.github.io/import.html"
target="_blank">http://aptum.github.io/import.html</a>
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!<br>
<br>
Groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 25-10-2014 21:17:<br>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<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
moz-do-not-send="true"
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>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<span class="">
<pre>_______________________________________________
Talk-be mailing list
<a moz-do-not-send="true" href="mailto:Talk-be@openstreetmap.org" target="_blank">Talk-be@openstreetmap.org</a>
<a moz-do-not-send="true" href="https://lists.openstreetmap.org/listinfo/talk-be" target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a>
</pre>
</span></blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Talk-be mailing list<br>
<a moz-do-not-send="true"
href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
<a moz-do-not-send="true"
href="https://lists.openstreetmap.org/listinfo/talk-be"
target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Talk-be mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-be">https://lists.openstreetmap.org/listinfo/talk-be</a>
</pre>
</blockquote>
<br>
</body>
</html>