<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Bedankt voor alle informatie! Ik kom
nog maar net kijken bij OSM en had de import-list nog niet gezien.
Inmiddels heb ik alle relevante berichten van vorig jaar even
doorgenomen. Ik begrijp, samen met jullie informatie, nu een stuk
beter waar het geheel op hapert.<br>
<br>
Zoals ik het nu begrijp zijn er een viertal discussiepunten (los
van het meningsverschil over het al dan niet uitvoeren van de
“import” met een dedicated user-account):<br>
1) De conceptuele aanpak van de data: wat willen we op welke
manier in OSM hebben?<br>
2) De beoordeling van de kwaliteit van de data: hoe betrouwbaar
zijn de gegevens?<br>
3) De methode van de initiële import.<br>
4) De methode om de dataset up-to-date te houden<br>
<br>
Uit wat ik allemaal gelezen heb leid ik af dat er al heel veel
inspanningen geleverd zijn. Binnen de BE-community was er
enigszins overeenstemming, maar op de import-lijst was die er
niet. <br>
<br>
Het eerste discussiepunt lijkt altijd voor- en tegenstanders te
hebben van een bepaalde visie. Naar mijn mening is overeenstemming
lastig te bereiken omdat de achterliggende problematiek niet
uitgeklaard is dan wel kan worden. Het belangrijkste punt lijkt te
zijn of adresgegevens in een punt of als polygoon (de woning)
moeten worden geïmporteerd. Feit lijkt me dat gewoon niet helder
is wat een adres nu juist is. Verwijst een adres naar een
kadastraal perceel, een fysiek gebouw, een woon-eenheid binnen een
gebouw, een toegangspunt tot een privaat domein, een fysieke
voordeur, een brievenbus, etc. Eigenlijk enkel die eerste durf ik
echt te ontkennen (daar dienen kadastrale nummers immers voor).
Voor de rest is het begrip “adres” volgens mij gewoon niet nader
omschreven. Adressen werken omdat iedereen voor elk individueel
geval opnieuw beoordeelt waar in dat specifieke geval het adres
naar verwijst. Dat in een objectief, wereldwijd systeem te vatten
is zeer ambitieus.<br>
<br>
Dat neemt natuurlijk niet weg dat de discussie wel gevoerd moet
worden (en dat is hij eigenlijk al, tot in den treure). Niemand
zal ontkennen dat beide systemen (nog los van de vele variaties op
deze systemen, verweven met meer of minder zaken koppelen in
relaties) voor- en nadelen hebben. Mijn gevoel zegt me dat een
pragmatische aanpak de enige manier is om vooruit te geraken. Ik
denk dat feitelijke omstandigheden (de wijze om de dataset
up-to-date te houden, de afwezigheid van gebouw-polygonen in een
groot deel van Vlaanderen) eigenlijk maken dat het héél lastig
wordt om enkel adresgegevens op polygonen te registreren. Ik denk
dat je niet ontsnapt om in sommige gevallen adresgegevens op een
punt te zetten. In het licht van consequent zaken op dezelfde
manier te doen lijken mij de punten dan het meest aangewezen. <br>
<br>
Een ander argument is meer uit de praktijk. Ik heb op een aantal
plaatsen gekeken waar gebouw-polygonen ingetekend zijn en waar de
adres-punten uit het CRAB niet op het overeenkomstige polygoon
vallen. Naar mijn idee staat het punt precies in het centroid van
het polygoon van het gebouw zoals dat bij AGIV gekend is. Daar
waar gebouw-polygonen beschikbaar zijn, zijn ze vaak ingetekend op
basis van een luchtfoto (die op die schaal toch een aanzienlijke
vertekening heeft). In vrijwel alle gevallen die ik bekeken heb is
het CRAB-adrespunt nauwkeuriger gepositioneerd dan de polygoon die
in OSM aanwezig is. Dat neemt natuurlijk niet weg dat er ook
fouten in het CRAB zitten.<br>
<br>
Ik wil hiermee geen oude koeien uit de gracht halen. Ik weet dat
het uitvoerig blijven discussiëren de community niet verder
richting consensus schuift en dat het zeer frustrerend is voor de
leden die hier heel veel moeite in stoppen om het te laten werken.
<br>
<br>
Los van deze conceptuele keuze zijn de andere drie aspecten eerder
technisch/praktisch van aard. Wanneer de methodologie gekozen is,
zal een initiële test om de kwaliteit van de data te beoordelen
niet zo'n probleem zijn denk ik. Zoals ik het nu begrijp is het
belangrijkste struikelblok het “updateable” maken van de gegevens.
Sander legt met zijn bericht een hele hoop inhoudelijke zaken op
tafel. Hoewel ik nieuw ben bij OSM heb ik wel enige affiniteit met
GIS en ga ik me hier verder in verdiepen om misschien zelf ook bij
te kunnen dragen aan de technische aspecten. <br>
<br>
Volgens mij schetst Sander terecht dat de originele piste niet zo
handig is met zicht op het onderhouden van de gegevens. Ik heb
beide andere methoden even uitgeprobeerd. Via
<a class="moz-txt-link-freetext" href="http://sanderd17.github.io/8840.html">http://sanderd17.github.io/8840.html</a> lijken de punten steeds in
een perfecte verticale lijn te liggen. Volgens mij gaat daar nog
iets verkeerd in het script dat de OSM-bestanden opstelt. Maar
misschien doe ik ook wel iets verkeerd hoor... De wiki pagina
lijkt dan weer prima te functioneren.<br>
<br>
Persoonlijk vind ik het om het even op welke manier de taken
beheerd worden. Naar mijn mening zullen de “imports” toch eerder
door ervaren leden gebeuren. Het hebben van een flashy interface
met mooie kaart die de status netjes weergeeft vind ik dan niet
belangrijk.<br>
<br>
Belangrijker is de opzet om het geheel te kunnen updaten in de
toekomst. Hoewel ik me nog in de technische aspecten moet
verdiepen, lijkt het me essentieel om een tool te hebben die een
soort van diff kan maken tussen een (geupdate) CRAB-dataset en de
OSM-situatie. Die gegevens moeten dus gematcht worden met elkaar.
In de situatie dat een adrespunt boven een niet-overeenkomstig
gebouw-polygoon (met eigen adres-gegevens) komt te liggen, lijkt
het me heel lastig die situatie goed op te lossen. Op het eerste
zicht is dat ook een probleem dat zich best vaak zal voordoen. Bij
de initiële import gebouw-polygonen verplaatsen naar waar ze horen
lijkt me lastig, omdat we geen dataset hebben waarmee we dat
nauwkeurig kunnen doen. Overtekenen van een luchtfoto is toch echt
behelpen. Daarentegen zal in veruit de meeste gevallen het
adres-punt vanuit het CRAB wel op een “juiste” locatie liggen (het
centroïd van het gebouw-polygoon). In zo'n situatie de locatie van
het punt weggooien en de adresgegevens mergen met het polygoon dat
kennelijk daarmee overeenstemt lijkt mij echt knoeien. Daarnaast
zal ter plaatse gaan kijken ook weinig oplossen. De precieze
vormen van een gebouw op enkele meters nauwkeurig bepalen zonder
professionele apparatuur lijkt mij zeer lastig.<br>
<br>
Ik zeg dit niet om mijn eerdere standpunt over het al dan niet in
stand houden van de adressen als punten te herhalen. Ik wil enkel
aangeven dat het volgens mij heel lastig wordt als die adrespunten
niet gehandhaafd worden. Ik kan me geen algoritme voorstellen dat
in zo'n situatie de punten aan de polygonen weet te matchen,
wanneer zo'n polygoon niet precies onder zo'n punt ligt. Een soort
van afstand-algoritme zal niet helpen omdat er in veel gevallen
een naburig gebouw dichter bij het adrespunt ligt dan het
daadwerkelijk overeenkomstige gebouw-polygoon.<br>
<br>
Omgekeerd denk ik persoonlijk dat de adres-punten zouden kunnen
helpen bij het corrigeren van de locatie van gebouwen. De vorm van
een gebouw is doorgaans rechthoekig. De oriëntatie is doorgaans
loodrecht <br>
<br>
Volgens mij komt het er eigenlijk op neer dat het veel eenvoudiger
zou zijn als we ook alle gebouw-contouren zouden hebben. Maar daar
zal iedereen het wel mee eens zijn. Mijn mening op dit moment is
dus dat het in deze realiteit heel erg lastig wordt om het te doen
met enkel adresgegevens op gebouwen. Daarnaast zie ik weinig grote
bezwaren tegen het in stand houden van de adrespunten. Naar mijn
mening is de meest pragmatische keuze dus het importeren van de
adresgegevens als punt en het updaten van die punten. Dat kan
volgens mij het eenvoudigst gedaan worden door een CRAB-id mee te
importeren (ik besef dat dit vloeken in de kerk is...). Echter,
ook met afstands-algoritmen moet er een en ander mogelijk zijn.<br>
<br>
Daarnaast lijkt het mij belangrijk dat het hele proces goed
geautomatiseerd kan verlopen. Aan een initiële import die niet te
onderhouden valt heeft niemand wat. Integendeel; het eventueel
moeten mergen van zo'n hoop data in OSM met een geüpdatet CRAB
lijkt mij echt een nachtmerrie. In dit licht lijkt de derde optie
van Sander mij zondermeer de meest interessante.<br>
<br>
Ik kom nog terug op een aantal technische punten die Sander
aanhaalt. Complimenten voor iedereen die hier al zo hard aan
gewerkt heeft!<br>
<br>
Vriendelijke groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 17-10-2014 12:03:<br>
</div>
<blockquote
cite="mid:CABUOUO8ZxfjLtjzESQEM=L_0CTL_oRP8fAoj-uVt5dbE1G5rVQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Ik ben idd bezig met het onderzoeken welke tools we
kunnen gebruiken om de adressen te importeren, en nog
belangrijker, te onderhouden. Gebaseerd op scripts van
Ben.<br>
<br>
</div>
Momenteel zijn er drie pistes open.<br>
<br>
</div>
<b>1.</b> De originele piste is gebruik maken van <a
moz-do-not-send="true"
href="http://addr.openstreetmap.fr/vlaanderen/">http://addr.openstreetmap.fr/vlaanderen/</a>.
Deze tool kan éénmalig data als CSV importeren. Daarna moeten
mappers aanduiden welke straten compleet zijn en welke niet.
Het is hier onmogelijk om data te updaten zonder de
commentaren of classificatie te verliezen. Dus is deze tool
enkel goed voor de initiële import, en zijn er problemen voor
het onderhoud.<br>
</div>
<div><br>
</div>
Er is een script om de CRAB data naar een grote CSV te brengen,
voor de initialisatie. Verder zijn er geen scripts meer nodig en
werkt de tool volledig crowd-sourced.<br>
<div><br>
<b>2.</b> Het genereren van wiki pagina's zoals: <a
moz-do-not-send="true"
href="http://wiki.osm.org/wiki/User:Sanderd17/AddrImport8840">http://wiki.osm.org/wiki/User:Sanderd17/AddrImport8840</a>
(opmerking: momenteel worden hier rechtstreeks CSV bestanden
aangeboden, dus moet je de open-data plugin van JOSM
installeren om de wiki pagina te gebruiken).<br>
<br>
</div>
<div>Het doel bij deze is om éénmalig wiki pagina's te maken die
verwijzen naar automatisch gegenereerde CSV bestanden. Het
update proces ziet er als volgt uit:<br>
</div>
<div>
<ul>
<li>Download 1.6 GB data van AGIV, en pak het uit</li>
<li>Download en run een python script om nieuwe CSV
bestanden te maken (tijd onbekend, genereren van 1
gemeente kost iets minder dan 1 uur, maar door de DB
structuur moet voor 1 gemeente ook de volledige DB gelezen
woden. Dus voor een volledig extract zou het lezen van de
DB niet veel langer duren)</li>
<li>Upload de nieuwe CSV bestanden naar een git repo en
bekijk de diff t.o.v. de vorige versie</li>
<li>Ga manueel alle wijzigingen van de diff gaan toepassen
op de wiki pagina's (de CSVs zijn per straat, dus kan je
eenvoudig zien welke bestanden nieuw, verwijderd of
gewijzigd zijn om de correcte wiki lijnen aan te passen).</li>
</ul>
</div>
<div>Mappers moeten hier dus hun opmerkingen en status info
ingeven op de wiki pagina. Deze is zo gegenereerd dat het
edits makkelijk maakt (geen tabellen gebruikt b.v.). Updates
zijn nu mogelijk, maar vereisen manuele tussenkomst om de
status ingegeven door mappers niet te verwijderen (ttz: enkel
de statusen te wijzigen van de straten die gewijzigd zijn).<br>
<br>
</div>
<div>Aangezien het runnen van het script tamelijk lang duurt
denk ik niet dat we kandidaten zullen hebben om het iedere
week te runnen (toch niet voor jaren aan een stuk). Ik heb er
geen idee van hoe veel straten gewijzigde adressen zullen
hebben na een maand of twee, dus hoe zwaar het manuele
onderhoudswerk zal zijn. <br>
<br>
</div>
<div>Een ander nadeel is dat de aangeboden CSV diff files (die
het verschil tussen OSM en CRAB tonen) ook maar gegenereerd
worden tijdens de update (dus waarschijnlijk 1 keer per maand
of 2). Dus als je in een gemeente aan het mappen bent zijn de
diffs op het einde van de maand niets meer waard, en kan je ze
niet gebruiken om je fouten op te sporen. Een spellingsfout in
de straatnaam maakt hier veel kans om ongezien te passeren.<br>
<br>
</div>
<div><b>3.</b> On-th-fly vergelijking tussen OSM en CRAB: <a
moz-do-not-send="true"
href="http://sanderd17.github.io/8840.html">sanderd17.github.io/8840.html</a>.
(Opmerking1: De pagina is enkel getest met de meest recente
versie van Firefox, en ik verwacht niet dat de pagina nu al
werkt op andere browsers. Opmerking2: ik heb de pagina nog
niet werkende gekregen met josm remotecontrol, dus momenteel
kan je enkel .osm bestanden downloaden). <br>
<br>
Hier wordt de CRAB database omgevormd tot JSON bestanden per
straat. De webpagina gaat dan die JSON bestanden lezen, en
vergelijken met data die rechtstreeks van OSM komt via de
overpass API (je moet dus even wachten tot alle data gelezen
is voor de pagina tevoorschijn komt). Voor een kleine gemeente
is de pagina verrassend snel. Dus verwacht ik niet dat het
veel problemen zal geven voor een stad.<br>
<br>
</div>
<div>Het update proces ziet er als volgt uit:<br>
<ul>
<li>Download 1.6 GB data van AGIV, en pak het uit</li>
<li>Download en run een python script om nieuwe CSV
bestanden te maken (runtime is iets korter dan optie 2,
omdat de OSM data nu niet moet gelezen en vergeleken
worden)</li>
<li>Upload de nieuwe CSV bestanden naar een git repo of site</li>
</ul>
</div>
<div>De voordelen van deze werkwijze zijn dat er geen manuele
tussenkomst is om de bestanden te updaten. Je moet geen diffs
lezen, en het is zelfs niet belangrijk dat de CRAB data onder
versiecontrole staat. Het nadeel is dat mappers ook geen
manuele status kunnen toewijzen, en dus ook geen opmerkingen
kunnen geven.<br>
<br>
</div>
<div><b>OPMERKINGEN:</b><br>
<br>
</div>
<div>
<ul>
<li>De CRAB database bevat sommige adressen zonder
coördinaten. Meestal is dit omdat een bedrijf en een privé
woning op hetzelfde perceel staan (soms zelfs hetzelfde
gebouw), maar een verschillende brievenbus hebben. Vaak,
maar niet altijd, zijn die alternatieve nummers zichtbaar
op de brievenbus, dus kunnen ze in OSM wel een positie
krijgen als node. De tools behandelen die adressen nog
inconsistent. Zo zie je bijvoorbeeld bij de derde tool, in
de 14e Linistraat, dat er 1 missing adres is. Maar als je
het OSM bestand opent, dan zie je een leeg bestand. Dat is
net omdat het ene missing adres een adres zonder positie
is in CRAB.</li>
<li>Staar je niet blind op het kaartje van de eerste tool.
Een kaartje geeft een mooi overzicht, maar IMO werkt een
lijst even goed. Het zou ook mogelijk moeten zijn om een
kaartje te hebben in de derde tool. Een kaartje in een
wiki pagina is iets moeilijker, maar een link naar umap is
nog altijd mogelijk.</li>
<li>De automatische vergelijking (van tools 2 en 3) maakt
nog geen gebruik van afstanden. Het vergelijkt enkel welke
objecten er met een bepaalde straat en huisnummer getagged
zijn in OSM, en welke er in CRAB zitten. Controle op basis
van afstand is moeilijk, omdat de CRAB positie vaak het
centrum van het perceel is, wat bij grote percelen (zoals
bedrijven) wel eens heel ver van het hoofdgebouw of de
ingang kan liggen.</li>
<li>CRAB data bevat niet altijd de officiële spelling van
straatnamen. Zo zijn er enkel straten met afkortingen (Zie
G. Gezellestraat in CRAB, and Guido Gezellestraat in OSM).
Momenteel houdt de derde tool rekening met afkortingen (en
dit naar de tweede tool porten is niet moeilijk), maar
rekening houden met arbitraire spellingsverschillen is
natuurlijk onmogelijk. Dus zullen deze straten altijd als
incompleet gemarkeerd worden door de tools, tot iemand
AGIV contacteert om de fout te melden (let op, de versie
op de straatnaamborden is ook niet de officiële spelling,
de officiële spelling kan enkel gevonden worden in
gemeentedecreten).<br>
</li>
</ul>
</div>
<div>We kunnen je natuurlijk niet weigeren om feiten te mappen.
Toch niet als je die feiten afkomstig zijn van een compatibele
bron en ingegeven met een correcte bronvermelding. Maar hou er
rekening mee dat de data in de eerste tool ondertussen wat
verouderd is, en de andere tools volop in ontwikkeling zijn,
waardoor ik enkel mijn eigen gemeente geëxporteerd heb. Dus
probeer je edits lokaal te houden, en telkens een survey aan
een import te koppelen.<br>
<br>
</div>
<div>Door een import aan een survey te koppelen krijg je ook een
beter idee van de kwaliteit van de CRAB data (op vlak van
spelling en positie b.v.). Als je probeert verschillende
omgevingen in je buurt te mappen (platteland, wijken,
rijhuizen, appartementen, industrie, winkels, ...) dan zal je
ook een beter idee krijgen over dergelijke objecten het best
getagged worden, en waar CRAB data goed of slecht is.<br>
</div>
<div><br>
</div>
<div>Momenteel denk ik dat de derde werkwijze het meest
succesvol zal zijn (als dat importprobleem met JOSM opgelost
wordt). Het is volledig onafhankelijk van één persoon.
Iedereen kan het script en de CRAB data downloaden en de
nodige bestanden genereren. De webpagina zelf bestaat uit pure
JavaScript, dus kan die op eender welke server (of zelfs
lokaal) geïnstalleerd worden. Buiten CRAB en OSM is er ook
geen externe database nodig die moet onderhouden worden.<br>
<br>
</div>
<div>Ik zou graag de mening hebben van andere mappers, over hoe
automatisch of manueel het onderhoud zou moeten gebeuren. En
als iemand graag CSS schrijft, dan is dat ook altijd welkom.<br>
</div>
<div><br>
</div>
<div>Groeten,<br>
</div>
<div>Sander<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-10-17 6:43 GMT+02:00 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>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hallo Thomas,
<div><br>
</div>
<div>We hadden een volledig voorstel geschreven hoe we met
de import zouden omgaan. De pagina's op de wiki en de
site waarnaar je verwijst zijn daar een deel van. Jammer
genoeg werd dit voorstel niet goedgekeurd op de
import-mailing list (en dus ook niet door DWG). Het ging
daarbij vooral over de updates en de controle van de
correctheid van de gegevens. (die inderdaad meer dan
eens te wensen overlaat).</div>
<div>Momenteel wordt er achter de schermen weer druk
gewerkt aan een verbeterde versie. Ben Abelshausen en
Sander Derycke weten daar alles van.</div>
<div><br>
</div>
<div>Dus met andere woorden: het mag nu niet.</div>
<div><br>
</div>
<div>Wat ik wel doe is als ik twijfel aan mijn eigen
nota's even controleren op de AGIV website of ik het bij
het rechte eind heb.</div>
<div><br>
</div>
<div>met vriendelijke groeten</div>
<div><br>
</div>
<div>m</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div class="h5">On Thu, Oct 16, 2014 at 11:53 PM,
Thomas <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:osm@aptum.nl" target="_blank">osm@aptum.nl</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
<div text="#000000" bgcolor="#FFFFFF"> Hi,<br>
<br>
Beginners question: what's the current state of
affairs concerning the import of the
AGIV-CRAB-data?<br>
<br>
At <a moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import"
target="_blank">http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import</a>
I read that there will be a Team Approach. How I
understand it, there is a consensus about how to
deal with the data. The page <a
moz-do-not-send="true"
href="http://addr.openstreetmap.fr/vlaanderen/"
target="_blank">http://addr.openstreetmap.fr/vlaanderen/</a>
looks to be up and running. On a very small
scale imports seem to have started, but not by
{username}_crab-accounts, as is prescribed by
the wiki.<br>
<br>
At <a moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Using_AGIV_Crab_data"
target="_blank">http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Using_AGIV_Crab_data</a>
is explicedly stated: “Please do not use this
procedure to upload data to OSM until the Data
Working Group (DWG) has approved it.”. Has this
already happened? The page hasn't been edited
since November 2013. <br>
<br>
Eager to get started but apprehensive about the
correct M.O. I thus wonder how things are going.<span><font
color="#888888"><br>
<br>
Thomas<br>
</font></span><br>
p.s. 't mag ook in 't Vlaams hoor; ik ben nog
niet helemaal op de hoogte van de etiquette op
dit gebied... / Not sure about whether to write
English or Flemish... </div>
<br>
</div>
</div>
_______________________________________________<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>
_______________________________________________<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>