<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">De herkomst voor de punten die in mijn
script samenvallen is vaak/meestal/altijd onderling niet
verschillend, noch wijkt die herkomst af van de andere punten in
de straat. Het gaat sowieso niet om busnummers /
appartementnummers. Die heb ik net als in jouw script niet
opgenomen. Het gaat steeds om verschillende adressen die dezelfde
positie meegekregen hebben. Soms gaat het om verschillende nummers
(vb 21 en 23) die samenvallen, soms om verschillende bisnummers
(vb 25A en 25B) die samenvallen. Het zijn dus wel steeds echt
verschillende adressen.<br>
<br>
In deze Adressenlijst vormt elke huisnummer-busnummer combinatie
een eigen record. Stel: je hebt 2 huisnummers: nr 4 en nr 6. Beide
behoren tot 1 gebouw. Voor beide nummers heb je 5 busnummers:
bus1, bus2, bus3, bus4 en bus5. In de adressenlijst heb je dan 12
records (2 x 1 adres zonder busnummer en 2 x 5 adressen met
busnummer). Het huisnummerr-label (HNRLABEL) is voor alle 12
records hetzelfde: “4-6”. In mijn script registreer ik (net zo als
in het script van Sander) de adressen in een dictionary per straat
met als key het huisnummer. Daarmee worden al die verschillende
busnummer / appartementnummers genegeerd. Omdat de informatie
verder toch gelijk is, is het overschrijven op basis van
huisnummer als key in principe voldoende, en hoeft er verder niets
gemerged te worden.<br>
<br>
Wat daar inhoudelijk moet gebeuren hangt af van de situatie ter
plaatse, denk ik. Het meest handig is denk ik een FIXME-tag die
aangeeft dat de punten samenvallen. Er moet immers steeds iets
gebeuren met die punten. Daar kan dan eventueel het
huisnummer-label aan worden toegevoegd, maar dat moeten we enkel
doen als we dat een aanvaardbare situatie vinden (dat die punten
worden samengevoegd tot 1 adres met zo'n samengesteld label). Als
we dat samenvoegen in beginsel onwenselijk vinden (zo veel
mogelijk los) dan moeten we dat label misschien juist niet
aanleveren en enkel die FIXME-tag instellen.<br>
<br>
Dat sorteren heb ik over het hoofd gezien. Ik pas het aan; bij de
volgende omzetting zal het weer netjes geordend staan.<br>
<br>
Het gebruiken van discardable keys is een goed punt; dat ga ik nog
even verder bekijken. Ook het enkel gebruiken van discardable keys
in de wrong-laag lijkt me een goed punt. Ook de upload=no ga ik
toepassen. Dat is allemaal een beetje voer voor het javascript;
daar heb ik nog maar weinig aandacht aan besteed. Ik pak het op.<br>
<br>
Verder is er nog iets gek aan de hand met het bepalen van de
“Missing”-punten, zowel in mijn script als die van Sander. Voor
veel plaatsen werkt dat prima. Nu keek ik naar postcode 9000,
straat “Hoogpoort”. Daar lijkt het helemaal niet te werken (voor
de hele postcode); niet bij jouw script en niet bij mijn script.
In heel postcode 9000 (Gent) zou geen enkel “Wrong” punt zijn; dat
kan niet. Mijn script levert geen “NoPos” punten op, dus dat is
wel anders, maar de bestaande adressen in OSM worden niet
opgepikt. Dat terwijl voor bijvoorbeeld postcode 8400 alles
perfect gaat.<br>
<br>
Als ik de requests bekijk, krijgt JS netjes een JSON antwoord van
overpass, maar voor postcode 9000 is die leeg (8400 is netjes
gevuld). Dat doet me denken aan een soort timeout van je query.
Handmatig het query invoeren levert overigens ook geen resultaten
op. Misschien heeft het specifiek met Gent te maken, dat daar het
selectiemechanisme om tot de postcode te beperken niet werkt of
zo? Dat moeten we nog even goed bekijken.<br>
<br>
Overigens zag ik dat ik nog de oude variant van de webpagina en
het JS-script gebruik. Die ga ik ook netjes updaten.<br>
<br>
Groeten,<br>
Thomas<br>
<br>
Jo schreef op 26-10-2014 11:41:<br>
</div>
<blockquote
cite="mid:CAJ6DwMD9NTrE0OVvf9TdCmUxnOLZM2+a0D-2h+CSHtqSyeFCRg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>Het lijkt mij ook aangewezen om voor de nummers die
in de wronglaag worden geladen geen
addr:housenumber/addr:street te gebruiken. Daar zou ik
enkel discardable keys gebruiken, die we dan zichtbaar
maken mbv MapCSS. (Wel Expert modus gebruiken, anders
worden ze niet getoond)<br>
<br>
Zo ontstaat er geen verwarring bij het samenvoegen van
die lagen. Als die nodes enkel discardable keys
bevatten, zoals:<br>
<br>
"tiger:upload_uuid", "tiger:tlid", "tiger:source",
"tiger:separated", "geobase:datasetName",
"geobase:uuid", "sub_sea:type", "odbl", "odbl:note",
"yh:LINE_NAME", "yh:LINE_NUM", "yh:STRUCTURE",
"yh:TOTYUMONO", "yh:TYPE", "yh:WIDTH_RANK"));<br>
<br>
</div>
dan worden die allemaal weggehaald en dan zal de validator
daarover klagen. Even testen. Ai, de tags en hun waardes
worden pas weggehaald na de validatie. Dat moet nog beter
kunnen.<br>
<br>
<br>
</div>
Wat me ook belangrijk lijkt, is om voor die wrong-laag,
upload=no aan te zetten in het XML-bestand:<br>
<br>
<osm version="0.6" upload="no" generator="Python/JS
script"><br>
<changeset><br>
<tag k="source" v="CRAB"/><br>
</changeset><br>
<br>
</div>
Dan zal JOSM tenminste toch al klagen, als je die laag zonder
meer zou proberen door te sturen.<br>
<br>
</div>
<div>Met die changeset/source tags wordt spijtig genoeg geen
rekening gehouden, voor zover ik kan zien. Maar toch lijkt het
me wel goed om die toe te voegen.<br>
</div>
<div><br>
</div>
Jo<br>
<div><br>
<br>
<div>
<div><br>
<br>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 26 oktober 2014 11:09 schreef Jo <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:winfixit@gmail.com" target="_blank">winfixit@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Voor tags waarvan je niet wilt dat ze naar OSM worden
opgeladen is het het beste om tags te gebruiken die
automatisch zullen worden verwijderd, voorbeelden zijn
created_by en odbl. Laat me weten als er meer nodig
zijn. Ze zitten ergens in de broncode van JOSM.<br>
<br>
</div>
Ik zou dus die tags gebruiken ipv CRAB:source.<br>
<br>
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>:
<div>
<div class="h5"><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>
<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>
<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"
target="_blank">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>
</div>
</div>
<br>
</div>
</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>