[OSM-talk-be] import AGIV CRAB-data
Marc Gemis
marc.gemis at gmail.com
Tue Oct 21 18:54:09 UTC 2014
al even kort:
- bedankt voor de extra uitleg, nu begrijp ik wat je bedoel met
onnauwkeurige positie.
- we beschikken nog niet zo heel lang over de AGIV beelden (een jaar of
zo). De Bing beelden zijn veel onnauwkeuriger, i.e. meer verschoven t.o.v.
de werkelijkheid, ze zijn ook ouder en dikwijls onduidelijker.
- iedereen mag de positie van de gebouwen aanpassen, als dat een
verbetering is. Ik doe dat bv. ook bij gebouwen die ik 3 jaar geleden heb
geplaatst (aan de hand van Bing), of bij slechte AND-imports, enz.. Je kan
dat nu al doen. Dat staat feitelijk los van welke import dan ook.
- soms heb ik ook al plekken gezien waarbij ik me afvraag hoe ze de huizen
bij AGIV hebben ingetekend. Maar natuurlijk zijn die door professionals
getekend, dus zal nauwkeurigheidsniveau over het algemeen wel hoger moeten
liggen. Wat niet wil zeggen dat in OSM niet nauwkeurig gewerkt zou worden.
met vriendelijke groeten
m
2014-10-21 20:28 GMT+02:00 Thomas <osm at aptum.nl>:
> 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>:
>
>>
>> 2014-10-17 23:27 GMT+02:00 Thomas <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
>> 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/20141021/ad463e0e/attachment.htm>
More information about the Talk-be
mailing list