[OSM-talk-be] import AGIV CRAB-data
Marc Gemis
marc.gemis at gmail.com
Thu Oct 23 12:00:32 UTC 2014
In zo'n geval probeer ik vooral naar de tuinafscheidingen te kijken. die
zijn veel lager en geven een minder grote afwijking
2014-10-23 13:56 GMT+02:00 Thomas <osm at aptum.nl>:
> Bij mij werkt alles inmiddels weer prima. Mogelijk was het probleem aan
> mezelf te wijten en heb ik per ongeluk de niet-laatste variant van JOSM
> opgestart na een crash eerder gisteravond. Deze variant ging inderdaad niet
> goed om met het request vanuit de browser, zoals Sander al eerder
> signaleerde.
>
> Over het intekenen van gebouwen via luchtfoto's. Het gaat mij inderdaad
> niet om die dakgoot van enkele centimeters maar om de
> perspectiefvertekening; dat gaat over meters. Zowel bij de luchtfoto van
> het AGIV als die van Bing geldt dat als als de betreffende locatie zich
> relatief ver van de loodlijn van de satelliet / vliegtuig bevond, er een
> aanzienlijke vertekening is (ondanks de orthorectificatie waarbij de
> vertekeningen door hoogteverschillen op het grondvlak weggewerkt worden).
>
> Ik heb even een voorbeeldje gemaakt van een aantal huizen in Oostende:
> http://downloader.aptum.nl/ImageryOffset.jpg . In het rood aangegeven is
> de daklijn zoals 'men' (ik in elk geval) geneigd is in te tekenen. In het
> blauw de 'correcte' lijn door rekening te houden met het perspectief (ervan
> uitgaande dat de georefererentie 'nauwkeurig' is). Die rode lijn intekenen
> is vrij simpel. Die blauwe vind ik pure ellende, met name omdat de
> hoekpunten heel vaak verstopt liggen in het perspectief. In dit geval is de
> foto van linksonder genomen, aardig in lijn met de straat, waardoor de
> perspectiefvervorming hier enkel in de breedte van de huizen optreedt en
> niet in de diepte. Dit is dus absoluut geen extreem geval.
>
> Omdat de daken niet even hoog komen, lijkt het alsof het ene huis dieper
> is dan het andere. Ik ken de situatie ter plaatse en dat is niet het geval.
> In dit geval zijn de Bing-beelden meer van loodrecht boven de locatie
> genomen. Daarmee is de perspectiefvertekening veel minder en passen de
> blauwe lijnen heel netjes over de daklijnen. Op de GRB-kaart zie je dat de
> blauwe lijn heel aardig klopt. Toch zou je op basis van de AGIV-foto het
> idee kunnen krijgen dat ze onnauwkeurig ingetekend zijn.
>
> Het verschil tussen de blauwe en rode lijnen bedraagt in dit geval
> ongeveer 2,5m. Enerzijds is dat een beperkte fout, maar anderzijds kan dat
> wel voor miserie zorgen bij de CRAB-import. Zoals je op mijn voorbeeld al
> kunt zien, lijnen de adrespunten (de kleine witte cijfertjes) op het
> verkeerde dak uit. Ze liggen nog net niet in het naastgelegen rode perceel.
> In andere situaties kan dat wel het geval zijn. Wat mij betreft is dit
> zeker een aandachtspunt in de workflow, met name bij rijtjeshuizen. Het is
> ook de reden dat ik (zeker in mijn omgeving) een hekel heb aan het
> intekenen van gebouwen; het is zeer lastig om het enigszins nauwkeurig te
> doen.
>
> Als probleem voor de import valt het overigens wel mee. De meeste
> bebouwing op OSM in België ontbreekt nog. Daarnaast zijn de gebouwen die
> wel ingetekend zijn meestal vrijstaande woningen. De bestaande problematiek
> is dus zeker nog te overzien. Het wordt volgens mij vooral een issue als
> bij de import van de CRAB-gegevens massaal ingetekend worden van de
> AGIV-luchtfoto zonder met dit effect rekening te houden. Ik twijfel er niet
> aan dat er dan heel wat CRAB-punten boven een anders-genummerd OSM-gebouw
> komen te vallen. Bij foutcontrole kan dat een probleem vormen, maar dat
> hangt natuurlijk af van hoe die controle ingebouwd wordt.
>
> Groeten,
> Thomas
>
> Marc Gemis schreef op 23-10-2014 8:29:
>
> Een allegaartje van antwoorden en opmerkingen:
>
> - Ja, dit is een import (je kopieert data van een andere databank zonder
> survey) en dus moet je voldoen aan de import procedure. Deze moet dus
> beschreven worden en voorgelegd worden aan de import lijst. Een van de
> voorwaarden is een specifieke account..Je mag dus nu feitelijk nog geen
> data overnemen via de tool, omdat de procedure nog niet is goedgekeurd. Ik
> vraag me wel af in hoeverre deze werkwijze tegemoet komt aan de
> vragen/eisen die er met de vorige manier opdoken.
> - Ik heb Chrome gebruikt (te lui om ook Firefox te installeren) en hoopte
> dat dat ook zou werken. Sander, Welke vieze trucks heb je gebruikt omdat
> het enkel op Firefox zou werken ? (grapje :-) Eerst met 2840 (Rumst),
> daarna met de A-straten (10 of zo), dan met 1 straat. Kreeg geen resultaat.
> Zal later nog wel eens met Firefox proberen
> - Als je geen initiële survey doet, hoe weet je dan of de nummers in AGIV
> Crab juist zijn ? Ik wil daar niet vanuit gaan, heb al een paar problemen
> gezien. Ook ontbreken er soms nummer (niet alleen nieuwbouw). Als je nu de
> nummers gewoon overneemt, zonder controle, gaan die fouten er maar heel
> langzaam uitgaan. Waar geven we de voorkeur aan: geen data of data met ??
> fouten. Ik heb er nog steeds geen zicht op hoe goed AGIV Crab is. 5% fouten
> ? meer ? minder ? Dit is volgens mij een van de vragen van de import
> mailing list.
> - Het kadaster is volgens mij niet rechtsgeldig (zie bv
> http://bouwinfo.be/forum/threads/136644-buurman-zet-afsluiting-1-5m-over-de-scheidingslijn/page2
> )
> - Het is nu de bedoeling dat de gemeenten de huizen gaan intekenen (meen
> ik begrepen te hebben van Gilbert). Volgens zijn "contact" persoon tekenen
> zij ook de huizen in vanaf de luchtfoto's. Moeten we daar niet nog eens
> contacten leggen, een presentatie geven ?
> - Waarvoor wil je de gegevens van de gebouwen tekenen ? Hoe groot mag de
> foutenmarge zijn ? Een dakgoot is volgens mij niet meer dan 1 of 2 pixels.
> Wat is het fouten percentage als je die volgt ? Het perspectief geeft een
> grotere fout. Ik wil best meewerken aan de beste kaart, maar gaat het
> volgen van de dakgoot de kwaliteit van de kaart zodanig naar beneden halen
> dat ze niet meer bruikbaar is voor je toepassing ?
> - Wat is het nut om een huisnummer op de voordeur van een privé woning te
> zetten ? Voor deur naar deur routering voor slechtzienden ? Maar dan moet
> het ook wel echt juist zijn. Een meter of 2 naar rechts of links helpt dan
> ook niet. Bij grote gebouwen (bedrijven, of evenementshallen) kan ik er nog
> inkomen, maar dan moet je ook entrance=... erbij zetten. Een huisnummer bij
> de deur plaatsen is enkel nodig indien er verschillende huisnummers in een
> gebouw zijn met elk een eigen ingang. En dat kan je enkel weten door een
> survey.
> - Zijn huisnummers niet belangrijker voor autonavigatie dan de gebouwen ?
>
> - oh ja, ook nog een +1 voor Glenn's antwoord i.vm. met al dan niet
> overtekenen van GRB kaart, de mogelijke easter eggs en zijn standpunt dat
> als alles correct is de 2 kaarten toch gelijk zouden moeten zijn.
>
> met vriendelijke groeten
>
> m
>
>
>
>
> 2014-10-23 0:15 GMT+02:00 Thomas <osm at aptum.nl>:
>
>> Ik heb nu de laatste variant van de website van Sander even snel
>> uitgeprobeerd; een dikke twee uur geleden werkte alles prima, maar het
>> laatste uur krijg ik steeds een 400: bad-request van JOSM terug op het
>> request vanaf het js-script, met daarbij “no command specified” (ongeacht
>> welke van de 4 sets per straat ik gebruik). OSM-data inladen via de
>> straatnaam werkt perfect. Het vergelijk met OSM werkt wel perfect, alleen
>> het inladen in JOSM gaat dus fout. Wissen van de cache heeft geen effect
>> (Firefox 33).
>>
>> Uit een aantal snelle eerste vergelijkingen lijken in mijn regio
>> (Oostende) vrijwel alle adresposities zéér mooi uit te lijnen op het midden
>> van de gebouwen op de AGIV-luchtfoto. Alle reeds gemaakte opmerkingen over
>> afwijkende positionering zal volgens mij vooral gelden voor de meer
>> plattelandsgemeenten. Ik moet het nog even goed bekijken. In elk geval voor
>> de woonwijken in Oostende zou ik de adrespunten zeer vlot kunnen verwerken
>> en als punt importeren, als we het eens zouden zijn dat dat de nu de beste
>> aanpak is.
>>
>> Ik ben het zeker eens met het feit dat de gebouw-contouren hebben veel
>> 'rijker' is voor de kaart dan puur de adrespositie. Toch vind ik dat die
>> adrespositie op zichzelf waarde heeft. Volgens alle richtlijnen van OSM
>> zijn adrespunten, naar mijn idee, zeker de moeite waard, ook al zijn de
>> bijbehorende gebouwen nog niet ingetekend. Dat die gebouwen eigenlijk
>> belangrijker zijn dan de nummers vind ik een terechte opmerking, maar we
>> hebben niet de beschikking over die gegevens. Daarnaast blijf ik bij mijn
>> eerdere standpunt dat alle gebouwen intekenen zeer veel werk is, vrij
>> onnauwkeurig door perspectiefvertekening en schaduwwerking en buitengewoon
>> frustrerend als over een paar maand de GRB-data alsnog open zou worden.
>> Ikzelf zie heel vaak af van het intekenen van gebouwen vanaf de luchtfoto
>> omwille van bovenstaande redenen. In mijn werkomgeving ben ik ook vaak
>> bezig met data-entry in GIS-systemen. Ik vind het zeer frustrerend om zo
>> onnauwkeurig te werken als bij het intekenen van gebouwen vanaf een
>> luchtfoto.
>>
>> Daartegenover moet ik zeggen dat ik de GRB-data in mijn regio volgens mij
>> extreem nauwkeurig is (los van tijdsdiscrepanties). Volgens mij is die data
>> afkomstig van het kadaster. De moderne gegevens zijn met professionele GPS
>> ingemeten, de oudste volgens mij zijn gedigitaliseerd van de analoge
>> kaarten. Kadaster-gegevens hebben een bijzondere 'rechtspositie'. Volgens
>> mij hangen de licentie-problemen daar mee samen. De 'eigendom' van die
>> gegevens is een zeer complexe zaak. De oorspronkelijke data stamt formeel
>> uit het begin van de 19de eeuw en is daarmee auteursrechtenvrij. De
>> oorspronkelijke kaarten (ondermeer uitgegeven door Popp en raadpleegbaar op
>> geopunt.be) zijn op zich auteursrechtenvrij maar de scans zijn dat niet.
>> De huidige kadastrale systemen zijn een directe voortzetting van dat
>> historische systeem. Hoe en wat precies met rechten op de data is
>> buitengewoon complex.
>>
>> Over de workflow: ik vind dat de adrespunten op zichzelf geïmporteerd
>> mogen worden; ook bij afwezigheid van het gebouw. Uiteraard moeten de
>> punten wel handmatig 1 voor 1 gecontroleerd worden met de AGIV-luchtfoto.
>> Een automatische datapomp is een echte no-go, maar daar lijken we het
>> allemaal over eens te zijn. Wanneer de situatie niet duidelijk is, kan nog
>> een beroep gedaan worden op de GRB-gegevens (zonder de contouren over te
>> nemen!) of bij aanhoudende onduidelijkheid kan survey ter plaatse
>> noodzakelijk zijn en/of moet van import van de specifieke punt uiteraard
>> afgezien worden. Wanneer het gebouw aanwezig is (een relatieve
>> zeldzaamheid, heb ik het idee) mogen wat mij betreft de adresgegevens op
>> het gebouw getagd worden en mag het punt verwijderd worden. Dat er dan
>> adressen op gebouwen staan en anderzijds adressen op punten lijkt mij geen
>> probleem. Uit mijn eerste testen besluit ik dat ik met deze werkwijze zeer
>> vlot een regio kan verwerken, zonder onzin-data te importeren. Het aantal
>> “moeilijke gevallen” is in mijn regio zeer beperkt. Dat kan uiteraard per
>> regio verschillen.
>>
>> Over Bing versus AGIV: Bing zal altijd bekender zijn dan AGIV. Hoe
>> eenvoudig het ook wordt om de AGIV-luchtfoto te gebruiken: als 'startende
>> OSM-editende leden' ook voor Bing kunnen kiezen zullen ze dat heel snel
>> doen. Dit als belangrijk punt naar voor schuiven in de
>> 'how-to-get-started'-lijstjes lijkt mij enkel de drempel te verhogen. Het
>> is volgens mij belangrijker om de aandacht te vestigen op de
>> onnauwkeurigheid van luchtofotografie in het algemeen. De misvattingen over
>> schaduwen, perspectief etc. zorgen voor een verkeerde interpretatie van de
>> luchtfoto en bijgevolg het verkeerd aanpassen / corrigeren van wél correct
>> ingevoerde gegevens. Het klopt dat de voetafdruk van een gebouw haast nooit
>> netjes uitlijnt met de dakgoot-contour. Die contour is echter wél heel
>> duidelijk zichtbaar op de luchtfoto. Het is een natuurlijke reflex om een
>> gebouw-contour te tekenen rond die dakgoot, maar daarmee nog niet minder
>> fout. Ik ben het wel volledig eens met het verder promoten van de
>> AGIV-luchtfoto voor Vlaanderen.
>>
>> Voor wat betreft de workflow van het importeren van de adressen kom ik nu
>> tot volgende richtlijnen:
>> – In de basis altijd het gebouw de adres-tags meegeven. In principe geen
>> losse adres-nodes, tenzij:
>> * gebouw nog niet ingetekend maar wel aanwezig op luchtfoto:
>> → gebouw intekenen en adres-tags toevoegen OF punt midden boven
>> gebouw plaatsen.
>> * gebouw nog niet ingetekend en niet zichtbaar op luchtfoto maar wel
>> gezien bij survey:
>> → adres-punt op gesurveyde locatie plaatsen
>> – Wanneer er meerdere adressen binnen 1 gebouw zijn:
>> → gezamenlijke kenmerken op gebouw taggen, al de rest op de
>> individuele adres-nodes (“Nederlands systeem”)
>> – Wanneer er meerdere adressen zich precies boven elkaar bevinden:
>> → de adressen individueel registreren als punt, maar de punten mogen
>> niet op elkaar vallen.
>> – Over het hoe en wat voor adrespunten zonder locatie zal het
>> vooronderzoek eerst duidelijkheid moeten brengen
>>
>> Over de precieze locatie van de adres-nodes kan gediscussieerd worden.
>> Zoals Sander voorstelt (het punt op de ingang plaatsen) is het in veel
>> gevallen logisch. In veel andere gevallen is het volgens mij lastig om de
>> ingang precies aan te wijzen, zonder survey. Ik vrees dat in de praktijk
>> veel nodes toch lukraak op het gebouw zullen belanden. De richtlijn om het
>> punt op de ingang te plaatsen is dan misschien enkel verwarrend, wanneer
>> het niet consequent toegepast wordt. Maar daar zijn vast ook heel andere
>> meningen over...
>>
>> Bij de vorige stap naar de import-lijst was er discussie over het al dan
>> niet gebruiken van een dedicated account. Is er consensus over hoe hiermee
>> om te gaan? Of is het een kwestie waar we het niet over hoeven te hebben en
>> gewoon 'de regels' volgen en de import met een dedicated account uitvoeren?
>>
>> Is er verder nu ook consensus over het feit dat de twee tags (huisnummer
>> en straatnaam) op de node of het gebouw getagd worden in tegenstelling tot
>> het koppelen van alle huisnummers aan de straat met een relatie?
>>
>> Groeten,
>> Thomas
>>
>> Sander Deryckere schreef op 22-10-2014 21:40:
>>
>>
>>
>> Op 22 oktober 2014 20:57 schreef Marc Gemis <marc.gemis at gmail.com>:
>>
>>> Sander, (& anderen)
>>>
>>> ik heb je website daarstraks eens geprobeerd. Jammer genoeg kreeg ik
>>> niets anders dan "Loading". Niet lang genoeg gewacht ? Server overladen ?
>>> Verkeerde browser ?
>>>
>>> Welke browser? Welke postcode (misschien een grote stad waarbij het
>> niet werkt)? Heb je het net nog geprobeerd (mogelijks moet je de browser
>> cache legen om de verbeterde versie van het JS script opnieuw te
>> downloaden)?
>>
>>
>>> Ik vraag me nu af hoe ik een en ander in mijn workflow kan inpassen.
>>>
>>
>> Ik ook :D Dat vraagt natuurlijk wat onderzoek en wat denkwerk.
>>
>>>
>>> Het overzicht van wat er al in OSM zit is heel handig, maar dan zou
>>> het resultaat onmiddellijk zichtbaar moeten zijn. Zou dit kunnen door het
>>> script 's nachts te laten lopen en de resultaten te cachen in een DB ?
>>> (sorry maar hier komt mijn achtergrond naar boven :-) ).
>>>
>>
>> Niet met de huidige code. Alles gebeurt client-side, wat maakt dat het
>> (eenmaal de kinderziekten verdwenen zijn) bijna geen onderhoud zal vragen.
>> Als je werkt met een DB, dan moet er altijd server infrastructuur
>> onderhouden worden, waardoor er kostbare mapping tijd verloren gaat.
>>
>> Ik denk ook dat niet in elke gemeente elke dag gemapt zal worden. Dus
>> is het jammer om elke dag alle adressen te downloaden, wanneer er misschien
>> hoogstens in 20 gemeenten per dag a.d.h.v. CRAB data gemapt wordt.
>>
>> Een ander voordeel van live-queries is dat binnen enkele minuten na het
>> uploaden naar OSM je al het resultaat zou moeten zien. Dus kan je eenvoudig
>> straat per straat mappen, zonder dat je er de volgende dag op moet terug
>> komen om te kijken als je geen fouten gemaakt hebt.
>>
>> Normaal is het laden van de data snel genoeg, en ik kan de overpass
>> query nog wat verbeteren om het laden nog sneller te maken (en zal dat
>> zeker doen).
>>
>>
>>> De adrespunten in JOSM overnemen, is handig, maar gaat het mij
>>> tijdwinst opleveren (gesteld dat ik nog steeds eerst een survey doe) ? Ik
>>> vrees ervoor. Ik heb al eens gewerkt met de osmose site vorig jaar en dat
>>> ging niet sneller. Als we de adressen niet op de gebouwen zouden plaatsen
>>> zou er wel een snelheidswinst inzitten. Dit is een beetje zoals ze het in
>>> Nederland doen. Hoewel je dan in sommige gevallen toch nog het adres op het
>>> gebouw moet plaatsen, bv. bij supermarkten waar de POI gegevens op het
>>> gebouw gezet worden.
>>>
>>> Ik kan niet meer data aanbieden dan we van AGIV krijgen ;)
>>
>> Ik weet ook niet als het sneller zal gaan, maar ik denk dat met de CRAB
>> data slechts onvolledige surveys zouden nodig zijn.
>>
>> Door een routine te creëren zal je zien waar er problemen kunnen zijn met
>> de CRAB data (zeker al met de punten die geen positie hebben), en specifiek
>> die probleemplaatsen gaan opzoeken. Ik denk, als je begint met een
>> volledige survey, zonder CRAB data, dan kom je thuis, zie je dat er op
>> sommige plaatsen nog onduidelijkheden zijn, en moet je nog eens terug. Deze
>> eerste survey zou kunnen vermeden worden door eerst de duidelijke CRAB data
>> te importeren.
>>
>> Een andere tool die we kunnen gebruiken (weet niet als deze al
>> bestaat), is een tool om "probleemplaatsen" te markeren. Een soort
>> geografische TODO lijst. Ofwel gedeeld of persoonlijk. Zodat we aan de
>> computer, tijdens de initiële CRAB import, deze probleemplaatsen eenvoudig
>> kunnen markeren en vergeten, om dan later alle plaatsen te gaan bezoeken.
>>
>> Deze tool is moeilijker te maken, omdat het afhangt van de mapping
>> voorkeuren (mappen op papier, met Android, met iPhone, ...). Dus hoop ik
>> dat er al ergens een bruikbaar systeem bestaat dat we gewoon kunnen
>> gebruiken.
>>
>>
>>> Ik had de indruk dat Sus ongeveer hetzelfde schreef. een huisnummer
>>> toevoegen in JOSM is 2 kliks (HouseNumberTool plugin CMD-K/CTRL-K of
>>> terracer-tool).
>>>
>>> Daarom laat ik het downloaden als extra layer. Dan kan je die (met
>> een aangepast stylesheet) ook als achtergrondlaag gebruiken, en zelf je
>> eigen gegevens ingeven. Na het mappen is de laag eenvoudig te verwijderen.
>> Daarnaast blijft mijn tool nuttig als controle na het mappen.
>>
>>
>>>
>>> Hoe zien jullie dat ? Hoe kunnen we het harde werk van Sander het
>>> beste gebruiken ?
>>>
>>> met vriendelijke groeten
>>>
>>
>> Opmerkingen zijn altijd welkom.
>>
>> Groeten,
>> Sander
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
>
> _______________________________________________
> 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/20141023/e02223ba/attachment.htm>
More information about the Talk-be
mailing list