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.
.
