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.
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):
1) De conceptuele aanpak van de data: wat willen we op welke manier in
OSM hebben?
2) De beoordeling van de kwaliteit van de data: hoe betrouwbaar zijn de
gegevens?
3) De methode van de initiële import.
4) De methode om de dataset up-to-date te houden
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.
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.
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.
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.
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.
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.
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 http://sanderd17.github.io/8840.html
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.
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.
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.
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.
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
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.
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.
Ik kom nog terug op een aantal technische punten die Sander aanhaalt.
Complimenten voor iedereen die hier al zo hard aan gewerkt heeft!
Vriendelijke groeten,
Thomas
Sander Deryckere schreef op 17-10-2014 12:03:
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.
Momenteel zijn er drie pistes open.
*1.* De originele piste is gebruik maken van
http://addr.openstreetmap.fr/vlaanderen/. 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.
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.
*2.* Het genereren van wiki pagina's zoals:
http://wiki.osm.org/wiki/User:Sanderd17/AddrImport8840 (opmerking:
momenteel worden hier rechtstreeks CSV bestanden aangeboden, dus moet
je de open-data plugin van JOSM installeren om de wiki pagina te
gebruiken).
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:
* Download 1.6 GB data van AGIV, en pak het uit
* 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)
* Upload de nieuwe CSV bestanden naar een git repo en bekijk de diff
t.o.v. de vorige versie
* 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).
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).
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.
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.
*3.* On-th-fly vergelijking tussen OSM en CRAB:
sanderd17.github.io/8840.html <http://sanderd17.github.io/8840.html>.
(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).
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.
Het update proces ziet er als volgt uit:
* Download 1.6 GB data van AGIV, en pak het uit
* 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)
* Upload de nieuwe CSV bestanden naar een git repo of site
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.
*OPMERKINGEN:*
* 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.
* 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.
* 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.
* 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).
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.
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.
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.
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.
Groeten,
Sander
2014-10-17 6:43 GMT+02:00 Marc Gemis <marc.ge...@gmail.com
<mailto:marc.ge...@gmail.com>>:
Hallo Thomas,
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).
Momenteel wordt er achter de schermen weer druk gewerkt aan een
verbeterde versie. Ben Abelshausen en Sander Derycke weten daar
alles van.
Dus met andere woorden: het mag nu niet.
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.
met vriendelijke groeten
m
On Thu, Oct 16, 2014 at 11:53 PM, Thomas <o...@aptum.nl
<mailto:o...@aptum.nl>> wrote:
Hi,
Beginners question: what's the current state of affairs
concerning the import of the AGIV-CRAB-data?
At http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import 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
http://addr.openstreetmap.fr/vlaanderen/ 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.
At
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Using_AGIV_Crab_data
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.
Eager to get started but apprehensive about the correct M.O. I
thus wonder how things are going.
Thomas
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...
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
