Spain’s “A-roads” do not necessarily have blue shields

[1ec5]

Currently, this project assumes that every route relation tagged network=ES:A-road is an autopista or autovía that has a blue shield. Neither assumption is correct with respect to OSM. In reality, Spain’s route designation situation is almost as complex and inconsistent as in the U.S. Although the national government often applies a blue shield and “A-” or “AP-” prefix to autopistas and autovías, many have the prefix “R-” (for radial) or “AP-” (for autopista de peaje), making it less clear whether these routes should be considered “A-roads”.

Meanwhile, each of the autonomous communities has its own conflicting scheme for local autovías. For example, in Andalusía (which happens to start with an A), Autovía A-92 has an orange shield, while Autovía A-382 has a green shield. In Castile and León, Autovía A-231 has a blue shield. In the Basque Country, Autovía AP-1 is neither nationally operated nor tolled but still has the “AP” prefix and blue shield.

Due to the large number of idiosyncrasies, the Spanish community has adopted the ref:colour key to indicate the shield color independently of the route network. It would be better to base the shield selection on this data than to maintain an override list ourselves, since the assigned colors apparently change regularly. The vector tiles would need to expose ref:colour, ideally coalescing similarly hexadecimal color references into more predictable color keywords. In the meantime, maybe we should remove the existing blue-only implementation to avoid confusion:

https://github.com/ZeLonewolf/openstreetmap-americana/blob/e5fe35be2653a0cf96acec634e49fe3df829dce1/src/js/shield_defs.js#L3324-L3328

[ZeLonewolf]

The vector tiles would need to expose ref:colour, ideally coalescing similarly hexadecimal color references into more predictable color keywords.

Since it's tagged at the network level, this is feasible. However, remember that network and ref are packed into a single tile attribute per route, so you have something like:

route_1=ES:A-road=AP-1

The ref:color key has 35K usages, so it's not unreasonable to use it. I would need to implement some scheme that packs the value into the string to make this work, perhaps by adding another :<color> on the end of the network portion, for example.

However, this will mean that any other network that happens to use ref:color tag will also get its network value modified as well, so we'd need to be wary of second order effects.

This is exactly the kind of craft-mapped boutique output that I'd encourage in this project...

[1ec5]

Once #1032 lands, we’ll be able to make the route’s color part of the image name format. The style will pass this color to the shield rendering code to use verbatim instead of the hard-coded blue background.

[1ec5]

As of #1032, each feature has a route_#_color property based on the route relation’s ref:colour=* tag. The name gets plumbed through to the application’s shield selection code, which can now parse it out of the image ID that the stylesheet requests.

We’ll need to modify the shield library’s public interface to pass in an optional color:

https://github.com/ZeLonewolf/openstreetmap-americana/blob/cbad54bf616645bd93f218a079268f52450cee39/shieldlib/src/types.ts#L125-L129

At this point, routeDef.color is still set to the raw tagged color, which could be either a CSS keyword or a hexadecimal triplet. We need to match it to the nearest color in our color palette before passing it into the graphics code:

https://github.com/ZeLonewolf/openstreetmap-americana/blob/cbad54bf616645bd93f218a079268f52450cee39/shieldlib/src/shield.js#L335-L342