<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>Wil je beide lijsten (busnrs en apptnrs) los in de JSON hebben,
of samengevoegd als “subadressenlijst”? Ik had het als dat laatste
al ingebouwd, maar ik kan het natuurlijk eenvoudig weer uit elkaar
trekken. De lijsten worden toch al los van elkaar opgebouwd.<br>
<br>
Groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 29-10-2014 12:06:<br>
</div>
<blockquote
cite="mid:CABUOUO_J8MWNgxLoJYcUW1r-cMd+gmRjv88T=PVt=8sAKrtkkA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>Hoi Thomas,<br>
<br>
</div>
Net het script wat verder aangepast voor de nieuwe data,
en geuploaded naar jouw repo. Dus aan iedereen, gelieve
vanaf nu vooral <a moz-do-not-send="true"
href="http://aptum.github.io/import.html">http://aptum.github.io/import.html</a>
te testen,<br>
<br>
</div>
Kan je de appartementsnummers en busnummers als aparte
lijsten in de JSON zetten? Dan kan ik ook het script updaten
om addr:flats te ondersteunen. Lijsten zijn het best
aangezien ze gemakkelijker omgevormd kunnen worden naar de
correcte formaat. Ook die best alfabetisch sorteren voor de
diffs. En misschien enkel de lijsten aan de JSON toevoegen
indien wel degelijk (dat zal bandbreedte sparen voor de vele
adressen die geen busnummers of appartementsnummers hebben).<br>
<br>
</div>
Aangezien de overlappende en de niet overlappende nummers nu
in verschillende kolommen staan, is daar geen verschillende
CSS voor nodig. Een verschillende CSS voor de herkomst kan wel
helpen. Momenteel staat die herkomst nog in CRAB:source om de
waarden gemakkelijk te kunnen aflezen. Dus momenteel die tags
nog niet gaan uploaden.<br>
<br>
</div>
Als het goed is voor iedereen, dan breng ik die tags naar de
vorm <br>
<ul>
<li>odbl:note=CRAB:<span class="">manueleAanduidingVanGebouw</span></li>
<li><span class=""></span><span class="">odbl:note=CRAB:<span
class=""></span></span><span class=""><span class=""><span
class="">geinterpoleerdObvNevenliggendeHuisnummersGebouw</span></span></span></li>
<li><span class="">...<br>
</span></li>
</ul>
<span class="">odbl:note lijkt mij de meest neutrale van alle
discardable tags, en het voorvoegsel CRAB: kan zorgen voor
unieke CSS selectors.</span> <br>
<div><span class=""><br>
</span></div>
<div><span class="">De grootste problemen momenteel zijn de
huisnummers met een underscore. Ik kan moeilijk beslissen
als ik die naar bis, ter, ... of naar /1, /2, /3, ... breng.
Maar het overlaten aan de mapper kan er voor zorgen dat de
huisnummers met een underscore rechtstreeks geuploaded
worden.<br>
<br>
</span></div>
<div><span class="">Het andere grote probleem is de spelling van
de straatnaam. Dat is moeilijk om af te leiden met de
beperkte OSM data die ik heb in de webpagina (vooral als er
nog geen adressen in OSM zijn). Een spellingsverschil kan er
voor zorgen dat huisnummers geuploaded worden waarbij
addr:street verschilt van de straatnaam in OSM. Wat
natuurlijk voor problemen zal zorgen. Maar hierbij kan Jo
misschien helpen, of de JOSM validator. <br>
<br>
<br>
</span></div>
<div><span class="">Als die problemen opgelost zijn, dan lijken
de tools klaar, en wordt het tijd om enkele definitieve
beslissingen te maken:<br>
</span>
<ul>
<li><span class="">Huizen tekenen of niet</span></li>
<li><span class="">Aparte gebruikersnaam of niet</span></li>
<li><span class="">Welke tags moeten op de changeset</span></li>
<li><span class="">Hoe contacteren we het AGIV met
opmerkingen?</span></li>
<li><span class="">...</span></li>
</ul>
</div>
<div><span class="">Groeten,<br>
Sander<br>
</span></div>
<div><span class=""><br>
</span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 29 oktober 2014 08:39 schreef Sander
Deryckere <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sanderd17@gmail.com" target="_blank">sanderd17@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>
<div>
<div>Nog niet,<br>
<br>
</div>
eerst onze tools maken, dan kunnen we het opnieuw
presenteren.<br>
<br>
</div>
Groeten,<br>
</div>
Sander<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 29 oktober 2014 05:08 schreef
Marc Gemis <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:marc.gemis@gmail.com" target="_blank">marc.gemis@gmail.com</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 dir="ltr">Hoe zit het met het nodige
papierwerk rond de import ? Zijn daar al
vorderingen gemaakt ?
<div><br>
</div>
<div>groeten</div>
<span><font color="#888888">
<div><br>
</div>
<div>m</div>
</font></span></div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-10-26 13:18
GMT+01:00 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 code staat op <a
moz-do-not-send="true"
href="https://github.com/aptum/aptum.github.io"
target="_blank">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
moz-do-not-send="true"
href="https://github.com/sanderd17/sanderd17.github.io/"
target="_blank">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>
<div>
<div>
<blockquote 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>
<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>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<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>
</blockquote>
<br>
</div>
</div>
</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>
<br>
</div>
</div>
</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>