[OSM-talk-be] import AGIV CRAB-data
Thomas
osm at aptum.nl
Thu Oct 23 11:56:31 UTC 2014
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 <mailto: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 <http://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
>> <mailto: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 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 <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/20141023/53304dda/attachment.htm>
More information about the Talk-be
mailing list