Adding country tag to transportation_name

[JannikGM]

We'd like to add country-specific road shields in our mapbox map (which has a custom style already).

Our focus is on Germany and surrounding countries. However, most of the German roads don't have the network tag and the way to discern most road-types is by their ref (such as "A #" for Autobahnen).
While we can probably write mapbox expressions to detect the pattern in ref, it might cause false-positives, because we don't know if the road we found is actually in Germany or some other country (what happens if another countrty also has "A 7"? We don't want it to be misdetected to be an Autobahn).

So our idea was to add a country tag (ISO3166-1 of surrounding country) to our transportation_name.
We are aware that this isn't a simple punch through from OSM, because OSM doesn't have those tags on the roads either.
So this likely involves checking if a feature is inside a country border (or is there an existing relation?).

However, we are not familiar with the openmaptiles codebase and will probably need some guidance for the PostGIS.

1. First of all: Is this even a good approach for country-specific road-shields? How do others do it?
2. How would we add the country tag to transportation_name? Is this even feasible with the current openmaptiles architecture?

[wipfli]

@ZeLonewolf and friends started this nice new map style which focuses on shields if this is what you are looking for. See ZeLonewolf/openstreetmap-americana#141.

[wipfli]

And if you want to generate vector tiles for the OpenMapTiles schema yourself, I strongly recommend using planetiler. It is a new tool written by @msbarry which is 160x faster than the traditional OpenMapTiles tools. See https://github.com/onthegomap/planetiler and some of my gists on customization, e.g. https://gist.github.com/wipfli/02ba9081b26c3a0cfae054e5c5402fe7

[zekefarwell]

For some reason, the network value used in OSM for Autobahnen is BAB with no country code prefix. Adding prefix (DE:BAB) would disambiguate from routes in other countries, but there seems to be resistance to this idea in the German mapping community
https://forum.openstreetmap.org/viewtopic.php?id=74873
https://forum-openstreetmap-org.translate.goog/viewtopic.php?id=74873&_x_tr_sl=de&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp
I encourage you to reach out to the German mapping community explaining what you are trying to achieve and how route relations with unambiguous network values would help.

[JannikGM]

The BAB value doesn't even seem to end up in the tiles network tag for any Autobahnen I have checked (checked in maputnik using https://api.maptiler.com/tiles/v3/tiles.json?key={key} and https://zelonewolf.github.io/openstreetmap-americana/ - where they return "network": "road"). Instead, it's usually only visible as part of the route_1 tag in transportation_name (checked in https://zelonewolf.github.io/openstreetmap-americana/; maybe using planetiler?).

[zekefarwell]

I'm not sure how the network field gets populated by OpenMapTiles, but it clearly isn't the original value of the OSM network tag from a route relation. In the schema documentation it says:

The network type derived mainly from network tag of the road. See more info about us-*, ca-transcanada, or gb-*.
So it seems OMT does some data processing and only populates network values for certain road networks.

The route_n (1-6) fields were recently added to OMT and are a more direct representation of OSM data. They pull data from route relations, and the format is route_n: {{network value}}={{ref value}}.

[ZeLonewolf]

The way @zekefarwell described it is correct. The network and ref tags are a legacy approach to route labeling that doesn't handle things like concurrencies and instead takes the "most important" combination based on a rudimentary algorithm. That's why the route_n approach was developed, to properly support multiple routes simultaneously on a road - for example, E-roads and national A routes that share a road (as well as far more complex situations in the US). It's certainly possible to add additional national cases to the importance algorithm, but route_n handling will be the most robust approach that support concurrencies.

[ZeLonewolf]

Forking the openmaptiles codebase to add country-specific processing sounds like an awfully painful workaround for the lack of road route relations in certain countries. The most straightforward approach to highway shields is simply to add route relations where they're missing, and then openmaptiles/planetiler will be able to produce highway shield-compatible vector tiles out of the box. This is a mapping problem, not an openmaptiles problem.

[JannikGM]

I agree.
But I'm also starting to think this might also be a problem in the tiles due to regional OSM mapping differences (which do exist, unfortunately).
OSM existed before and has regional standards that openmaptiles ignores (which is also expected).
While there are some global standards, there are some things which work differently in certain countries and getting them to agree will be a large task.

For the meantime, I'd prefer if there was a country / mapping_standard tag, to identify which country a feature belongs to, so regional mapping differences can be handled in styling.

For example, while Germany currently uses network=BAB in a relation for the Autobahnen (when it really should be network=DE:BAB, but that's another issue).
However, there's no network tag at all on Bundesstrassen. Instead, the assumption is that all routes in Germany starting with ref=B will be Bundesstrassen. This is a problem for generated tiles, because there's absolutely no way of knowing wether the road is part of German mapping standards (as other revealing tags like the operator name have also been stripped).
At the same time, openmaptiles assigns "road" as network value, which doesn't align with the more common, country-code prefixed, network tags either.

Adding the proper network tags on a global scale will be tedious and will probably take some convincing within the mapping community. So this should definitely happen, but it will take a lot of effort and time.

Instead, adding a country / mapping_standard tag could be a good workaround.
While it is somewhat hacky, it will certainly help businesses which create their maps for customers in specific regions (in our case, that's mostly around Germany.. for now).