fixing-polygons-in-osm
fixing-polygons-in-osm copied to clipboard
osmlab
Overlapping areas
Another thing to fix in/with mps: overlapping landuses/naturals Often, mappers will overlay areas (rather than use distinct polygons or mps), which works for the map (due to rendering z-order), but not for database queries.
Examples:
- lakes within a forest (to be excluded from forest multi/polygon)
- different areas of wetland (to be marked with wetland=*; e.g. wetland with trees is wetland=swamp, not wetland on top of a regular forest)
- farmyards/residential areas/meadow embedded in farmland/forest
- industrial area embedded in residential area
Some examples can be seen nicely on the map, given that symbols are drawn after colored areas. This causes e.g. tree symbols on top of incorrectly overlaid water areas.
But: sometimes overlaps actually make sense Examples:
- a quarry (for gravel) will often contain an artificial lake which is part of the mining operation and should therefore not be excluded from the quarry area
- a park area containing patches of grass and forest
- ornamental grass in residential areas (if too small for park)
So, as usual, judgement (and guidelines) will be required. In the above examples, the lake may or may not be part of the underlying area. That said, it's another huge area to be worked on.
@wolfbert Yes, that is something we should eventually work on. But, as you noted, it very much depends on the tags. This needs somebody who want's to look at existing tagging practice and figure out tag combinations that are good/bad.
One approach to the above is the discussion on the "landcover" tag, which might mean that there is a single layer of adjacent polygons describing the surface of the earth and another sparse one ("landuse") on top to describe human usage of that surface. Intersecting the two would give both an "is-distinct-from" and "is-part-of" relationship. No concensus has been reached however, and the tags are neither rendered nor in widespread use (19.000 at the moment). Also, the transition required would be substantial.
It seems that for the time beeing we'll have to work with what there is, and I'm happy to collect my thoughts in a document for discussion when the time comes.
Just to add to the cases with forest that openstreetmap-carto made the intentional decision to move to a rendering where the tree overlay covers the inner areas so that these are more visible and eventually get fixed.
As I see Mapbox is analyzing this type of problems.
- discussion mapbox/osm-compare/145:"Analysing overlapping features in OSM using tile-reduce"
- code: https://github.com/amishas157/feature-overlap-tile-reduce
