OSM Inspector/Views/Geometry

The Geometry view in OSM Inspector shows basic geometry problems such as overlong ways.

Overview

Ways with many nodes are difficult to manage. Long ways with long stretches between two nodes are sometimes not rendered. Ways crossing themselves also lead to rendering problems in some cases. This layer helps finding those problems which are not caused by any tags on the way but just by the basic geometry.

Data sources

All data in this view is derived from OSM data.

Data for the whole world is available in this view.

The OSM data processing of this view is done by osmi_simple_views.

Layers

Long ways with more than 1900 nodes are shown in blue. These should probably be split up into smaller parts. The OSM API allows a way to have up to 2000 nodes.

Ways with long segments (i.e. distances larger than 20 km between two nodes) are shown in green. The way itself is shown as thin dark green line. Long segments are a shown as wide light green lines. There are several reasons why long segments are problematic: By definition the connection between two nodes in a way is a straight line. Unfortunately it is not clear what a "straight line" means on a round earth. See [1], [2], and [3] for some details. Also it depends on the projection ([4]) used for the map whether something that is arguably straight on the Earth will show up as straight line on the map. Due to restrictions in the renderers objects might not show up as they should. The smaller the interval between two nodes is, the smaller the difference between different defintions of "straight line" will be and the smaller the errors due to the projection. So while it might not be a "proper" solution its certainly pragmatic to make the segments shorter. Another problem is due to the current implementation of the OSM API: When requesting all objects inside a bounding box only nodes in this bounding box and ways having a node in this bounding box will be returned. (This is done because it is more efficient.) So the longer the segments are and the smaller the bounding box the bigger the chances that some object will not be returned from the API call and might not appear on the map. This can happen with Tiles@Home for instance.

Self-intersecting ways are ways which cross or touch themselves. Depending on the renderer they might not be rendered properly. They are shown in red. If you zoom in far enough you see the points where the intersections are (Intersection points) as a little red X. Only closed ways are shown in this view, ie ways that have the same node as beginning and end node.

Single node in way shows ways that only consist of one single node. This should not happen and needs to be fixed.

Duplicate node in way shows nodes that appear more than once in a way right next to each other. Say you have a way going from node 10 to node 20 to node 20 to node 30. The node 20 is in there twice. This should not happen and is drawn in pink here. Ways which have to subsequent nodes with different ID but at the same location are flagged with this error, too.

What you can do with this view to improve OSM data

Fix self-intersecting ways

Ways that intersect themselves are problematic for renderers, especially when they are polygons (closed ways). Some software doesn't work properly with such illegal polygons. So it is best to fix them. In many cases the self-intersection is just the result of a node that was moved accidentally. Many other cases involve polygons that should have holes in them and should be modelled with a proper Multipolygon. A collection of best practices can be found in the wiki Fixing OSMI self intersection.

Fix ways containing only a single node

Ways need to have at least two nodes to make sense. Some have only a single node because of some error. Look at those ways and check the tags. If it make sense you can create a new proper way and give it the tags and then remove the ways with the single node.

Fix ways containing duplicate nodes

Can be fixed manually if you come by them by removing all except one instance of the duplicate nodes. But it probably makes more sense to do this automatically at some point.