[OSM-talk-be] import AGIV CRAB-data

Tue Oct 21 18:28:17 UTC 2014

In de discussie over node vs gebouw kan ik zeker meegaan in wat Sander 
zegt. Bij nader inzien hoeft een combinatie van beide geen probleem te 
zijn. Wat mij betreft kunnen in dat opzicht ook zeker adresposities 
geimporteerd worden zonder dat daar gelijk een gebouw-polygoon voor moet 
ingetekend zijn. Dat de CRAB-positie in veel gevallen het 
perceel-centroid is en daarmee niet wenselijk als adrespositie binnen 
OSM klopt ook. Binnen de workflow kan dan opgenomen worden dat de 
adresposities minimaal op de AGIV-luchtfoto op het gebouw moeten komen 
te staat dat het dichtst aan de weg ligt. Hoewel dat toch zeer wenselijk 
is als uiteindelijk doel denk ik dat het 'eisen' dat er een 
gebouw-polygoon aanwezig moet zijn toch veel mensen afschrikt om mee te 
werken aan de import. Nu wordt in de wiki ook al aangegeven dat het zeer 
wenselijk is om gelijk ook de gebouw-polygonen te tracen van de 
luchtfoto. De verwoording in de wiki lijkt mij wat dat betreft prima.

Voor een aantal woonwijken zal het erop neer komen dat 'alle' 
adresposities binnen CRAB prima op het gebouw vallen en daarmee 
rechtstreeks geimporteerd kunnen worden (uiteraard na handmatige 
controle van elke individuele node). Voor heel veel landelijke gebieden 
zal dan de adrespositie handmatig verschoven moeten worden (met de 
luchtfoto als leidraad) tot boven het gebouw dat het dichtst aan de 
straat ligt. In de workflow moet dan even duidelijk vermeld worden dat 
het gebruiken van de AGIV-GRB-kaart heel handig is om zaken mee te 
vergelijken, maar dat de adresposities niet op de GRB-kaart mogen worden 
uitgelijnd en dat ook de gebouw-contouren niet mogen worden overgenomen 
van die kaart. Wanneer er een bestaande polygoon is voor dat adres 
kunnen de gegevens uit het CRAB daar aan toegevoegd worden. Daarnaast 
bestaat dan uiteraard altijd de mogelijkheid om het gebouw gelijk in te 
tekenen.

Op technisch gebied gaat het volgens mij best goed. Ik wil zeker mee 
kijken naar de software zelf; als de scripts beschikbaar kunnen worden 
gesteld: graag! De laatste variant van de webpagina werkt bij mij prima. 
Nog iets om bij stil te staan: nog los van waar de punten zonder positie 
geplaatst worden bij import (middelpunt van de straat?); nu worden ze op 
elkaar weergegeven. Misschien kan daar met een offset gewerkt worden of 
zo, zodat visueel al bij import duidelijk is dat er meerdere punten op 
elkaar liggen. Alternatief is dat zo'n punt op het dichtste punt langs 
de straat wordt geplaatst, maar die gegevens heb je volgens mij niet 
beschikbaar in het import-script. Nog een alternatief is dat de punten 
precies verticaal boven/onder elkaar worden geplaatst langs de 
westelijke of oostelijke rand van de extent, ter hoogte van een 
overeenkomstig punt (als query een gelijk numeriek gedeelte in het 
nummer-veld). Maar misschien vinden jullie het helemaal geen issue dat 
er meerdere punten op elkaar liggen bij import.

Over het niet uitvoeren van een grootschalige import zijn we het denk ik 
allemaal eens. Ook is het duidelijk dat er specifieke richtlijnen moeten 
zijn (of in elk geval een plan van aanpak) voor een aantal specifieke 
issues met de brondata, zoals de aanwezigheid van adressen zonder 
positie. Daarnaast heb ik het idee dat het geheel op de import-lijst 
voor een gedeelte is afgeketst door het niet formeel beschreven zijn van 
de quality-assesment van de brondata, een eisenspecificatie van de 
software en het plan voor het beheren van updates in de toekomst.

Als ik het zo bekijk is het meeste toch minstens gedeeltelijk besproken. 
Ik denk dat als we dat wat formeler op een rij zetten, we ook een betere 
'case' hebben voor de import-lijst. In elk geval is dan voor externen 
beter te beoordelen wat nu juist de bedoeling is.

Ook voor de software is het denk ik handig om een concrete lijst van 
eisen te hebben zodat verschillende software-opties tegen elkaar 
afgewogen kunnen worden. Er zijn meerdere softwarematige opties mogelijk 
maar we hebben geen formele manier om ze te vergelijken en te beoordelen 
welke de 'beste' is. Bij de vorige gang naar de import-lijst kwamen er 
vragen over het waarom niet gebruik maken van de task-manager en zo. 
Door concreet een lijst van eisen te hanteren kan heel duidelijk gemaakt 
worden waarom die software niet voldoet en waarom alternatieve software 
daar beter voor geschikt is (in dit geval lijkt het belangrijkste punt 
mij het per-straat kunnen werken in plaats van per oppervlakte-polygoon).

Concreet moeten er denk ik 4 formele lijstjes van 
voorwaarden/richtlijnen/plannen opgesteld worden:
1) Kwaliteitsbeoordeling van de brondata: welke data is het, welke 
kenmerken heeft de data en hoe kan de kwaliteit beoordeeld worden.
2) Kwaliteitsbeoordeling en 'normering' voor de import-software: wat 
moet de software precies wel en niet doen en hoe wordt de werking 
daarvan beoordeeld.
3) Richtlijnen voor de menselijke handelingen bij de import: workflow. 
De wiki-pagina geeft hier al heel wat aanwijzingen maar is niet compleet.
4) Heel belangrijk: plan van aanpak voor het continu updaten van de 
gegevens.

Deze formele lijsten kunnen bij de import-aanvraag gevoegd worden als 
onderbouwing, mogelijk als wiki-pagina over de import op zich. Verder 
kan de inhoud ervan volgens mij best verwerkt worden op de (bestaande) 
wiki-pagina's. Ik denk dat het belangrijk is dat deze lijsten opgesteld 
worden. Het zou toch erg jammer zijn als het voorstel op de import-lijst 
afketst omdat bepaalde zaken niet voldoende uitgewerkt zijn. Dat zou ook 
heel erg jammer zijn voor de vele inspanningen die al geleverd zijn.

Als jullie het hiermee eens zijn ben ik zeker bereid om deze lijsten 
vorm te gaan geven. Voor de eerste lijst moet ik me nog wat verdiepen in 
de formele beschrijving van de dataset; daar kom ik op terug. Voor de 
andere drie lijsten gelijk een voorzet:

1) Kwaliteit van de brondata. Specifieke issues:
     – adressen zonder positie
     – verkeerde spelling
2) Eisen voor het import-script:
     a) Oplossing voor alle specifieke issues met de brondata?
     b) Wat wel/niet te importeren (naast specifieke issues)?
         Beoordeling van volledigheid van import-script?
         vb:  Vakbondstraat in Willebroek ontbrekende nrs tussen 9 en 41
     c) Welke tags worden mee geimporteerd? (zie ook 3.d relaties en 4.a)
     d) Het systeem moet het mogelijk maken een latere update te beheren
3) Richtlijnen voor de workflow:
     a) Gegevens worden geimporteerd met het script
     b) Adrespunten worden verplaatst tot boven het gebouw 
(AGIV-luchtopname)?
         Is hier consensus over? Wat met het issue uit mijn vorige 
bericht aan Marc?
     c) Gegevens uit adrespunt worden toegevoegd aan gebouw-polygoon.
         – indien polygoon aanwezig en eenduidig voor adres: adrespunt 
wordt verwijderd
         – indien polygoon aanwezig maar niet eenduidig
             vb: meerdere adressen in 1 gebouw: appartement, 
winkelcentrum, etc
             → adrespunt op zichzelf laten bestaan.
             → Waar precies? Ingang/centroide? (zie ook punt b)
             → Hoe adrespunten die precies boven elkaar liggen te 
behandelen?
             → POI-tags komen dan niet op polygoon maar op het punt te 
staan.
                 Wanneer POI volledige polygoon bestrijkt: tags op 
polygoon laten.
         –  indien polygoon niet aanwezig:
             * Bij voorkeur gebouw intekenen
             * Indien niet haalbaar: adrespunt op zichzelf laten bestaan
             * Indien gebouw niet duidelijk aanwijsbaar of afwezig: niet 
importeren
     d) Richtlijnen voor straatgegevens op gebouw, punt of als relatie?
     e) Richtlijn voor dedicated account?
     f) Registratie voortgang import: overzicht? kaart?
4) Plan van aanpak voor het up to date houden:
     a) bron-tags (zoals CRAB-id) bij import handhaven tbv latere update?
     b) diffs-worden automatisch gegenereerd
     c) Hoe weten gebruikers wat geupdate moet worden? overzicht?

Deze lijsten lijken mij het best te passen binnen 
http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import . De inhoud moet dan 
verder verwerkt worden in 
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Using_AGIV_Crab_data 
en de daaraan gekoppelde subpagina's.

De richtlijnen voor huisnummers en zo kunnen dan gekoppeld worden aan of 
verwerkt worden in
http://wiki.openstreetmap.org/wiki/User:Escada/JOSM_and_Housenumbers

Wat denken jullie over het wat formeel op een rij zetten van de 
hierboven genoemde zaken? Hebben jullie ideeën voor een verdere concrete 
invulling hiervan?

Groeten,
Thomas

Sander Deryckere schreef op 20-10-2014 22:34:
> Eindelijk een versie die werkt met JOSM remotecontrol (na een JOSM 
> patch, dus werkt het enkel met de SVN versie).
>
> http://sanderd17.github.io/import.html?8840
>
> Nu ben ik nog van plan een afstands-check toe te voegen (met 
> instelbare afstand), en dan kan het terug naar de import lijst.
>
> We moeten enkel nog wat richtlijnen bedenken mbt huisnummers zonder 
> positie, en met de richtlijnen over waar een huisnummer te plaatsen 
> (node, gebouw, waar exact) moet alles in orde zijn.
>
> Groeten,
> Sander
>
> Op 18 oktober 2014 17:46 schreef Marc Gemis <marc.gemis at gmail.com 
> <mailto:marc.gemis at gmail.com>>:
>
>
>     2014-10-17 23:27 GMT+02:00 Thomas <osm at aptum.nl
>     <mailto:osm at aptum.nl>>:
>
>         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.
>
>
>     Dit begrijp ik niet helemaal. Bedoel je dat de polygoon in OSM
>     helemaal niet rond het adres punt is getekend ?
>     Voor het overige plaatst de standard rendering van OSM het
>     huisnummer gewoon in het midden van de polygoon (als de gegevens
>     op de polygoon staan).
>     Sommige mensen plaatsen het huisnummer ongeveer op de deur, dus op
>     de rand van het gebouw, of gewoon ergens in het gebouw. Er is geen
>     regel waar het adrespunt moet komen. In Denemarken zijn ze er wel
>     strenger op waar de huisnummers moet komen (alvast niet op het
>     gebouw, dat is het enige dat ik kan onthouden :-) )
>     Dus als er geen regels zijn, kan je IMHO ook niet spreken over
>     "nauwkeuriger gepositioneerd", als het nummer op/in het juiste
>     huis staat, is het juist gepositioneerd voor OSM. Nauwkeuriger kan
>     niet :-)
>
>     met vriendelijke groeten
>
>     m
>
>
>     _______________________________________________
>     Talk-be mailing list
>     Talk-be at openstreetmap.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20141021/8a604cb3/attachment.htm>