<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>Over het beschikbaar maken van postcode en gemeentenaam: de
postcode wordt reeds meegegeven in de JSON bestanden en de
gemeentenaam kan daaraan worden toegevoegd. Met twee regels code
heb ik dat voor elkaar. Echter, daarbij moet ik wel de nodige
extra checks inbouwen voor de gemeente-id en de naam en de mate
waarin deze 1 op 1 matchen om ook hierin eenduidigheid te
garanderen. Daarnaast biedt dit ook de mogelijkheid om een extra
verwantschap tussen gemeente en postcode te bestuderen. Zoals ik
uit de voorgaande mails begrepen heb matchen die niet overal. Dat
zorgt voor gesplitste straten met potentieel andere schrijfwijzen.
In de suggestie van Jo om iets met straat-relaties te doen kan dit
punt ook voor problemen zorgen. Mijn import-script kan deze
gevallen signaleren. Daarmee kan weer een aanvullend stuk
zekerheid over de kwaliteit van de brondata worden ingebouwd.<br>
<br>
In de discussie over discardable keys denk ik dat de sleutel ligt
in het gebruik van de addr:flats tag die de lijst met
busnummers/appartementnummers weergeeft. Het is namelijk die
informatie die door de gebruikers echt gezien moet worden. Voor
die functie is een discardable tag ook niet echt inzetbaar, juist
omdat de informatie erin verborgen wordt voor de gebruiker. Met de
lijst van busnr/apptnr is dat afgedekt. De rest kan dan inderdaad
met een discardable key en wat mapCSS worden weergegeven.<br>
<br>
De CRAB:huisnrlabel kan als als tag weggehaald worden uit de
javascript. Voorlopig kan dit in de JSON blijven staan. Op die
manier kan de informatie gebruikt worden door het script van
Sander om verder gegevens aan elkaar te matchen. CRAB:message
verdwijnt dus met het toevoegen van de addr:flats. CRAB-source
heeft weinig inhoudelijke betekenis en kan met een discardable-tag
worden vormgegeven met mapCSS ter ondersteuning bij het mappen. De
fixme-tag inzetten bij specifieke herkomsten is ook een goed idee,
denk ik.<br>
<br>
Die afwijkende huisnummerlabels zijn toch iets bijzonders. Dat
wijst toch op een vage integratie van verschillende databronnen.
Mogelijk dat dat probleem verholpen wordt als alle gemeenten
eenmaal hun adressenbestand gevalideerd hebben.<br>
<br>
Het standaardiseren van de letters is een lastige kwestie. Die
functie inbouwen in het importeer-script is misschien niet heel
handig, omdat het matchen met OSM sowieso in de javascript
gebeurt. Dit standaardiseren op 2 plaatsen regelen lijkt me zeer
onhandig. Daarom ben ik voorstander van de gegevens uit het CRAB
niet te standaardiseren naar al dan niet met hoofdletter bij het
omzetten naar de JSON bestanden. Ik weet niet hoe consistent de
gegevens in OSM zijn op dit punt. Als nu al in OSM beide varianten
voor komen, dan zal dat ook in de toekomst mogelijk heel lastig te
vermijden zijn, denk ik. Maar dat hangt dus af van de huidige
status van OSM en die ken ik niet. Verder deel ik de visie van
Sander op de schrijfwijze.<br>
<br>
Het script dat Jo beschrijft om gemakkelijker de CRAB-gegevens te
mergen met OSM lijkt mij ook zeer handig. Daarbij zou ik wel heel
erg opletten met het inladen van informatie uit OSM in de laag die
geïmporteerd wordt. Ook de tegenovergestelde handeling van het
automatisch doorvoeren van informatie uit de import in de
OSM-data-laag lijkt me 'gevaarlijk' omdat eventuele fouten dan
weer lastig te spotten zijn. Een wizard die voor elk punt de match
weergeeft en slechts een druk op de knop vereist om de tags over
te laden lijkt me dan weer prima. Op welke manier zie jij die
koppeling tussen de CRAB-adrespunten en de OSM-gebouwcontouren
voor je?<br>
<br>
Het tweede script vind ik lastiger. Het omzetten van de tags vind
ik risicovol omdat op die manier een derde parse plaatsvindt. Er
zijn nu al twee omzettingen: CRAB → JSON → JOSM. Ik denk dat die
alternatieve tags beter in de javascript gerealiseerd kunnen
worden. De associatedStreet-relatie is voor zover ik begrijp toch
wat controversieel vanwege de toegevoegde complexiteit en de
problemen van beginnende mappers met relaties. Hoewel ik de
meerwaarde van een dergelijke relatie zeker zie, is dit ook een
extra verwevenheid tussen de brondata en OSM die met de hoogste
voorzichtigheid moet worden toegepast. Ook de opmerking van Sander
over de potentieel verkeerde relaties lijkt me een aandachtspunt.
Wanneer het script hiermee rekening houdt lijkt het me potentieel
een zeer waardevolle toevoeging!<br>
<br>
Ik ga nu mijn conversie-script aanpassen met de bovengenoemde
wijzigingen mbt de tags en de extra informatie. Ik ga een stuk
documentatie opstellen over de inhoud en de structuur van de
JSON-bestanden zodat mensen die aan andere scripts werken die
hierop aansluiten een duidelijke referentie hebben over het hoe en
wat van de beschikbare data. Ik ga de extra controle inbouwen voor
gemeente-postcode. Daarmee staat het conversie-script dan zo
ongeveer op punt. Als dat eenmaal getest is plaats ik mijn
conversiescript ook op github. Alle command-line interactie heb ik
nu ook bijna op orde, waarmee het script ook geschikt wordt om het
daglicht te zien...<br>
<br>
Sander: de aanpassingen die je al maakte aan de website vind ik
zeer geslaagd. De herbestemming van de Missing w/o pos lijkt mij
ook positief. Een punt zonder locatie wordt al afgevangen door
mijn conversiescript. Wat voorwaardelijke opmaak van de tabel kan
er ook voor zorgen dat de “Wrong” kolom leeg blijft, tenzij er 1
of meer punten gevonden worden. Zo wordt het geheel wat rustiger
en wordt tegelijkertijd de aandacht meer gevestigd op specifieke
potentiële fouten in OSM. Het proces van de foute adrespunten
inladen en OSM verbeteren staat immers wat los van de werkwijze
van het toevoegen van nieuwe adrespunten. Door de opmaak echt te
laten contrasteren kan daar alsnog de aandacht voor gevestigd
worden. Lijkt het je wat om in elk geval die conditional rond die
<a> toe te voegen? Het stylen is dan van ondergeschikt
belang.<br>
<br>
Ik regel ook de toegang voor je tot de repo.<br>
<br>
Groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 28-10-2014 17:39:<br>
</div>
<blockquote
cite="mid:CABUOUO8Z3m5e1H58r4jaYROLr2nhrc21q2rY3x-+ZsOuYkUPhA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Ik heb mij bezig gehouden met het maken van unit tests.
De vele regexen zorgden vaak voor bugs die al eens vroeger
opgelost waren.<br>
<br>
</div>
<div>Er is ondertussen ook ondersteuning voor "bis", "ter"
en "/1", "/2", ... Ook straatnamen met een streepje
verschil ("Sint-Jansstraat" en "Sint Jansstraat") worden
nu vergeleken.<br>
<br>
</div>
<div>De dubbele huisnummers worden nu ook vergeleken op
basis van het huisnrlabel (wat enkel zal werken met de
data van Thomas). Een adres wordt dus als "matching"
beschouwd indien het huisnummer van OSM overeenkomt met
het huisnummer van CRAB, of met het huisnummerlabel van
CRAB. Afhankelijk van de lokale situatie kan een mapper
dan kiezen om meerdere samenvallende huisnummers te
splitsen, of samen te laten. Beiden moeten herkend worden.<br>
</div>
<div><br>
</div>
Thomas, aangezien het duidelijk is dat we met de
adressenlijst gaan verder werken, zou ik commit access
kunnen krijgen voor jouw repo? Dan kan ik verder werken met
jouw data, en kan mijn adres gesloten worden. Ik denk om de
no-position lijst te vervangen door een lijst van
samenvallende adressen (a.d.h.v het huisnummerlabel
eenvoudig te bepalen). Dat is net zoals vroeger, een simpele
splitsing tussen de gemakkelijke gevallen en de moeilijke
gevallen, wat de productiviteit enkel maar ten goede kan
komen. Daarvoor is natuurlijk jouw data nodig.<br>
<br>
</div>
<div>Jo, een script dat straten met dezelfde naam zoekt is idd
handig. Vooral met straten zonder adres valt dit moeilijk te
controleren op de webpagina (tenzij ik een nieuwe overpass
query maak, en de gebruikers nog wat langer moeten wachten).
Dus is het maar al te gemakkelijk om bij een straat als
"Guido Gezellestraat" de adressen met "G. Gezellestraat" te
importeren. Dat is zeker iets wat we moeten voorkomen. Ik
denk echter niet dat die associatedStreet relaties nodig
zijn (en dan heb je ook de postcode niet nodig).<br>
<br>
</div>
Groeten,<br>
</div>
Sander<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 28 oktober 2014 14:44 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"><span class="">> 2) CRAB:message. Deze
bevat informatie over het al dan niet aanwezig zijn van
busnummers en appartementnummers op dat specifieke
adrespunt. Deze gegevens hoeven niet in OSM opgenomen te
worden maar kunnen (zeker nu in de testfase)
verhelderend werken.</span>
<div class="gmail_extra">
<div class="gmail_quote"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
</span>
<p dir="ltr">Er is een addr:flats tag die kan
gebruikt worden ( <a moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/Key:addr:housenumber#Detailed_subkeys"
target="_blank">http://wiki.openstreetmap.org/wiki/Key:addr:housenumber#Detailed_subkeys</a>).
Ik weet niet wat nu net het verschil is tussen
een busnummer en een appartementsnummer, maar
het is volgens mij objectieve, verifieerbare een
geografische info, dus als die beschikbaar is,
dan moeten we ze niet persé uit OSM weren.</p>
</blockquote>
<div><br>
</div>
</span>
<div>Het lijkt mij ook het beste om deze info te
parsen en onder te brengen onder addr:flats, waarbij
we geen onderscheid hoeven te maken tussen
apartmentnrs of busnrs.<br>
<br>
</div>
<div>Wellicht best wel sorteren en dan gescheiden door
komma's zonder verdere spaties.<br>
<br>
</div>
<div>Mijn eerste CRAB: crap is ondertussen (per
ongeluk) doorgestuurd naar de server. Daar gaan
zeker en vast nog meer ongelukken mee gebeuren.<br>
<br>
</div>
<div>Verder werk ik aan een Pythonscript dat binnen
JOSM werkt om te helpen bij het integreren van de
CRAB-data met wat er reeds in OSM zit. Om zoveel
mogelijk adressen automatisch te koppelen aan
gebouwcontouren. Zo blijft er meer tijd over om de
gebouwcontouren zelf dan nauwkeuriger in te tekenen.<br>
<br>
</div>
<div>De MapCSS is bijna klaar.<br>
<br>
Ik heb ook een pythonscriptje gemaakt (eigenlijk
Jython) dat jullie output omzet naar data met
discardable tags en dat een associatedStreetrelatie
aanmaakt. Waarbij hij ook meteen op zoek gaat naar
straten met dezelfde naam.<br>
Het zou daarbij helpen om postcode en gemeente ook
aangeleverd te krijgen in discardable tags.<span
class="HOEnZb"><font color="#888888"><br>
</font></span></div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>Jo<br>
</div>
</font></span></div>
</div>
</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>
<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>