[OSM-talk-be] import AGIV CRAB-data
Marc Gemis
marc.gemis at gmail.com
Sat Oct 18 08:18:54 UTC 2014
Tja, als ik dan nog eens naar de AGIV CRAB data op de eerste website kijk
en vergelijk met wat ik al verzameld heb, dat weet ik weer waarom ik niet
pro-imports ben.
Kijk maar eens naar de Vakbondstraat in Willebroek. Een gebouw met 2
verdiepingen en verschillende huisnummers op gelijkvloers en de eerste
verdieping. Ofwel is de originele data niet juist ofwel is het conversie
algoritme niet juist. Maar in de "geimporteerde" data ontbreekt meer dan de
helft van de nummers tussen 9 en 41.
Misschien een goede test voor Sander's algoritmes van punt 2 en 3. :-)
Een andere "test' voor die algoritmes: hoe gaan we om met POIs ? Die worden
nu ofwel op het gehele gebouw getagged (bv. bij supermarkt) of als punt
(indien slechts een deel van het gebouw is ingenomen). Nu ja, dit is de
meest voorkoment guideline. Als het een punt is binnen een gebouw worden de
adres gegevens dubbel gezet: op de POI en op het gebouw. Dus als je enkel
adrespunten importeerd, waar zet je dan de POI informatie ? --- POI is
bv. winkel met naam, type, openingsuren, website, enz.
Je kan nooit garanderen dat een import ID behouden blijft, dus daar mag/kan
je je niet op baseren.
Tegen een volledig geautomatiseerde import zal ik me altijd verzetten omdat
je zo teveel fouten introduceert. Liever minder snel en betere manuele
controle. Bv. geen nummers importeren als het gebouw niet meer bestaat. Dus
feitelijk liever minder data dan foutieve data.
Aan de andere kant besef ik ook wel dat je zonder import nooit op korte
termijn alle adressen gaat hebben, maar het is niet omdat we aan een import
zouden beginnen dat die "morgen" al af moet zijn. Daar mag ook best een
aantal maanden, zo niet jaren over gaan. Zeker als de kwaliteit van de
geïmporteerde data dan beter is.
mvg
m
2014-10-17 23:27 GMT+02:00 Thomas <osm at aptum.nl>:
> 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. (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.gemis at 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 <osm at 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 at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>>
>>
>> _______________________________________________
>> Talk-be mailing list
>> Talk-be at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
>
> _______________________________________________
> Talk-be mailing listTalk-be at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20141018/21266110/attachment.htm>
More information about the Talk-be
mailing list