Today I would like to share a MapRoulette challenge that purpose is to identify and correct cases where building polygons overlap, ensuring a cleaner and more accurate representation of the area’s layout.
How Tasks Were Created: TomTom has generated these tasks by analyzing building data in OSM. Each task highlights a potential intersection between buildings.
Important Note: Some tasks may be false positives, meaning the buildings aren’t actually intersecting in a problematic way. If you come across a task like this, please mark it as “Not an Issue.”
Please don’t hesitate to reach out to me with any comments, feedback, or remarks about this MapRoulette challenge. I want to ensure it meets the necessary standards, and I’m more than happy to answer any questions you may have.
ENG: Yes, the building data in OpenStreetMap comes from the BAG (Basisregistraties Adressen en Gebouwen - the Dutch Cadastre, Land Registry and Mapping Agency’s address and building register), a publicly licensed dataset containing address and building outlines for the entire Netherlands. Our spatial analysis revealed potential issues with this data. The community should be aware of these and correct or clean the map as needed. if you think is not needed then I can simply close/archive the challenge.
Dear Salim, I’d strongly recommend you to stop using literal translations to Dutch in your messages. Most Dutch members of the OpenStreetMap community understand and speak English just fine. Even if someone doesn’t understand English, they can always use a machine translator themselves. Furthermore, the Dutch translations are confusing, and more importantly, sound awkward and even embarrassing or condescending to native speakers.
Two sheds, side by side. Mathematically, they intersect. We can’t tell with our puny human eyes, but I’m sure the algorithm used detected this correctly. Now, if someone fixes this on OpenStreetMap, that ‘error’ is gone, but it will be reintroduced the next time someone uses the BAG importer tool. That means well-meaning mappers are just wasting their time on trivial non-bugs, and their work won’t even be retained.
That seems a bit problematic, don’t you agree?
Of course there are plenty of real overlap errors. Sometimes a building part is tagged as building=* instead of building:part=* and the overlap is real. I did see some examples of that in the challenge. Do you think you could reduce the challenge to buildings with a certain minimum amount of overlap and weed out all the tiny negligible cases? Buildings in the Netherlands on OpenStreetMap don’t have to match their BAG versions, but those that don’t (for a variety of reasons) are really a tiny minority of perhaps some 2 ‰ or so.
Ik heb een aantal van deze kleine gevallen proberen op te lossen met nieuwe BAG imports, en in alle gevallen die ik heb gezien zijn de kleine overlappen na herimport verdwenen.
'Tis ook belangrijk om je tijdens BAG imports te herinneren dat de BAG regelmatig fouten bevat en dat je altijd moet dubbel checken voordat je data upload. 'T idee dat kleine fixes niet toegepast moeten worden omdat ze toch wel weer verschijnen bij BAG updates klopt naar mijn mening dus niet helemaal.
Het is m.i. goed om te realiseren ieder Pand in de BAG een individueel polygoon vlak heeft. De BAG import JOSM plugin zorgt ervoor dat aanelkaar gelegen Panden (bijv rijtjeswoningen) gemeenschappelijke Nodes in OSM krijgen.
In combinatie met fouten in de BAG (altijd terugmelden naar Kadaster!), in later stadium weer opgelost (veel imports zijn uit bulk in 2014) en met hand ingevoerde gebouwen in bijv Id, afrondingsfouten (RD naar WGS84), kan ik mij dit soort “glitches” goed voorstellen.
Ik denk wel dat het oplossen in Id zonder originele BAG geometrie data niet de weg is. In de BAG plugin en plugin-backend-WMS worden veranderde geometrieën dan later weer gedetecteerd. Dus denk dat nalopen/oplossen/terugmelden (via Kadaster BAGViewer) in JOSM met BAG Plugin, een betere weg is.