The Areas view in OSM Inspector shows problems with areas (closed ways, multipolygon relations and boundary relations), e.g. missing or inappropriate role, unclosed ways as multipolygon members or self-intersecting areas.
|This layer replaced the former Multipolygon View on 2016-10-18.|
- 1 Overview
- 2 Data sources
- 3 Layers
- 3.1 Basic geometry issues
- 3.2 Duplicate segments
- 3.3 Intersections
- 3.4 Ring problems
- 3.5 Old-style multipolygons
- 3.6 Ways (context)
- 4 What you can do with this view to improve OSM data
- 5 Discussion
- 6 See also
There are many different ways (multi)polygons in OpenStreetMap can be mapped correctly and there are even more ways in which they can be mapped incorrectly. Of the over 220 million (multi)polygons in OSM more than 100,000 contain mapping errors of one kind or another and about 250,000 are tagged old style with tags on the outer ways instead of on the relation making multipolygon tagging and processing much more complicated and much more expensive than it needs to be.
This view shows many different problems with (multi)polygons in OSM data. This includes problems with multipolygon (and boundary) relations as well as closed ways (which most often are polygons).
All data in this view is derived from OSM data.
Data for the whole world is available in this view.
Basic geometry issues
This layer shows locations where a node appears two or more times directly one after the other in a way or several nodes with the same locations appear directly one after the other in a way.
This is generally not a huge problem, because those cases can be removed when processing the data. But they are still unclean and can be fixed in the data, especially if you are fixing other problems anyway.
One-node member way
A way containing only a single node. Not a polygon-specific problem really, but one that should be fixed.
Shows segments (connection between two nodes) that are part of an area several times. This is often used to create "fake inner rings" where a polygon boundary turns back on itself. This case is not correct and should be fixed. But sometimes the duplicate segments can be correct. Use your judgement.
Way in >1 rings
When assembling the area from its ways, different segments of the same way end up in different rings of the area. Sometimes there is an error in the data here that needs to be fixed, but not all of these cases are errors. Often this is the result of trying to build "fake inner rings".
Area borders may not intersect themselves, because this leads to all sorts of rendering and other problems.
These cases need to be fixed. Sometimes a node can be created on the place where the intersection is, but in almost all cases that is the wrong fix. Usually intersections are the result of a node just moved very slightly or two nodes where there should be one. In most cases a fix is obvious and simple.
This layer shows the points where such intersections happen.
This layer shows the way segments that intersect.
Areas consist of one ore more outer rings, each of those can have zero or more inner rings.
Ring not closed
Rings must be closed (the name kind of gives it away...). If there are ways not forming a ring, there is no area. Sometimes these cases can be fixed easily, but often more knowledge about the broken object is needed. Do not just connect the open ends together without looking at the specific problem!
Touching rings don't have to be a problem. But often they indicate some suboptimal mapping. Sometimes they are the result of nodes snapping to (the wrong) ways in the editor. Seeing the places where rings touch can sometimes help find and resolve other problems. And sometimes they are the result of imports from data that appears detailed, but is really autogenerated from raster data and should me much smoother in reality. Often the result just look wrong. Forests don't have sharp edges that meet at corners.
These cases are often difficult to handle. Use your judgement.
Role should be inner/outer
Way members of multipolygon relations should have a role "inner" or "outer" depending on whether they belong to an inner or outer ring, respectively. An empty role is also allowed, because most programs assembling multipolygons will ignore the role anyway, because it is wrong so often.
These layers show all ways that the algorithm has determined to be inner or outer ways, but that have a different role. (Empty roles are ignored.) Some of these are just typos that can be fixed easily, but often the role contains some useful information, like a proper name or so. It seems many mapper are confused about what the role is for. These have to fixed manually by finding a better place for the information in the role and then correcting the role.
Old-style multipolygon tagging has the tags not on the relation but on the outer ways. This is deprecated now, but is still seen often. One particular sub-variant is that inner ways have the same tags as the outer ways. That is very deprecated and should be fixed. Make sure to move all tags that are used for the whole multipolygon from all outer and inner ways to the relation and leave only tags on the ways if they are meant for that particular way only.
Multipolygon relations with tags on the (outer) ways instead of on the relation. This is deprecated and should not be used any more. Move the tags from the outer ways to the relation.
This shows all ways belonging to any of the areas that have a problem. So if you see anything on one of the other layers, you will have all the involved ways in this layer to give you some context.
This layer is purely for context. Once you fix anything in the other layers, the corresponding ways in this layer will be gone.