Ref values pre-processing

[Mashin6]

Some countries have ref values that include additional characters such as A1. But in real life traffic signs only show the number: 1.

vs

The biggest problems this is causing is in Romanian trunk roads shields (#99), but this issue is present in other countries as well:
Germany, Switzerland, Italy, Czechia.

A possibility would be to add a function that would strip of letter characters from refs in certain countries.

[1ec5]

In #119, I implemented a refsByWayName lookup table specified as part of an individual shield definition object. It could be generalized into a function: these European shield definitions would implement the function by deleting the letter, while the Kentucky parkway shield definition could look up the value based on the ref (assuming we don’t find a more data-driven way to implement that shield definition).

[ZeLonewolf]

I think ref pre-processing is something we should do under only extremely exceptional circumstances, if even at all. It sounds like there is a relatively small list of countries that have tagged their highway route relations in a way that's different from the rest of the planet. If that's the case, I'm fairly comfortable rendering them wrongly and suggesting that they might change the tagging to be more consistent with the global trend.

I noticed Italy in that list, and Italy does have the prefix values in their signs so I think in that case the ref prefix should actually be there and be rendered.

[1ec5]

I think a transformation mechanism would be useful anyways. Thinking ahead to when we add the full complement of Texas shields, we’ll probably want to display most of the networks’ shields as something like [FM 1234] and [PA 1502], which would require prepending something to the bare ref that ordinarily shouldn’t be there in the data.

[ZeLonewolf]

Thinking ahead to when we add the full complement of Texas shields, we’ll probably want to display most of the networks’ shields as something like [FM 1234] and [PA 1502], which would require prepending something to the bare ref that ordinarily shouldn’t be there in the data.

This could also be accomplished by making the prefix part of the shield artwork.

[1ec5]

The letters would have to be counterbalanced with whitespace on the other side of the image, which would shift the shield away from the roadway in many cases.

[ZeLonewolf]

The other thought I had for cases like the Texas route was to make the prefix a modifier, so it would render as text above, which could be done right in the shield definitions.

[1ec5]

The other thought I had for cases like the Texas route was to make the prefix a modifier, so it would render as text above, which could be done right in the shield definitions.

#177 does this for Ohio township routes, and it seems like Texas routes would fall into the same boat.

[1ec5]

I think there should be a transformation step, but only one that adds text, not one that removes it. This is a common need for route networks that, for whatever reason, only use one text size on their shields. For example, many Asian route networks are signposted with distinctive shields that put a letter immediately before the route number in the same typeface. For example, the Asian Highway network (#122) is signposted with “AH ###” in most countries.

It would be incorrect to put AH directly in the ref of each route relation, because that would prevent other data consumers from being able to synthesize a name like “Asian Highway 1”. Unlike the British “M1 motorway”, it would be incorrect to redundantly say “Asian Highway AH1”. In my opinion, it isn’t a big deal for Americana to concatenate a prefix onto a ref, but it would be quite unfortunate if other data consumers have to parse ref on relations in the same manner that legacy data consumers had to parse ref on ways.

To keep the preprocessing from being misused for more complex transformations, a shield definition could specify a ref format, similar to the road number formatter property on Wikidata.

[ghost]

A possibility would be to add a function that would strip of letter characters from refs in certain countries.

Yes. If you know that this is a specific road (like an Autobahn starting with "A ") then you can use a slice expression in mapbox. However, it's not supported in maplibre-native and mapbox-native yet, so this would only work on the web.

To figure out if this even an Autobahn in the first place, we'd first have to solve openmaptiles/openmaptiles#1369 (or fill out all the tags in OSM).

[zekefarwell]

@JannikGM, see relevant discussion here #149

[claudiush]

Here's another national freeway shield that might require preprocessing: Iranian shields contain the reference number on the top right in Persian Numerals and bottom right in Western Arabic Numerals (Example shield for Freeway 2: https://commons.wikimedia.org/wiki/File:Azadrah2-IR.png ).
OSM relations contain Western Arabic Numerals in the ref tag and sometimes the Persian as ref:fa. (Example relation: https://www.openstreetmap.org/way/320844736 - Example way with ref:fa: https://www.openstreetmap.org/way/320844736 )
See wikipedia article on Arabic numerals - Theoretically the Persian numerals can be calculated via a Unicode shift from Western Arabic.

[zekefarwell]

Displaying the Persian numerals is probably out of scope for the Americana project. It looks like the western Arabic numerals in a appropriately colored rectangle would work just fine for these routes if we were to add support for them. For a renderer that did want to display the Persian numerals, it looks like reading for the ref:fa tag would be the way to do that.

[ZeLonewolf]

Internationalization of non-latin script numbers is certainly an interesting idea. If anything, it would make more sense to put the whole map in a latin script or a different script, and have that translation be done in the javascript side. I agree with @zekefarwell that we probably don't want to show both simultaneously. Feel free to open a new issue for script toggling, but it's something that requires code changes and a fair amount of thought.

[1ec5]

It is possible, with a glorious hack, to parse a non-European number as long as the input and output languages are known.

/ref openstreetmap/iD#8769

[Blijbol]

The Netherlands also needs ref pre-processing for correct rendering. When written in text, no space is written between the letter and number (e.g. one would write "The A44 was congested.", and hence also the tagging as ref=A44). However, when displayed on signs, there is subtle spacing between the letter (A) and number (44) to enhance readability:

[ZeLonewolf]

The Netherlands also needs ref pre-processing for correct rendering. When written in text, no space is written between the letter and number (e.g. one would write "The A44 was congested.", and hence also the tagging as ref=A44). However, when displayed on signs, there is subtle spacing between the letter (A) and number (44) to enhance readability:

That's a very subtle difference. In general, the highway shields we've drawn on the map at icon size are representative but not perfect replicas of the shields shown in reality. Of course, since most European highways shields are boring shapes like rectangles or hexagons, they usually end up being very close to reality! I'm not sure that this tiny gap is a big enough deal that we need to build in the custom code that would insert a few pixels of space there. I suspect that most Dutch users would recognize the white-on-red shields with or without the additional kerning space.

[Blijbol]

It is of course still recognisable without the space, but the space does improve readability of the map, just like it improves readability of road signs.

[bgo-eiu]

Re: Persian numerals, it is notable that Iran is surrounded by countries that don't use them. Not displaying the numerals would impede recognizability of the shield by removing part of what makes them distinct. I don't know if anyone is looking at Americana while crossing the Pakistan - Iran border yet, but since Pakistan uses "European" Arabic numerals on signs you would see a difference on the ground.

If you didn't understand either numeric system or language involved, you would still be able to recognize the symbols/glyphs if they matched. I would add for English speakers in particular though, Persian/Arabic numerals don't actually differ that much from 1234... etc. if you look at it for an extra moment you can probably tell exactly what number it is without issues.

[1ec5]

This style currently shows labels in English for usability. We aren’t making users figure out Cyrillic text despite significant orthographic similarity to Latin. It is possible to figure out which European numeral corresponds to which Arabic numeral, but not everyone will intuit that it is a comparable numeral system in the first place.

Ideally it would be the responsibility of OpenMapTiles to offer the ref in two writing systems, just as with name:latín. (This would be sensible especially for the UAE, which includes both Latin and Arabic ref prefixes on its shields.) By ensuring we have the data in both writing systems, we’ll have the flexibility to switch between them based on a user language preference. This could even open the door to other transliterations.

[1ec5]

As of #193, we’re also showing some Chinese characters in shields that would ideally be replaced by letter suffixes such as A/B/C or N/S/E/W.

[bgo-eiu]

Hmm I guess I'm sort of confused about what people would find useful here. I think of route numbers as symbols and to that end I would think it would make things easier. Most countries that use Arabic based scripts don't use it for numerals on route shields, so knowing that Iran is different in that regard seems like useful information in itself. Having a transliteration on shields that only changes Iran and a few other countries would seem strange, and it would be misleading to transliterate Roman numerals to something else just because it's in a country which uses Arabic scripts when those numbers aren't used in shields in that country.

I can see the use case for those China shields, but not for the UAE. Most people in the UAE don't speak Arabic and can recognize them just fine, especially since the prefixes don't really convey information on their own and they already use Roman numerals.

[ZeLonewolf]

Support for adding pseudo refs from way names (Kentucky parkways) was added in #119 and support for stacked refs (Italy, et al.) is documented in #366. Supporting network identifiers that are not posted on shields on the ground is not planned, and should be regarded as a tagging error.