Centreline problem

[systemed]

(As discussed briefly at SOTM 2022.)

OSM represents many real-world objects, particularly roads, as centrelines. This is simple, intuitive, and appropriate for most uses such as small/medium-scale cartography and routing/navigation. Usually, though, these objects exist in the real world as a significant area whose extent is not captured by a centreline.

Existing practice - areas

Rivers were the first object where the centreline/area split was tackled, very early in the history of OSM. The solution adopted was to have two objects: a centreline way (waterway=river) and an area way (originally waterway=riverbank, latterly natural=water, water=river). There is not usually any data linkage between the two other than that implied by geometry.

In some places a similar approach has been taken for roads (e.g. Cornmarket Street, Oxford). This, however, is comparatively uncommon - in central London and Paris, for example, most roads are still bare centrelines. Highway areas are probably most commonly used for squares/piazzas and other permeable pedestrian spaces.

There is currently no widespread support for area routing nor any sign of movement towards it. Nor are the generalisation functions that would be needed to turn areas into single centrelines for small/medium-scale cartography widely available. So it looks likely that centrelines will continue to be part of the picture for years to come. Given that, in this discussion I'm aiming to identify the challenges with our centreline approach which need to be overcome.

Existing practice - "children" of centrelines

A centreline way may represent several (parallel) linear geometries. This started with attributes such as cycleway=lane or cycleway:left=track, but has since evolved into distinct tagging languages such as the lanes syntax. This tagging inevitably becomes insanely complex.

What's the problem?

A picture is worth a thousand words, etc.:

(location)

In reality:

Where the cycleway and the motor vehicle carriageway are physically separated, the mapper has used separate ways. This implies a diverging geometry (in this case modelled with 45° turns) that simply isn't there. In reality, the driver/cyclist simply carries on along their existing course. This is very misleading cartographically and challenging for routing.

Another extensively discussed example is "pencil-tip" intersections (see also community.osm.org).

Essentially, the centreline model breaks down at the interface between different centrelines within the same real-world object.

The "tag the children" approach tends towards the complex: as ever, difficult tagging/modelling in OSM is routinely ignored by the biggest consumers. It encourages long colon-separated tags which are complex for the mapper (particularly the newbie/casual mapper) and the consumer alike. It is inevitably limited in the fidelity of its geometries: you could potentially model that a cycleway was consistently 5m offset from a carriageway centreline with something like cycleway:left:offset=5, but not much more than that.

Solutions

Well, if I knew the solution I wouldn't be here ;)

Is this a data model issue? It might be! Or it might not!

Certainly some of the issues could be ameliorated with tagging. For example, adding a tag such as junction=diverge at the diverge points in the first pictured example could be a hint to the router that this is not a real 45° turn as modelled in the geometry. I fear however that this may be piling kludge upon kludge.

It could be possible to model the relationship between centreline(s) and their enclosing area. This could be done in several ways:

• An OSM relation, whose members had area and centreline roles¹
• A direct attribute in the OSM model (e.g. <way id="12345" enclosed_by="56789">, where way 12345 is the centreline (or one of several centrelines) and way 56789 is the enclosing area
• A tagging/modelling convention which enables the relationship to be derived programmatically, such as:
  • The enclosing area should be tagged with area=yes
  • The enclosing area should have the same principal tag (e.g. highway=primary) and identifying tags (e.g. name and ref)

A similar approach might apply to "child" centrelines, e.g. lanes within a road, allowing them to be mapped as discrete lane geometries rather than requiring a complex tagging language.

Or there might be other ideas!

Footnotes

1. I'm personally sceptical of this approach: relations are for metadata, not geometries. Multipolygon relations were a major error in the evolution of OSM I wouldn't like to repeat. But other opinions are available! ↩

[mvl22]

The issue isn't really 'centreline', it's more that currently we are representing things that are spaces (namely roads etc) as lines. That inevitably leads to compromises.

This issue is also discussed extensively in this talk I gave at State of the Map 2019:
https://www.cyclestreets.org/news/2019/09/22/sotm2019/

A tagging/modelling convention which enables the relationship to be derived programmatically, such as:

• The enclosing area should be tagged with area=yes
• The enclosing area should have the same principal tag (e.g. highway=primary) and identifying tags (e.g. name and ref)

I don't think we need any changes at all to the data model.

The view I've come to is that the area approach should solve the problem pretty well. We need both vector lines for routing, and areas to associate those lines and provide benefits for cartography.

All that's needed is to surround an existing junction with something like area=yes + junction=yes or maybe area:junction=yes. Ditto a highway. This should surround all the objects that are part of the junction, or for a highway, the edge-to-edge area.

The Straßenraumkarte project shows what can be achieved with this approach:
https://strassenraumkarte.osm-berlin.org/posts/2021-12-31-micromap-update

Having added areas around existing features, an ST_Intersects/similar -style query can then be used to pre-process data. For instance:

• We can then tell that a cycleway alongside the road is related to the road itself, because they will be within the same area;
• We can then tell that entering the junction from one way and leaving by another is say an overall right-turn, even if the exact geometries of each way has more complex turns within it;
• We can associate road names onto a pavement/cycleway alongside;
• We get the best of both worlds: linear vector lines which any standard routing engine can continue to use, but the option of adding in this additional information to perform more advanced analysis and connection of data;
• Cartographic rendering can use the area for additional hinting.

I think trying to associate things directly by using way ID references or relations, is doomed to failure, because it will be hard to maintain.

Drawing an area does actually add additional information that we don't currently capture: highway boundaries. Highway lines represent flows, and the area represents the area in which those flows exist. This seems to me a very pure model, matching the real world well. There doesn't need to be a direct ID-based connection between the two, as ST_Intersects-based matches (well supported in databases/libraries), can achieve the same thing.

The addition of areas is also backwards compatible - it needs no fundamental change to the OSM data model, and can be used immediately. It is the classic approach of 'start basic, enhance later'.

I have drawn an example here. The tagging is experimental and needs to be decided on by the community, but the drawing hopefully shows the principle. You can see that all the junction features, whether highways, pavement/sidewalks, bits of concrete, trees, whatever, all of which a human sees as 'the junction', is surrounded with a simple polygon enclosing them but not formally joining them.
https://www.openstreetmap.org/way/1069011490#map=19/52.20265/0.13140&layers=D

I'm sure there will still be issues to work out like multiple levels, but I think these can be worked through.

[Kovoschiz]

Defining this still has problem in both dimensions:

• Longitudinally, it's not clear what its extent is. Very long slip lanes; extremely large unconventional intersections, including jughandles (already assuming Continous-Flow Intersection / displaced left-turn is split); bus pre-signal; diverging and merging lanes; detector loops, cameras; stairs and ramps for footbridges and subways. When there is 3D at overpass or underpass and interchanges, it falls apart vertically,
• Transversely, this are overlapping with the wider landuse=highway (road corridor, land RoW) and narrower area:highway= (roadway / paved surface, or carriageway / traveled way).

When you further add other area:highway= besides the 2 area:highway=traffic_island, the necessity and clarity of this becomes lower. The task is already made easier by the existence of barrier=kerb lines.

If partitioning out the intersection for rendering is the focus, this doesn't need to be so broad.

[Kovoschiz]

Solutions

Tagging

placement=transition already exist to show deviation from alignment implicitly. It can be specified with *:start= & *:end= when applicable, since it unfortunately expects continuous (viz width=) not discrete numbers (ie lanes=). T
There's a method in reverse by indicating junction=intersection on the "box" of a dual carriageway intersection. This partially helps with some other issues with handling such areas.

Object

1,2,3. As mentioned by another above, a spatial relationship could be good enough at first. Crucially, it should be noted there's not necessarily a one-to-one area--linear correspondence. Eg a road paved with different materials across could be surface:lanes=concrete|asphalt|asphalt|concrete with 3 area:highway= of different surface=, resulting in many-areas-to-one-line.
3.1. Aside from the lack of a one-to-one correspondence, you have to deal with omnidirectional area routing. Which currently requires mulltiple lines to be drawn inside to be routable. Another situation is water flow continuing through a (non-linear) waterbody, leading to (potentially multiple) waterway= drawn across a natural=water. Both causes many-lines-to-one-area.
3.2. Aside from differing attributes (not to mention junctions), currently there are advice against duplicating them to keep it simple. This includes both area:highway= and natural=water + water=river.

Lanes

Without having anything to do with the application of this, I don't believe linear representation of lanes is a good idea. Lanes are in contact with each other (further requirement to relate them with each other spatially or explicitly), can cross wildly (resulting in a complex web of lines), are indicated by markings that can change or degrade easily (difficult to maintain and judge), and lead to the question of whether there will be sub-areas too. Using areas for lanes additionally (to the lane lines) or alternatively (inside the roadway area) is again very complicated, and overlaps with the roadway area (ie the question of sub-areas). Personally, I imagine drawing lane markings for to delineate lanes inside a roadway is best at first.