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

Wed Oct 22 22:15:34 UTC 2014

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 
> <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
> https://lists.openstreetmap.org/listinfo/talk-be

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