<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 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 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 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 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 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">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>