Met trots kondig ik een nieuwe MapRoulette-uitdaging aan: Nederland - Fix Spiky Buildings (MapRoulette)! We hebben gebouwen op OpenStreetMap (OSM) geïdentificeerd met vreemde scherpe hoeken. De meeste hoeken van gebouwen zijn bijna 90 graden, maar deze uitdaging richt zich op gebouwen waar de hoeken minder dan 15 graden zijn. Hoewel sommige misschien echt zijn, zijn er waarschijnlijk veel met onjuiste gegevens. De taak:
Help ons de gegevenskwaliteit van OSM te verbeteren door de geïdentificeerde gebouwen te beoordelen en te kijken of hun vorm een aanpassing behoeft. Belangrijke overwegingen daarbij:
Sommige gebouwen, vooral historische gebouwen, kunnen unieke hoeken hebben.
Als u het niet zeker weet, raadpleeg dan het communityforum voor advies.
De taak leidt je naar het gebouw zelf, niet noodzakelijkerwijs naar het specifieke “scherpe hoek gedeelte” van het gebouw. Zoom zorgvuldig in en zoek naar het probleem.
Waarom het scherpe hoek gedeelte van gebouwen repareren?
Van nauwkeurige bouwvormen op OSM profiteert iedereen! Ze verbeteren:
Datakwaliteit voor diverse toepassingen
Navigatie diensten
Stadsplanning
Noodoproep reactie
Heeft u nog vragen?
Gewoon een reply sturen op dit bericht voor hulp, het wijzigen van instructies of suggesties voor bronnen.
Bedankt voor je bijdrage!
Bij “osm history” wordt de node id als link meegegeven, dit hoort de polygon id te zijn.
Mooi initiatief voor het verbeteren van de datakwaliteit.
Dit geeft zover ik weet geen problemen met de BAG import (goed uitgelijnde gebouwen blijven groen)
Thanks for your input, @E_de_Wit. Rest assured, the task’s location is accurate, and kindly ignore this particular node. We’ve already informed the MapRoulette development team, and they’re addressing the issue.
Dank je voor je input, @E_de_Wit. Wees gerust, de locatie van de taak is nauwkeurig, en gelieve deze specifieke node te negeren. We hebben het ontwikkelingsteam van MapRoulette al op de hoogte gebracht, en zij werken aan het probleem.
Excuse my Dutch as I am still learning the language.
Graag wil ik jullie informeren dat we nog enkele duizenden taken/leads hebben voor de Fix Spiky Buildings challenge op Maproulette waarmee we de challenge kunnen aanvullen.
Hebben jullie nog vragen of suggesties voordat ik hiermee aan de slag ga?
Is het zo dat dit gaat om gebouwen die goed zijn overgenomen uit de BAG maar waarbij de BAG een fout heeft. Of is er bij deze gevallen iets fout gegaan bij de BAG import?
In het geval dat er een fout zit in de BAG dan zou het handig zijn om deze ook door te geven aan het Kadaster.
Bij een deel van de problemen die door de challenge worden gemarkeerd is het inderdaad de geïmporteerde BAG data die een fout heeft.
We zullen deze problemen niet zelf melden bij het Kadaster. Maar als leden van de community dat willen, kunnen ze ook de taken in de Maproulette-challenge gebruiken om vast te stellen waar deze problemen met de geïmporteerde BAG gebouwen zich voordoen en deze eventueel zelf rapporteren.
We hebben de spiky buildings challenge in Maproulette voor Nederland met 511 taken bijgevuld.
Als er vragen of opmerkingen zijn over de challenge kan je ze hier gerust stellen als reactie op dit bericht.
Ik zie in Den Haag - Leidschenveen dat nu af en toe een (gemeenschappelijk) muurtje verdwijnt dat door Kadaster is ingemeten. Ik heb onder een wijziging (# 151462170) gemeld dat dit aanpassen tamelijk zinloos is, want bij een volgende update vanuit BAG naar OSM keren de muurtjes weer terug.
En nee, ik voel me niet geroepen om half Leidschenveen bij BAG aan te melden .
Er staan nog ongeveer 500 taken voor spiky buildings open in deze challenge, allemaal geconcentreerd in Brabant en Dordrecht.
Als er taken van muurtjes tussenzitten kunnen die geskipt worden, maar taken zoals deze bijvoorbeeld kunnen makkelijk gefixt worden
Maar het voelt ook zinloos om dit te fixen als bij een toekomstige BAG-import de foutjes weer terugkeren. Heb zelf inmiddels ook een aantal van deze taken opgelost maar de reactie van @jb54osm zet me wel aan het denken. Wordt hier bij BAG-import naar gekeken (of er rare punten / uitsteeksels aan de omtrek zitten en of deze legitiem zijn zoals dat muurtje)?
Het gaat dan doorgaans om dit soort smalle muurtjes van zo’n baksteen(tje) breed. Het smalle muurtje is dan nog eigendom van (hier) nr. 50, zegt Perceelloep. Het eigendom van nr. 52 begint na de scheiding. (Wel zo handig bij onderhoud; hoeft 50 geen steiger te bouwen op grond van 52).
In deze situaties kunnen bij een import afrondingsfoutjes optreden waardoor een rechthoek een driehoek / punt kan worden.
Dit soort foutjes meld ik altijd wel terug, en worden ook meestal goed ontvangen. Hoewel het een aanzienlijk aantal is over heel Nederland word het per gemeente opgepakt, dus zolang het er maar een paar per gemeente zijn dan lijkt het mij beter om het terug te melden.
Soms kunnen er ook fouten ontstaan door een fout tijdens het importeren, een her import kan dan ook het probleem verhelpen.
Zou dit ook beter zijn bij intersecting buildings (andere MR-uitdaging) wanneer het gaat over twee overlappende BAG-omtrekken? Dus terugmelden i.p.v. zelf fixen? Hier heb ik er ook een aantal handmatig opgelost. Op zich vind ik dat ook leuk om te doen maar zonde als het voor niets blijkt te zijn.
Op zich kan het ook beiden. Er zijn wel problemen waarvan wij/validators het een probleem vinden. Maar waarvan ze bij de bag het geen probleem vinden en het dus ook niet op gaan lossen.
Op dit moment is het zo dat BAG updates niet direct in OSM komen. Dus als je iets fixed in OSM dan blijft dat ook redelijk lang goed. Maar het onderliggende probleem is dan dus mogelijk nog niet opgelost.
Toen wij importeerde was de data van de bag kwalitatief minder, de hoeveelheid ingemeten data was veel minder, daar is men met een inhaalslag bezig. Hierdoor lost misschien het probleem zichzelf op binnen de BAG.
Als geonerd en mag wel zeggen, BAG-expert, vind ik dit een fascinerend probleem en doe graag analyse en een werkmethode:
Het is denk ik goed te realiseren dat er een belangrijk verschil is tussen Panden (contouren, polygonen) in BAG en OSM (voor niet-vrijstaande Panden):
BAG: losse polygonen, geen gemeenschappelijke, identificeerbare ‘Nodes’ anders dan geometrisch samenvallend.
OSM: Polygonen in topologie, identificeerbare gemeenschappelijke Nodes: bijv. tussenmuren rijtjeswoning.
Hierdoor moe(s)t m.i. bij BAG import en denk nu ook bij Updates via JOSM Plugin de conversie van losse polygonen (BAG) naar aaneengesloten topologie gemaakt. Misschien dat intern in de BAG wel gemeenschappelijke punten zitten. Dit is bijv ook bij BRK Percelen: Kadaster houdt alleen grenslijnen bij. Het ‘Polygoniseren’ is onderdeel van export levering. In dit soort bewerkingen speelt tolerantie en afronding een rol, zeker als je ook van RD (BAG) naar WGS84 (lat,lon OSM) gaat. Hoewel PostGIS en bijv denk GeoPandas hiervoor functies heeft. Hetzelfde probleem speelt bij Polygoon-simplificatie bijv BGT.
Mogelijk dat dus veel ‘spikes’, scherpe hoeken, geen fouten in BAG zijn maar zoals sommigen hier aangeven, artefacten, residu-gevolgen van import. Daardoor denk ik ook dat veel van de situaties in de MapRoulette simpelweg met de BAG Update tool kunnen worden opgelost. Er is namelijk een commando (CTRL-SHIFT-G) om gewijzigde geometrie te vervangen. Als proef net uitgeprobeerd:
Bijv deze MR Task: MapRoulette
is deze situatie op Hondsruglaan 68 Woensel-Noord:
Als ik in JOSM met BAG Update Plugin hier de BAG download, zie ik juiste contouren. Echter het lijkt of de Panden in OSM juist zijn (groen). Maar na selectie van Pand (id 0772100000336956) en met CTRL-SHIFT-M, kan ik de BAG versie van geometrie naar de BAG+OSM Laag brengen. Door selecteren in die Laag van nieuw BAG Pand en OSM (met spike) en dan CTRL-SHIFT-G vervang ik de ‘spiky’ OSM-geometrie. Zie changeset.
ik denk dat veel ‘sharp edges’ voortkomen uit BAG-import artefacten
dus (denk merendeel) geen fouten in BAG. Edit: of reeds opgeloste geometrie-fouten in BAG.
in deze gevallen nauwkeurig gefixed kunnen worden: qua geometrie en 1-1 uit BAG, in JOSM met BAG Update Plugin.
Handmatig fixen in Id of JOSM kan natuurlijk. Is dan meer: willen we exacte geometrie uit BAG of “goed genoeg”? Want dit gaat natuurlijk sneller, meer crowd.
Ik heb ook even de hobbel moeten nemen om de BAG Update Plugin (met dank aan o.a. @Sander_H en @roelant) te leren, zelfs met mijn matige JOSM-ervaring. Misschien dat we die kennis sowieso moeten versterken omdat ook de BAG Import via pinned topic ook niet echt opschiet, erg ad-hoc…Denk bijv dat we met een paar BAG Updater online workshops best snel te werk kunnen gaan.
Maar uiteraard zitten er ook fouten in BAG, waardoor denk ook de BAG Update Plugin het niet meer weet, zoals dit BAG pand op Kampakker 26, Eindhoven, via Task: MapRoulette
Ik vind ook dat als de fout in de BAG zit, dit daar via een terugmelding opgelost moet worden. Niet in OSM gaan oplossen. De juiste geometrie komt dan vanzelf weer terug. Als we zelf gaan fixen zal dit altijd een andere geometrie zijn. Dit is een gezonde “Open Source workflow”: meld problemen in de bron, “upstream”, ipv oplossingen implementeren in een eigen kopie van die bron…
Ik ben maar een New Member dus trek je niets van mij aan.
Ik heb mij anderhalf jaar geleden fors gestoord aan allerlei beroerd geplaatste nodes. Dus begon ik uit te lijnen en als je daar dan toch mee bezig neem je meteen steeds meer mee; traffic_signs, traffic_calming, scholen, barriers, begraafplaatsen, playgounds, noem maar op. Ik herken nu aan een polygoon of way vaak meteen de mapper zonder naar het Author te kijken.
Later ben ik gaan inzien dat er nou eenmaal grondverf over de kaart ligt en dat er kennelijk iemand anders moet aflakken.
Terug naar je ‘goed genoeg’ vraag. Waarom zou ons doel zijn om minder goed te zijn dan het gemiddelde in de PDOK?
.
