Make Dutch highway shields more recognizable (spacing, font?)

[louwers]

See also e.g. Wikipedia https://en.wikipedia.org/wiki/A10_motorway_(Netherlands)

In France they also put a space and it is showing up correctly.

[claysmalley]

The Americana renderer takes no stance on matters of local formatting and punctuation—the ref=* value is displayed verbatim, as it is tagged in the OSM database. So the Dutch OSM community would need to agree to retagging all the relations.

cc @Blijbol

[louwers]

@claysmalley Well, the official names are without a space, and when referring to highways in text we also don't use a space. So there is no chance this would garner any support from the Dutch OSM community.

However if your cartographic goal is to have accurate representations of highway shields (which I think is the case¹), you should use a space.

I think France's spaces in highways might be a case of https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

Footnotes

1. "Highway routes are identified by shields that resemble the signs on the road, with special support for roads that carry multiple routes concurrently." ↩

[claysmalley]

However if your cartographic goal is to have accurate representations of highway shields (which I think is the case), you should use a space.

Our goal with shields is not necessarily to have a perfect copy of what's on the ground, but to stylize and simplify a little so that they look good on a digital map, and provide a data-driven renderer that displays shields for route=road relations, however the local community has tagged them. It's up to the local community to adopt a tagging scheme that matches shields, or not.

Near where I live, there is a highway called Interstate 540, or I-540 for short. The relation for I-540 is tagged ref=540, because that is the text present on signage, and we've chosen as a community to match ref=* to the text on signs. The "official name" isn't in the relation at all.

[ZeLonewolf]

Based on the initial photograph of the overhead signage (not the vector graphic below it), I am not seeing a space between the letter and number, or if there is a space, it is very very tiny. If you compare the A50 in the photograph to the A59 in the vector graphic, the space between "A" and "59" is much larger than the space between the "A" and the "50". Just eyeballing things, I think the vector graphic is putting a bigger space in than the signs say in reality.

All this to say -- I am not convinced there should even be a space between the letter and number based on what I'm seeing here.

[louwers]

@ZeLonewolf Right. I don't think it is a space. I sent an inquiry to Rijkswaterstaat and asked for clarification.

[ZeLonewolf]

I would also point out our style contributor's guide, which has this to say about shield design:

In general, this style is not trying to exactly replicate highway shields as seen on signage. Instead, we are trying to extract the key stylistic elements so that the graphics are recognizable as simplifications of their real-world counterparts.

Some number of years ago, @kennykb developed a map with photo-realistic highway shields with extraordinary attention to detail. Unfortunately, images of this map seem to be lost to time.

His map even went to the level of detail of rendering shields where suffix letters were drawn in a smaller font than the main route number, as shown in the "5A" and "5B" examples here:

We have not, so far in this project, attempted to micro-style these differences, as shown in our on-map rendering of New York state route 5A:

The only exception I can think of where we have consensus for micro-styling of text in this project is #366, which proposes to handle cases where shields have two rows of text by rendering the / character which appears in the ref tag as a line break. However, in those cases, the contents of the ref tag alone provide the information needed for the renderer to produce the line break behavior in a general way.

I would consider this described issue to be closer in nature to the New York case, which is one example of a class of text renderings that have minor stylistic adjustments on the real-world signs that we wouldn't produce a distinction for on the real-world map, if indeed there is a "less than a space" gap between characters.

There are other route networks where the space is explicit, both on signage and in the map:

If we find that in the Dutch case, spaces are being introduced in signage, this suggests that spaces should be inserted in the tagging as well. In the more recent photographs, it appears that the Dutch routes are following the text layout of European E-routes, which do place the space in the ref tag.

In summary, I agree with @claysmalley's assessment that this is a tagging issue to be sorted out with the Dutch mapping community rather than a styling requirement that the renderer should address.

[kennykb]

Hi. For what it's worth, I still have everything that I used with micro-rendering highway shields, the lion's share of which came from Phil! Gold. Brian's contention that it's 'lost to time' is not accurate. I didn't really like the results - the realistic shields were unreadable at the scale at which they'd appear as route indicators on maps. For that purpose, I really like the work of Minh Nguyen and others in developing highly stylized indicators of the general shape and colour that remain readable at small scale. (I never worked that into my proof-of-concept map because Minh's version, at least, depended on a somewhat incompatible technology stack. Nothing unfixable, but it just didn't work for me at the time.) But the results that I had were, I thought, better than the simple rectangle of OSM, which becomes unusable in the common case in the US where three, four, five different route networks with incompatible numbering are overlaid.

…

On Mon, Aug 12, 2024 at 1:05 PM Brian Sperlongano ***@***.***> wrote: I would also point out our style contributor's guide <https://github.com/osm-americana/openstreetmap-americana/blob/main/CONTRIBUTING.md>, which has this to say about shield design: In general, this style is not trying to exactly replicate highway shields as seen on signage. Instead, we are trying to extract the key stylistic elements so that the graphics are recognizable as simplifications of their real-world counterparts. Some number of years ago, @kennykb <https://github.com/kennykb> developed a map with photo-realistic highway shields with extraordinary attention to detail. Unfortunately, images of this map seem to be lost to time. His map even went to the level of detail of rendering shields where suffix letters were drawn in a smaller font than the main route number, as shown in the "5A" and "5B" examples here: image.png (view on web) <https://github.com/user-attachments/assets/53eeb14a-cc8a-4b6a-8a9e-2990333f5efc> We have not, so far in this project, attempted to micro-style these differences, as shown in our on-map rendering of New York state route 5A: image.png (view on web) <https://github.com/user-attachments/assets/392c746c-8843-4798-9b52-02bfdc97bf7b> The only exception I can think of where we have consensus for micro-styling of text in this project is #366 <#366>, which proposes to handle cases where shields have two rows of text by rendering the / character which appears in the ref tag as a line break. However, in those cases, the contents of the ref tag alone provide the information needed for the renderer to produce the line break behavior in a general way. I would consider this describe issue to be closer in nature to the New York case, which is one example of a class of text renderings that have minor stylistic adjustments on the real-world signs that we wouldn't produce a distinction for on the real-world map, if indeed there is a "less than a space" gap between characters. There are other route networks where the space is explicit, both on signage and in the map: image.png (view on web) <https://github.com/user-attachments/assets/cebc9b37-a968-457e-be51-ca1dd5a79c40> If we find that in the Dutch case, spaces are being introduced in signage, this suggests that spaces should be inserted in the tagging as well. In the more recent photographs, it appears that the Dutch routes are following the text layout of European E-routes, which do place the space in the ref tag. In summary, I agree with @claysmalley <https://github.com/claysmalley>'s assessment that this is a tagging issue to be sorted out with the Dutch mapping community rather than a styling requirement that the renderer should address. — Reply to this email directly, view it on GitHub <#1148 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABU6UMLGYAGRX6CRDFO7L3ZRDTOPAVCNFSM6AAAAABMMJU7YOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBUGUYTKNRWGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- 73 de ke9tv/2, Kevin

[Blijbol]

According to the Nationale routenummering (Rijkswaterstaat, 1982), the correct way to write the numbers is without space (page 5):

Het verdient dan ook aanbeveling te spreken of te schrijven over bijvoorbeeld de A12, de N264, de s105 en eventueel over de E35.

The refs in the Netherlands are tagged as such (except s-roads nowadays use uppercase S, which was an actual change at some point in time).

However, for readability there has always been slight spacing on road signs, as you can see in figures 2.1 through 2.4 of the same document. The exact amount of spacing varies depending on when the road sign was designed and by whom (there have long been major differences between Rijkswaterstaat and ANWB). However, the spacing is always less than a full character and can't be considered a proper space character. Meanwhile milestone signs show no spacing at all.

So this is basically a stylistic choice for the renderer, not a tagging problem. Even though Americana has no policy of exactly replicating road signs, it might be interesting for Americana to consider modifying spacing for better international consistency, e.g. by inserting/modifying spaces in ref values via network-dependent regular expressions. This way you can also work with special Unicode space characters of various widths.

[louwers]

From my subjective experience, having been exposed to these shields all my life, I cannot say that I find the Dutch highway shields in Americana particularly recognizable.

If we find that in the Dutch case, spaces are being introduced in signage, this suggests that spaces should be inserted in the tagging as well.

Disagreed. The official references of these highways are without a space. Adding a space would be a case of Tagging for the Renderer.

[ZeLonewolf]

From my subjective experience, having been exposed to these shields all my life, I cannot say that I find the Dutch highway shields in Americana particularly recognizable.

These are not recognizable?

[1ec5]

This came up previously in #141 (comment).

In general, this style’s artistic direction pays homage to a particular tradition from print cartography. One element of that is to apply a consistent typeface and color palette to every shield from every country, even if that sometimes requires a slight reinterpretation of the design. So it’s a question of whether we can “get away with” a departure of this magnitude.

There seems to be some precedent for more or less the current treatment, which is not to say that we must uncritically follow this particular example:

France & Benelux Countries (American ed.). 1:500,000. Cartography by Freytag & Berndt. American Automobile Association. 2009. Amsterdam inset.

This is far from the only situation where we’ve taken liberties with route shields. For one thing, we made a decision early on not to hew too closely to reassurance markers for state and provincial routes in North America, because they tended to be too busy for the purpose of marking a route on an already busy map. Rightly or wrongly, this informed many of the initial simplifications we made as we expanded coverage around the world.

Sign	Icon	Description
		Québec Autoroute 5
		MCTRA 249 Tollway
		G1512 Ningbo–Jinhua Expressway

From a technical perspective, we want to gradually reduce the amount of custom string processing that the shield library does, not increase it, to improve the style’s portability in different environments, such as mobile platforms. One possible approach would be to port the custom JavaScript to MapLibre style expressions, but unfortunately the expression language lacks anything in the way of string processing operators. Don’t get me started on what it took just to be able to find and replace semicolons in #666 #670, let alone something that would seemingly require a regular expression. If anyone here is able to push through stuff like maplibre/maplibre-gl-js#2064 maplibre/maplibre-gl-js#2059, it would give us a lot more confidence about that direction.

Instead, we’ve taken a different route, trying to make the shields more data-driven, for example working with OpenMapTiles to expose ref:colour=* tags so that we no longer need to hard-code a lookup table of colors for certain color-coded route networks: #654 (comment). That will hopefully give mappers more agency over the presentation of shields based on their local knowledge. We’ve envisioned ref=* working more or less the same way. It mostly works, but now that you’ve pointed out the typographical issue, I won’t be able to unsee it. 😅

To the extent that our current departures from the physical signs present difficulties in comprehension, hopefully the legend helps a bit as a workaround for now.

And of course, just because OSM Americana prioritizes typographic consistency over pixel-perfect shield rendering, that doesn’t mean that it’s the One True Way™. There are several active forks of Americana that apply their own artistic direction. Try making a fork and maybe we’ll be really jealous of what you come up with and want to copy you. 😉

[1ec5]

This way you can also work with special Unicode space characters of various widths.

One possible approach would be to port the custom JavaScript to MapLibre style expressions, but unfortunately the expression language lacks anything in the way of string processing operators.

Looking into this some more, the existing string expression operators are inconsistently implemented so that they’ll misbehave if we pass a non-ASCII space into them: maplibre/maplibre-style-spec#778 maplibre/maplibre-native#2730.