Handle route relations for roads

[pnorman]

Highway refs are often indicated by route relations, so we need to support them.

One relation may be part of multiple road route relations, each of which has a ref and network tag. They also might be part of no road route relations and have a ref tag. I don't think we need to handle the third case of a ref tag plus refs from relations any different than the first tag.

[westnordost]

Bake the refs of the route relations onto the roads, right?

[pnorman]

Yes, we need the line strings to have appropriate properties. The difficult part is handling multiple relations.

[1ec5]

Route relations intentionally provide more structure than way refs, so the two mechanisms aren’t quite equivalent – the structure should persist in the tile’s features to some extent, or it would defeat the purpose of route relations. openmaptiles/openmaptiles#1620 adopts a predictable route_#_key format for properties dissolved from route relations, allowing clients to process each value without resorting to any parsing.¹

If you need to cap the maximum number of concurrent routes along a given way for performance reasons, here are some statistics to help you arrive at a practical limit: osm-americana/openstreetmap-americana#894 (comment) osm-americana/openstreetmap-americana#894 (comment).

Footnotes

1. This would also be a sound server-side solution to the problem of pretty-printing semicolon-delimited value lists. ↩

[pnorman]

@1ec5

For each route relation, what information do we need to bring onto the way? e.g. part of the I 5 would have a relation with ref=5, route=road, and network=US:I.

Would this then give route_1_ref=5 route_1_network=US:I route_1_type=road?

I think one requirement is that you get sensible results if you write a style that only uses the ref attribute on the objects. Does this mean that we'd have (in addition to the above fields) ref=5?

[1ec5]

Would this then give route_1_ref=5 route_1_network=US:I route_1_type=road?

Yes, just like that. The style would then be able to choose an image based on route_1_network and overlay route_1_ref on top of it. route_1_name and route_1_color are also useful in some regions. You’d want to deduplicate two route relations that differ only in their direction=* tags.

The schema could do some things OMT doesn’t. For example, it could try to normalize the network identifiers to have more consistent capitalization and abbreviation style. OMT normalizes the main network field into its own classification, but it keeps the route_#_network verbatim. OMT doesn’t currently expose the route=* value as route_#_type, but that would be useful for distinguishing recreational routes from highway routes that could share the same roadways.

I think one requirement is that you get sensible results if you write a style that only uses the ref attribute on the objects. Does this mean that we'd have (in addition to the above fields) ref=5?

Such a style would probably be assuming the format of a roadway’s ref=* tag, which indicates both the route network and route number in a more or less human-readable format. For example, network=US:I ref=5 would become I-5. Otherwise, exposing just the route relation’s ref=* tag would create ambiguity in many countries. (This is why these countries indicate the network inside the way ref, after all.)

Unfortunately, reconstructing the human-readable format from the network=* tag is nontrivial and probably impractical inside a MapLibre style. A Shortbread implementation could hard-code a lot of heuristics for pretty-printing that vary by network. At build time, it could query Wikidata for these formats to generate the SQL code or whatnot.

Separately, OMT synthesizes “networks” for the UK and Ireland. These countries officially only number roads, whereas routes have colors but not numbers. To an end user, this is a distinction without a difference, so OMT makes sure a style can display shields in the British Isles even if it only codes for route relations and not way refs.

By the way, I think the ref_rows and ref_cols fields are mostly redundant. A style that’s going for a rounded rectangle like in OSM Carto would need only a single image that stretches between the corners, and the symbol layer would fit the icon to the text. I suppose knowing the number of (newline-delimited) values could be useful for something, but the schema doesn’t provide that information for any other value that can be semicolon-delimited.

[pnorman]

The state of route relations is worse than I had remembered :(

Unfortunately, reconstructing the human-readable format from the network=* tag is nontrivial and probably impractical inside a MapLibre style.

Yes, this is unfortunate. There's been a push towards the assumption that styles are going to do a bunch of country-specific route relation processing on the network tag. This is not practical as there is no global way to parse the network tag, and expecting general-purpose styles to have hundreds of rules for route relations isn't reasonable.

A Shortbread implementation could hard-code a lot of heuristics for pretty-printing that vary by network. At build time, it could query Wikidata for these formats to generate the SQL code or whatnot.

We can never expect implementations to pull down definitions at build time, and I don't think requiring 400+ formatting rules in the spec is reasonable.

By the way, I think the ref_rows and ref_cols fields are mostly redundant.

In Maplibre, most likely. Not in Mapnik.

[1ec5]

Yes, this is unfortunate. There's been a push towards the assumption that styles are going to do a bunch of country-specific route relation processing on the network tag. This is not practical as there is no global way to parse the network tag, and expecting general-purpose styles to have hundreds of rules for route relations isn't reasonable.

I don’t think ref formatting really needs to concern the specification, as the visual treatment will depend on the style. A data visualization basemap can likely get away with labeling Interstate 5 as a plain “5”, if at all. A map that places slightly more emphasis on transportation probably should display graphical shields in regions that primarily use them to communicate the network. So should an outdoors-focused map when it comes to recreational routes. I recognize that this isn’t as easy as the traditional approach of slapping a tag value on a capsule, but it is a strong user expectation reinforced by major parts of the OSM ecosystem that already support it.

Hopefully there isn’t any reason to parse either network=* or ref=*. In most regions where an alphabetic prefix is a core part of the route number, that prefix is already included in the route relation’s ref=*; a data consumer should not attempt to append one based on the network=*. Of the countries you listed in openstreetmap-carto/openstreetmap-carto#596 (comment), most are consistent about whether to include the prefix in the route ref=* based on the signs. Over the last couple years, OSM Americana contributors have worked with a number of countries to add or remove prefixes based on the signs, leaving a handful of prominent outliers like Germany, Brazil, and maybe South Africa (depending on whether you consider them to still use shields or not).

We can never expect implementations to pull down definitions at build time, and I don't think requiring 400+ formatting rules in the spec is reasonable.

Given the inherent complexity, Shortbread can reasonably choose not to support human-readable formatted route numbers based on route relation ref=*s. I normally don’t bring up Wikidata’s coverage of formatted road numbers in a style context, because they’re much more useful in other parts of a navigation system’s UI and in voice guidance instructions, for which generating definitions at build time is quite feasible.

Shortbread clients’ efforts would be better spent figuring out how to display graphical shields. For the Web, the maplibre-shield-generator plugin can draw shields based on raw network=* and ref=* values, covering a litany of edge cases. There isn’t an equivalent library for native platforms yet.

In Maplibre, most likely. Not in Mapnik.

Oh, I wasn’t aware that Shortbread is also targeting Mapnik styles. That could turn out to be an important constraint worth documenting somewhere.

[pnorman]

My thoughts are

• we need to keep ref_rows and ref_cols for 1.1 but can reconsider for 2.0
• I've gone back and forth on if we should reformat network to something consistent
• I'm inclined to keep ref around and allow it to be from a route relation if the way lacks a tag

I like the idea of putting multiple matching sets of attributes similar to OMT, and allowing the implementations to cap them at an arbitrary number if they choose so.

What I don't like is the specific route_1_ref route_1_network route_1_type details. Picking part of US 101 as an example I see 11 relations. Sorted in API order gives

N	route_N_ref	route_N_network	route_N_type
1	N2002	Flixbus	bus
2	2000	Flixbus	bus
3	N2003	Flixbus	bus
4	2008	Flixbus	bus
5	55	MST	bus
6	101	US:US	bus
7	none	none	road
8	121	VTA	bus
9	N2006	Flixbus	bus
10	2000	Flixbus	bus
11	none	US:NHG	road

We can sort in order of "importance" within the route=road options, but that doesn't solve the problem - we don't know if a cycle, walking, bus, or road network is more important to the users of a style. I think we need an easy way for the style to get at the most important road relation a way is a member of, and the same for other route types.

How about route_road_1_ref, route_road_1_network, ... and the same for other route types we want to cover? If a style is doing sophisticated stuff with concurrencies the information is there, but if it's like most styles and they're just taking the top 1-2 values they can do so easily.

The look at the US 101 example does reveal additional questions

• what do we do about routes that have the same ref, network, and type? (e.g. 2 and 10 from above)
• How do we handle routes with names but not a ref? (e.g. 7 and 11 from above)

I think we can de-duplicate routes as part of sorting. I'm not sure how to handle names.

[pnorman]

How about route_road_1_ref, route_road_1_network, ... and the same for other route types we want to cover? If a style is doing sophisticated stuff with concurrencies the information is there, but if it's like most styles and they're just taking the top 1-2 values they can do so easily.

Does anyone have feedback on this? If not, I can draft some text.

[1ec5]

How about route_road_1_ref, route_road_1_network, ... and the same for other route types we want to cover? If a style is doing sophisticated stuff with concurrencies the information is there, but if it's like most styles and they're just taking the top 1-2 values they can do so easily.

Yes, this is a sound approach. This is exactly what OpenHistoricalMap ended up doing in OpenHistoricalMap/ohm-deploy#600. Even road-focused maps always list, say, all the highway route shields before all the recreational route shields. I don’t think I’ve ever seen a map interleave the route types, sorting them by number alone.

OpenMapTiles’ omission of the route=* value from the property names was an oversight because OSM Americana was so focused on highway routes at the time: openmaptiles/openmaptiles#94 (comment). At this point, OMT can’t fix that without breaking backwards compatibility; all it can do is add route_bicycle_1_network alongside route_1_network, making the “road” implicit.

I've gone back and forth on if we should reformat network to something consistent

If so, definitely consider putting cycle_network=* in a more generally named property, so that clients don’t have to special-case some sort of unwieldy route_bicycle_cycle_network property.

How do we handle routes with names but not a ref? (e.g. 7 and 11 from above)

Realistically, some routes are only known by their names, not their numbers. Named routes have different treatments depending on the style and route type. Trail maps often make initialisms out of the names, while road maps often use the names to select one-off shield designs. For the former, OpenMapTiles exposes short_name=*. For the latter, wikidata=* would be even more useful than name=*.

what do we do about routes that have the same ref, network, and type? (e.g. 2 and 10 from above)

The reason for this redundancy is a separate relation for each direction that the route travels. In each pair of relations, each relation should have distinct from=*/via=*/to=* tags (as required by the PTv2 schema) or distinct direction=* tags (more typical of highway routes).

We should deduplicate any set of relations for which the properties exposed by the tiles are identical. The catch is that the PTv2 schema requires name=* to be unique to a fault. If we also expose the name of each relation, we can’t deduplicate public transportation routes that would otherwise be identical in most stylesheets. But I think that’s a problem for the mapping community to solve.

[pnorman]

If so, definitely consider putting cycle_network=* in a more generally named property

I hadn't considered handling different tags depending on the route value but I guess cycle network stuff is a bit different from anything else

[1ec5]

I started a discussion on the forum about whether to migrate routes from route=* state=proposed to route:proposed=*. This tag is a special case that every data consumer currently needs to implement in order to avoid misrepresenting proposed route designations as current, usable routes for wayfinding.