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 <[email protected]>: > 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 <[email protected]>: > >> 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 <[email protected]>: >> >>> 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 >> [email protected]https://lists.openstreetmap.org/listinfo/talk-be >> >> >> >> _______________________________________________ >> Talk-be mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-be >> >> > > > _______________________________________________ > Talk-be mailing > [email protected]https://lists.openstreetmap.org/listinfo/talk-be > > > > _______________________________________________ > Talk-be mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-be > >
_______________________________________________ Talk-be mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-be
