<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Op 26 oktober 2014 10:20 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>
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></div></div></blockquote><div>Ik veronderstel dat ze ook een vage CRAB herkomst hebben? Zoals afkomstig van interpolatie in de straat? Dan kunnen die met CSS anders gekleurd worden om meer op te vallen.<br><br></div><div>Het is ook zo dat niet de volledige straat in één keer geïmporteerd moet worden. Je kan eerst de duidelijke nummers importeren, en wachten met die probleemnummers tot de rest van de gemeente gedaan is.<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>
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></div></div></blockquote><div><br></div><div>Dus dan heb je drie adressen, met de huisnummers 10, 12 en 14, en op elk van die adressen staat het huisnummerlabel "10-14"? Ik denk dat die adressen toch sowieso gesplitst moeten worden, dus dat mergen niet moet. Maar we kunnen die info wel weer gebruiken om de huisnummers anders te markeren.<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>
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></div></div></blockquote><div>Ik zou het aan de mapper laten. Waarschijnlijk zullen de nummers meestal apart moeten blijven, dus lijkt het mergen niet zo'n goeie oplossing. <br><br></div><div>Ik vraag me ook af, als je een apartement hebt met 1 adres en 10 busnummers, krijg je dan 1 keer het adres zonder busnummer, en dan nog 10 keer het adres met een extra busnummer? Of krijg je gewoon die 10 adressen met telkens een verschillend busnummer?<br><br>In het eerste geval kan je gewoon alles wat een appartement- of busnummer bevat meteen vergeten in je Python script. In het tweede geval komt er weer een extra stap aan te pas om die te mergen.<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 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></div></div></blockquote><div>In het vorige script had ik dat gewoon omzeild door direct met straatnamen te werken, en de id's gewoon niet te gebruiken om huisnummers te groeperen per straat. Dus als huisnummers tot dezelfde straatnaam behoorden (in dezelfde postcode), dan werden ze in dezelfde json gebracht.<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>
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 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></div></div></blockquote><div><br></div><div>Zal deze meteen eens testen,<br><br></div><div>Groeten,<br></div><div>Sander<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>
<br>
Sander Deryckere schreef op 25-10-2014 21:17:<br>
</div>
<blockquote type="cite"><div><div>
<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>
<br>
<fieldset></fieldset>
<br>
</div></div><span><pre>_______________________________________________
Talk-be mailing list
<a href="mailto:Talk-be@openstreetmap.org" target="_blank">Talk-be@openstreetmap.org</a>
<a 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 href="mailto:Talk-be@openstreetmap.org" target="_blank">Talk-be@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-be" target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a><br>
<br></blockquote></div><br></div></div>