<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 }
-->
</style><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>
<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>
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>
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>
Groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 25-10-2014 20:17:<br>
</div>
<blockquote
cite="mid:CABUOUO9pfymgTV2huEGpXqgLGNFsRe3OiwBVZcNqK0CgpmdyaA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 25 oktober 2014 18:46 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:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Ik ben inmiddels bijna klaar met het nieuwe script
dat de adressenlijst (in plaats van de adresposities)
moet beschikbaar stellen via de website die Sander
gemaakt heeft.<br>
<br>
</div>
</div>
</blockquote>
<div>Geweldig nieuws ;)<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> Het oude script kon ik maar voor kleine stukjes
hergebruiken omdat het bestandsformaat en de
datastructuur toch redelijk anders zijn. Ik ben
uitgegaan van precies dezelfde JSON-uitwisselbestanden
te genereren zodat de website wel volledig compatibel
is (op misschien wat extra tags in javascript na dan).
Het was niet eenvoudig om een goed werkend script op
te zetten vanwege de door Sander genoemde
coderingsproblemen en vanwege het feit dat deze
adressenlijst in feite 1 grote tabel is tegenover de
adresposities die in feite een 'database' zijn of een
collectie van kleinere tabellen. Daardoor liep ik
tegen nogal wat geheugenprobleempjes aan. <br>
</div>
</div>
</blockquote>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> De beschikbare modules om GML in te lezen in
python bleken niet robuust genoeg om én met de vreemde
codering om te gaan én met de enorme omvang van het
bestand (ca. 3GB). Daarom heb ik ervoor gekozen om als
bron het shp-bestand te gebruiken (dat 'slechts' 1GB
in omvang is, door een efficiëntere datastructuur).
Daarmee kreeg ik wel alles aan de praat.<br>
</div>
</div>
</blockquote>
<div><br>
<div>Ik had ook al wat zaken opgezocht om het GML bestand
te splitsen en pas daarna te verwerken, om zo slechts
XML kind per kind in het geheugen te laden en geen
geheugen tekort te komen. Maar dat werd een serieus
gepruts, en ik verwachtte ook dat het te traag zou zijn
door de vele lees en schrijf operaties.<br>
<br>
</div>
Geheugenproblemen had ik sowieso verwacht, want zelft met
het huidige script moet ik zorgen dat Firefox en JOSM
alletwee gesloten zijn voor ik het script start. Anders
loopt mijn computer onherroepelijk vast in het
page-swapping. <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> <br>
Ik ben nu een aantal extra checks in de code aan het
inbouwen en te kijken wat handig is qua extra tags
(evt. gekoppeld aan wat CSS). Het blijft ook wat
worstelen met de omvang. Mijn eerste tests werken in
elk geval bij mij. Als het een beetje wil komt dat dus
dit weekend af. Ook alle gemelde 'problemen' met de
huidige dataset ga ik bekijken in deze nieuwe dataset.<br>
<br>
Voor alle duidelijkheid: voor de gebruikers verandert
er weinig tot niets tegenover de huidige versie.
Belangrijkste wijzigingen zijn het feit dat er punten
zonder positie zullen zijn en dat er misschien wat
extra tags automatisch ingeladen worden in JOSM als je
een straat importeert. Die extra tags moeten helpen om
de informatie naar waarde te schatten. In elk geval in
deze eerste test-fase kunnen ze zeer handig zijn om
beter bepaalde zaken te begrijpen.<br>
<br>
Ik heb nu voor het patroon “CRAB:key” gekozen als key
voor de tags die ik in JOSM inlaad maar die niet in
OSM thuishoren. Zijn er alternatieve patronen voor dit
soort “tijdelijke” werk-tags die OSM nooit mogen
bereiken? In de link die Marc eerder doorstuurde lees
ik vooral dat onze Nederlanders een aantal overbodige
tags in OSM hebben zitten n.a.v. een aantal imports.
Het lijkt me op zich een mooi streven om al dat soort
tags buiten OSM te houden, wat onze 'import' betreft.<br>
<br>
Moet er overigens nog een “source=CRAB”-tag toegevoegd
worden, of willen we dit juist vermijden omdat het
toch al niet om een automatische import gaat?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>source=* tags zijn beter op hun plaats op het changeset
object dan op objecten in de DB. Natuurlijk kan een
specifieke bron (zoals afkomstig van de voordeur, gebouw
or perceel) wel op het object zelf. <br>
<br>
</div>
<div>Postcode en gemeente zijn sowieso niet nodig, die
kunnen gerust uit de JSON gelaten worden. Welke andere
keys twijfel je nog over?<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> <br>
Groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 25-10-2014 17:52:<br>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Hmm, blijkbaar hebben alle
tabellen een mogelijkheid tot
deleten via "einddatum".<br>
<br>
</div>
En blijkbaar gaat dat niet altijd
samen. <br>
<br>
</div>
Ik heb nu net eens het script laten
lopen met alle records waar "einddatum"
bijstond genegeerd, en dat resulteert
vooral in terreinobjecten die genegeerd
worden, waardoor er vooral extra
adressen zonder positie zijn :/<br>
<br>
</div>
Heb ook eens de Koningin Louisa-Marialaan
bekeken met die nieuwe data, en daar
blijkt er nu geen verschil te zijn O_o<br>
<br>
</div>
Dus denk ik dat ik het script nog niet zal
aanpassen.<br>
<br>
</div>
Groeten,<br>
</div>
Sander<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 25 oktober 2014
16:11 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:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 25 oktober
2014 14:48 schreef Sus Verhoeven <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:susvhv@gmail.com"
target="_blank">susvhv@gmail.com</a>></span>:<span><br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>
<div>In Leopoldsburg 3970 op
de Koningin-Louisalaan is er
in CRAB een hele reeks
huizen met dubbele
huisnummers niet op dezelfde
plaats, in GRB staat er maar
een van deze reeksen. <br>
</div>
Eigenaardig.<br>
<br>
</div>
Sus<br>
</div>
<br>
</blockquote>
<div><br>
</div>
</span>
<div>Dit lijkt een straat die onlangs
hernummerd is, en waarvan de oude
nummers nog niet verwijderd zijn.<br>
<br>
</div>
<div>Ook de GRB basiskaart is niet
volledig duidelijk. Zo is er daar
een nummer 13-125 te zien, wat een
veel te grote range is om te kunnen
kloppen. Ik zou voorstellen om eens
ter plaatse te gaan kijken wat er nu
echt juist is.<br>
<br>
</div>
<div>Volgens de documentatie van de
databases zouden ze verouderde
nummers moeten deleten door er een
"einddatum" aan te geven. In het
extract script test ik ook op die
einddatum, dus als ze correct
verwijderd zijn, dan zouden ze niet
meer in de data mogen voorkomen. <br>
<br>
</div>
<div>Het is natuurlijk niet eenvoudig
om in dit geval te controleren als
het script of de data fout is, omdat
het nu eenmaal niet vaak gebeurt dat
een straat hernummerd wordt.<br>
<br>
</div>
<div>In Leuven werd onlangs een straat
hernummerd (zie <a
moz-do-not-send="true"
href="http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793"
target="_blank">http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793</a>)
en ik denk dat de CRAB data
overeenkomt met de huidige data, dus
dat de verwijderde nummers wel
degelijk niet meer zichtbaar zijn.
Maar 1 voorbeeld is natuurlijk wat
weinig om op voort te gaan.<br>
<br>
</div>
<div>Groeten,<br>
</div>
<div>Sander<br>
</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</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>
</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>