Add pictorial route shields

[1ec5]

In many parts of the world, the cartographic convention is to mark routes with graphical shields resembling road signage. This renderer marks routes with plain text badges that are suitable for countries that identify routes with consistent alphabetic prefixes, such as the U.K.’s M/A/B scheme. However, in countries that use graphical shields, this style makes OSM look foreign and much less impressive to potential contributors.

In the U.S., this renderer’s plain text badges often lead to disagreements and edit wars about the proper format of ref tags on ways. Some would prefer the ref tag to reflect real-world written usage (e.g. “I-10” for an Interstate route or “SR 123” for a state route), while others have pushed for a uniform, machine-readable syntax with a unique alphabetic prefix for each route network (“I 10” and “CA 123”). The U.S. is currently a patchwork of these schemes.

Meanwhile, we already have very good penetration of type=route relations, which solve this problem with a separate, machine-readable network tag. But we still squabble over the ref tag on ways because route relations are ignored by mainstream renderers.

495 requested arbitrary route shields based on URLs in the symbol tag, but that suggestion should scare anyone who wants to deploy a renderer based on live OSM data. Instead, we should maintain a large set of shield images in the symbols directory and select from these images using the network tag on route relations.

@asciiphil has built a fully-functional prototype (source) based on this idea. This renderer currently supports a variety of national, state, and some county and township routes in the U.S.; provincial routes in Canada; federal routes in Mexico; and some Australian routes. It also handles concurrencies and banners, which are difficult to express with ref tags on ways. It could easily be extended to handle country-specific shields in Europe (such as the blue hexagons in Germany), provided that route relations are used. The shield renderer is popular among members of the talk-us mailing list, but it needs to be ported over to the new Carto stylesheets.

The shield renderer stores a series of public domain “template” SVG images which each have SVG text placeholders for route numbers. A “sequences” folder contains files that list ranges of valid route numbers for each route network. A preprocessing step assembles SVG images for each valid route number for each network. The Mapnik stylesheets look for these images.

For countries that rely on graphical shields, rendering them accurately is a functional requirement, not an aesthetic one. Please consider implementing functionality similar to what the shield renderer provides (if not necessarily the same pipeline). Thank you!

[matthijsmelissen]

Thank you for this well-documented request.

How do paper maps handle this? I suppose US paper maps show the shields? I can't remember ever having seen shields rendered on map in continental Europe. What about the UK?

[1ec5]

Yes, paper maps in the U.S. always show shields, though they are generally greatly simplified due to constraints on resolution and the number of colors available. For example, most maps omit the word “Interstate” at the top of Interstate shields. The National Park Service’s maps render all shields in black and white.

To save space at low “zoom levels”, whenever multiple routes of the same network are concurrent, route numbers are often squeezed onto one shield (see I-80/I-90 at A-2, US 52/62/68 at E-14, and SR 6/SR 24 at D-3 on the State of Ohio’s official highway map). That would be difficult with the shield renderer’s approach, and I don’t think it’s strictly necessary.

Some maps alter shields to match the color of the way. But I think that treatment would just add unnecessary complexity to OSM.

[matthijsmelissen]

Is this something we want?

[1ec5]

I assume you were soliciting others’ feedback, but since no one has responded, I urge everyone to take a look through literally every map of North America produced in North America, both printed and online. OSM is an outlier. At the very least, national and state routes are always given appropriate shields. Many maps use a generic state route shield throughout the U.S., to simplify things. But we might as well do better, since we’d already have to respect route relations to get to that level of support. If symbolic shields aren’t desired in Europe, that would just be a matter of omitting specialized shields for European route networks.

Resolving this issue would require multiple steps and would certainly be a long-term effort. Here’s one approach:

• [ ] Split refs at semicolons, so route concurrencies actually appear on the map. (They usually don’t currently due to the eight-character limit.)
  • [ ] Use split_part() in the roads-text-ref SQL query to produce multiple columns for a single ref tag.
  • [ ] Modify carto to support GroupSymbolizer.
  • [ ] Refactor roads.mml to use GroupSymbolizers for all shields.
• [ ] With multiple shields, GroupSymbolizer currently only supports the MapQuest style of placing the shields side-by-side. Ideally, the shields would run along the way just like text but remain unrotated like shields. (The existing Shield Renderer computes the way’s local slope using a SQL function, then prerenders a shield group oriented along that slope.)
• [ ] Determine shield text based on refs on relations instead of on ways.
• [ ] How do we order shields in a concurrency? Based on stylesheet cascading rules? Or based on the number of colons in network? Or based on some sort of fuzzy matching on the way’s ref tag?

GroupSymbolizer is only supported in the in-development Mapnik 3.0. In the meantime, it may be possible to rig something based on the label-position-tolerance property that Mapnik 2.3+ supports on ShieldSymbolizers.

The Shield Renderer prerenders a shield for each individual route, based on per-route configuration fields, but it seems like we could avoid such a high-maintenance approach:

• [ ] Reuse a single SVG for each network using the <param> tag. Changes to Mapnik’s renderers may be required.
• [ ] Assemble a basic set of shield templates to start out with, which can expand over time to include more route networks. The most important networks that come to mind include US:I, US:US, US:XY (one for each state or one generic shield for all 50), US:TX:FM, CA:XY (one generic shield + something special for the Trans-Canada Highway), and MX. These templates can be copied from the Shield Renderer repository.
• [ ] Further nest GroupSymbolizers for bannered routes.

[matkoniecz]

From examples it seems that it is not really fitting the style, it is simply quite ugly. Note that I am not accustomed to something like this (not from USA). Also in the example renderer shields dominate everything else.

[1ec5]

The example images above are from the Shield Renderer, which intentionally hews as closely as possible to the actual signage (fonts and all). It’d be trivial to adjust the templates to better fit the map style while still differentiating between the different route networks. For example, Stamen’s Terrain style tones down the colors a bit and swaps in the map’s overall label font. Also, I picked examples with a variety of shields or with concurrencies, to illustrate the current style’s limitations. (The current style is simply incapable of displaying all the information necessary to navigate the U.S.’s major highways.) But in practice, shields are much less distracting in the vast majority of the map.

This issue is not so much about the shield style but rather the infrastructure needed to render graphical shields at all.

[Rovastar]

I think a) if it happens it is likely a long way off, read years. b) it raises the question of if we want it or not and the effects it will have for other parts of the world. every country/area would want specialist rendering. how far do we go with this? us road shields, London underground tube stations, what about different road colours/styles for different parts of the world? Blue motorways just in the UK elsewhere other colours.
the floodgates will open there will be thousands of local styles. It could get very confusing to visitors to these countries with a load for new symbols/styling.

[1ec5]

A. We’re at least a decade behind every major online mapping service. There’s already a functioning prototype. The U.S. community really wants this issue fixed.

B. This is no floodgate. Any other country-specific rendering should be a separate issue and a separate decision. Especially in the U.S., a route shield is not just decoration; it is a part of the road’s identity, as important as the route number itself. And because the current style can only accommodate eight-character refs, many major highways in the U.S. get no badge at all in this renderer. (Many major highways have more than one Interstate or U.S. route number.) British road colors are still usable elsewhere in the world, but the current badges are only barely usable in the U.S.

Route shields are familiar to visitors from the affected countries, much more than the current badges. Which of these is more likely to confuse/mislead an OSM user:

when the road is only ever identified by signs like these (and never as “KS 10”):

[Rovastar]

I am thinking about the floodgates of different styling for different features in different countries/areas. As everyone will want their own style feature for their town.

That changes the complexities of the 'simple' carto css style to something very different for the project. A complete change of direction which will in turn lead to more requests for more things to be rendered. Trying to look at the project as a whole rather than individual use case despite the apparent need here.

How many symbols are for the US?! Dozens? hundreds? Are you proposing having symbols for different states and even counties within states in the US? Have you found them all or will be getting requests every hour for another tiny area that has their own symbol?

I admit I know nothing about this way of displaying/organising these routes in the US. But I am genuinely curious how do you say in words the last example. Go down the yellow 24 pointed star number 10 road? I know that sounds that I am being ridiculously condescending and problematic but I don't understand. Is that a local symbol? Like a "state road" so it could be displayed/ is it referred to as state road 10? If it is not KS10. (edit: that one seems to be state http://en.wikipedia.org/wiki/Numbered_highways_in_the_United_States and it did guess KS10 was Kansas state road 10 despite no knowledge at all where is was and no understand at all of US road networks) Could we not just have state: 10; Interstate 12; etc in the existing rendering box?

There are 2 issues here how to display routes in relations for large road networks and how/if to use all these shields to be more visually appealing.

All that said I am not completely against it I am struggling to understand it clearly.

I am curious to know regulars on this list that are US based (@pnorman are you US based?) thoughts on this.

[matthijsmelissen]

All that said I am not completely against it I am struggling to understand it clearly.

+1.

@pnorman are you US based?

I think @pnorman is in Canada. But it would be also interesting to hear about the Candaian situation.

[matthijsmelissen]

More info:

http://wiki.openstreetmap.org/wiki/Road_signs_in_the_United_States http://en.wikipedia.org/wiki/Highway_shield

[Rovastar]

Well Canada is close enough :) http://en.wikipedia.org/wiki/Numbered_highways_in_Canada I have been reading up and that looks equally confusing/similar situation.

[pnorman]

Well Canada is close enough :)

We only ever have two-three shield styles in use in one region, and often one of those is really a generic sign, not a shield. e.g. .

I'm going to the stationary store, so I'll check their map rack, but my recollection is AAA maps as well as both major local printed street map books use shields for the Trans-Canada, but not provincial highways.

For online maps, I looked at the following locally

Bing, Google: Displays shields for the Trans-Canada and Interstate, uses a more basic uncoloured shield for the US-* system and provinicial system, and generic shields for others.

Here.com: Displays shields for Trans-Canada and Interstate, basic uncoloured for US, generic for provincial and state highways, but different generic ones for each.

Mapquest.com Coloured shields for trans-canada, interstate, provincial highway, uncoloured for US and state highways, uses unique shields specific to certain highways when available.

Mapquest Open Coloured shields for trans-canada, interstate, uncoloured for US and state highways, generic for provincial

[Rovastar]

Yeah looking at online maps most displays these to some level for US/canada.

What are you thoughts on the need for implementing shields in general? High priority/low priority?

And apart from need for it technically/aesthetically there are a few issues we will need to look at. What level of shield granularity we go down to, how often/size (the sample render has them way to big on some zooms IMHO), how the code would look in the carto style - I think it will change a lot, overhead, etc

[1ec5]

Rovastar wrote:

I am thinking about the floodgates of different styling for different features in different countries/areas. As everyone will want their own style feature for their town.

I think of this as a request to have specialized shield backgrounds for different values of the network tag, no matter where the relations are located. So no per-bbox rules would be necessary.

That changes the complexities of the 'simple' carto css style to something very different for the project. A complete change of direction which will in turn lead to more requests for more things to be rendered. Trying to look at the project as a whole rather than individual use case despite the apparent need here.

I think we have the opportunity to keep things somewhat simple in the stylesheets themselves, by tweaking Carto to support GroupSymbolizer and Mapnik to support <param>. We can start out by rendering shields only in territories where they matter, where they’re taken for granted, to avoid requests for other locally-significant features elsewhere.

How many symbols are for the US?! Dozens? hundreds? Are you proposing having symbols for different states and even counties within states in the US? Have you found them all or will be getting requests every hour for another tiny area that has their own symbol?

In truth, there may be thousands of symbols in the U.S. There are at least a hundred specific to the state of Ohio alone, and indeed we can find more if we look hard enough. However, we don’t have to support them all, at least not for the foreseeable future. Rather, we should first focus on parity with other online maps, which generally display the following shields in the U.S.:

• for US:I
• for US:US
• (generic state route shield) for US:\w\w
• (Maybe) (generic county route shield) for US:\w\w:CR and US:OH:\w\w\w
• Black number in a white rectangle for all other US:.*

I admit I know nothing about this way of displaying/organising these routes in the US. But I am genuinely curious how do you say in words the last example. Go down the yellow 24 pointed star number 10 road? I know that sounds that I am being ridiculously condescending and problematic but I don't understand. Is that a local symbol? Like a "state road" so it could be displayed/ is it referred to as state road 10? If it is not KS10. (edit: that one seems to be state http://en.wikipedia.org/wiki/Numbered_highways_in_the_United_States and it did guess KS10 was Kansas state road 10 despite no knowledge at all where is was and no understand at all of US road networks)

It’s a sunflower. :-) Locals call this particular route “K-10”, but IIRC the name doesn’t appear on signage. In other states, such routes may be called “state route …”, “state trunkline …”, or simply “highway …”. It’s a royal mess, which is why we should aim to have the map reflect surveyable ground truth rather than make users guess.

Each state has a different design for state routes, but enough maps use a plain white oval that we could do the same without confusing U.S. users. (Only a few online mapping services, such as MapQuest, currently recognize each state’s design.)

If we’re worried about visitors from Europe getting confused by North American shields, we could list the most common shields in the map key when viewing North America. Heh, if we don’t go forward with this proposal, I might request adding the reverse to the map key instead:

             in Kansas, United States

Could we not just have state: 10; Interstate 12; etc in the existing rendering box?

The U.S. uses graphical route shields for compactness. As it is, the existing rendering box can’t even fit the raw ref value in many cases. There are enough networks in the U.S. – Texas has over a dozen state-level networks – that any smart shield display might as well be a graphical shield.

I am curious to know regulars on this list that are US based (@pnorman are you US based?) thoughts on this.

Also: @rweait @asciiphil @RussNelson @mvexel @ToeBee @iandees

And apart from need for it technically/aesthetically there are a few issues we will need to look at. What level of shield granularity we go down to, how often/size (the sample render has them way to big on some zooms IMHO), how the code would look in the carto style - I think it will change a lot, overhead, etc

If we decide to tweak the shields to match the OSM style, we might as well simplify them so they can be used at very small sizes. And to me the priority is getting the basic networks in; more obscure designs for county, township, and city routes can come much later.

With GroupSymbolizer, I don’t think there will be much overhead to support concurrencies. Then, to support shields, each of the five basic shields listed above can get its own rule in roads.mss that overrides shield properties on the existing ref rules.

In the future, to support a wider variety of shields, we can maintain a directory of SVG templates in a shields/ directory, each file named according to a network value. Hopefully we can find a way to have the override rule can take effect based on the existence of a matching template file. Then, we won’t have to change the stylesheet at all when adding support for an additional network. For now, though, let’s stick to the basics to avoid making things too complicated.

[pnorman]

The printed maps I looked at all had shields for the Trans-Canada and Interstate. The road map used plain shields, but the outdoors map (which had much busier cartography in general) used the unique shields for provincial highways like the crowsnest.

I was initially skeptical, but looking at other maps convinces me for rendering special shields for the Interstate, US highway, Trans-Canada and equivalent, but I'm not convinced about special renderings for sub-national shields (state highways, etc). I'm very skeptical about replicating every state variant for farm routes, etc. See Texas

I think simplified versions rather than verbatim reproductions is the route to go. See interstates, but also the detailed designs look bad at the resolutions we need: (MQ non-open)

For the technical side, it's complicated. @asciiphil's work has been invaluable in working out data issues and as a proof of concept, but I don't support incorporating it into osm-carto. My understanding is that MapQuest has done work to support a symbolizer for a group of shields, and we might need to wait until that lands, probably in Mapnik 3.0.

[pnorman]

B. This is no floodgate. Any other country-specific rendering should be a separate issue and a separate decision.

This isn't about adding US shields to the rendering, this is about adding shields to the rendering and would, at a minimum, cover the US, Canada and Mexico, as that's what @asciiphil does. Wikipedia indicates that Australia has a system of multiple systems, and that Hong Kong, Malaysia and New Zealand have relatively simple systems.

[1ec5]

pnorman wrote:

I was initially skeptical, but looking at other maps convinces me for rendering special shields for the Interstate, US highway, Trans-Canada and equivalent, but I'm not convinced about special renderings for sub-national shields (state highways, etc). I'm very skeptical about replicating every state variant for farm routes, etc. See Texas

That would be a fine first step. (See my list of five basic shields above.) Eventually, though, we should support US:TX, US:TX:Loop/US:TX:Spur, US:TX:FM/US:TX:RM. Each of these networks can have a route with the same number.

For the technical side, it's complicated. @asciiphil's work has been invaluable in working out data issues and as a proof of concept, but I don't support incorporating it into osm-carto. My understanding is that MapQuest has done work to support a symbolizer for a group of shields, and we might need to wait until that lands, probably in Mapnik 3.0.

Agreed, the existing Shield Renderer is tightly coupled to high-maintenance enumerations of route numbers, which would be problematic for this project. Instead, we can use the templates as shield backgrounds behind arbitrary route numbers, like Stamen and MapQuest do on their maps, with a minimum of fuss.

GroupSymbolizer has landed in Mapnik 3.0, which won’t be out for awhile. It’s only required for supporting route concurrencies (multiple shields on a way). We could even render shields without supporting concurrencies until Mapnik 3.0 is released. I’d be fine with splitting concurrencies out into a separate issue.

This isn't about adding US shields to the rendering, this is about adding shields to the rendering and would, at a minimum, cover the US, Canada and Mexico, as that's what @asciiphil does. Wikipedia indicates that Australia has a system of multiple systems, and that Hong Kong, Malaysia and New Zealand have relatively simple systems.

What I meant is that, if we incorporate shields into this renderer, we can still say no to country-specific road colors and public transit logos. The idea is that we already (usually) show route numbers on the map, so we should try to show them the right way.

[pnorman]

can still say no to country-specific road colors and public transit logos.

We're not planning to use colour tags (#421) and region-specific styles are not on the table for now.

[Rovastar]

I am curious to know regulars on this list that are US based (@pnorman are you US based?) thoughts on this.

Also: @rweait @asciiphil @RussNelson @mvexel @ToeBee @iandees

I meant the regular contributors in this group ;-) None of which are in the US. :-)

It’s a sunflower. :-)

I had no idea what that was!

For the technical side, it's complicated. @asciiphil's work has been invaluable in working out data issues and as a proof of concept, but I don't support incorporating it into osm-carto. My understanding is that MapQuest has done work to support a symbolizer for a group of shields, and we might need to wait until that lands, probably in Mapnik 3.0.

In that case I think this can be parked until we are at that stage of Mapnik 3.0 and it is bedded in comfortably with our stuff. And when we do the main 1 or 2 tiers of these shields for all the relevant countries can be rendered and see how it goes.

[1ec5]

It should definitely be possible to add graphical shield rules before Mapnik 3.0 is out. GroupSymbolizer (mapnik/mapnik#2160) would only be needed for concurrencies, which are important but not a prerequisite. The shield rules can be based on Stamen’s Terrain stylesheet (CC-BY).

[skylerbunny]

I made a comment on issue 596, https://github.com/gravitystorm/openstreetmap-carto/issues/596#issuecomment-46761861 , and I realize that in essence, this issue is asking for the same thing for a different reason: consistency applied to the 'ref' field.

Since the current style provides no rendered refs for relations (whether text or shields!), we're getting a bad mishmash of styles for 'refs' all over the place, created on individual ways --which in turn will have to be fixed way-by-way when route relation refs is implemented in any form. The longer it takes for this to happen, the worse it will get. Panning around a bit in northeast Wisconsin, near http://www.openstreetmap.org/#map=13/44.2742/-88.4599 will likely illustrate better than I can describe succinctly - differently ref-ed US, state, and county roads, all done at the individual way/segment level.

If and when relation refs are rendered, beginner users will be more likely to see the 'right' way to create labels/shields/whatever-we-call-it on routes, reducing the work to keep them consistent over time.

*tl;dr - please don't shelve implementing labels "of some sort, even if that's just text" based on route relations (from #596) -- even IF the shield question here in #508 can't be immediately resolved.

[pnorman]

This issue is about graphical shields, not rendering from routes, although rendering from routes is probably a pre-requisite to tackling this.

[1ec5]

Can the renderer even do a good job rendering textual shields based on route relations? Most network values are longer than a character or two. The existing rules have an eight-character limit to keep the capsule-style shields from getting unwieldy. Then again, I suppose you could skip everything up to the last colon in network.

[mvexel]

On Thu, Jun 26, 2014 at 2:02 AM, skylerbunny notifications@github.com wrote:

Since the current style provides no rendered refs for relations (whether text or shields!), we're getting a bad mishmash of styles for 'refs' all over the place, created on individual ways --which in turn will have to be fixed way-by-way when route relation refs is implemented in any form. The longer it takes for this to happen, the worse it will get. Panning around a bit in northeast Wisconsin, near http://www.openstreetmap.org/#map=13/44.2742/-88.4599 will likely illustrate better than I can describe succinctly - differently ref-ed US, state, and county roads, all done at the individual way/segment level.

FWIW, we spent a ton of time augmenting route relations (Interstates and US Highways mainly) in the U.S. with appropriate network and ref tags, so that we wouldn't have to rely on the brittle ref-on-ways tagging convention for determining the road designation. This is by no means finished - many state level networks remain to be done - but we have some tools in place in the U.S. to help guide this work, like the relation pages http://184.73.220.107/relationpages/

Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/

[skylerbunny]

FWIW, we spent a ton of time augmenting route relations (Interstates and US Highways mainly) in the U.S. with appropriate network and ref tags...

Could you append this information to issue #596? As you point out, IF this were implemented in openstreetmap-carto, editors would be much more likely to implement and maintain it as such, since the instant gratification of properly displayed refs would come into play.

EDIT: Also, Martin, can I safely assume that you and the team working with these relations would want route relations implemented first-or-at-the-same-time, making #596 a prerequisite? I'm pretty confident you don't want to edit every way in every relation to add tags to see shields, just to remove them all again for cleanup reasons when the relations ref tagging is implemented. But if I'm wrong, let me know!

[ToeBee]

The main reason I would consider the current situation to be completely broken is that highways often overlap with each other in the US. When this happens, the ref value on the way grows to be larger than 8 characters at which point mapnik renders nothing at all. This leads to the impression by people looking at our map that major highways are not mapped. Case in point: A few notes that were created a few days ago:
https://www.openstreetmap.org/note/185116
https://www.openstreetmap.org/note/185115

It is hard to convey that these highways are mapped without doing some kind of more advanced clustered shield rendering. Specific network images would be super awesome but even a more generic solution would be better than what we have now.

[RussNelson]

I don't understand the people who are suggesting that shields are optional. They aren't optional. They are required. They're how you tell the difference between I-787, NY-787, and CR-787 (not that you'd have a county road numbered that high, but I'm just making the point). Specifically, I-787 switches over to NY-787 in Cohoes, NY, and the map's shielding needs to reflect that. There is a specific sign for Interstate 787 (which is a red topped blue shield with 787 in white numbers), and a different sign for NY-787 which doesn't say NY-787, but instead, like the Interstate shield, just says 787, in black letters on a white background with a black border that has a shape specific to New York State I won't even try to describe in words. If it then got to be a smaller road and changed into a county road, it would be yellow letters on a five-sided blue shield again, just saying "787". Saying "I-787", "NY-787", or "CR-787" just doesn't cut it. Makes the map look like a relic of the 1990's.

Accurate shields for US maps ... not optional.

[RussNelson]

Yes, what ToeBee says about multiple overlapping routes. You will often have two routes sharing the same road, sometimes with an additional county route. You can even have NY-30 South sharing the same road as NY-28 North. https://www.openstreetmap.org/way/254531981 has, going from west to east, NY-28 North, and NY-30 South.

[pnorman]

last colon in network.

network does not consistently have a colon.

[pnorman]

Edited title to better reflect what this issue is about.

[ghost]

This issue does not seem to have gained any traction on openstreetmap-carto. Is anybody willing to port the proof of concept site to carto and run it under load at a local chapter server or something?

[pnorman]

This issue does not seem to have gained any traction on openstreetmap-carto

It's gained a lot of traction, but it depends on #596 being implemented first, ties in with #670, and has very little coding done on it so far. Given how @asciiphil's proof of concept works, I doubt we'll end up reusing any code from it.

[pnorman]

Assigning as 3.x, we need a reload to get in the network information

[kocio-pl]

Do we really want to do this? I'm skeptical, because we don't do such localization for any other feature and the roads code is already big and complex enough.

[pnorman]

We want this, but an effective implementation depends on #596.

[1ec5]

Given how @asciiphil's proof of concept works, I doubt we'll end up reusing any code from it.

@kennykb started osm-shields as a successor to @asciiphil’s prototype that is intended to be more usable in a standard Mapnik-based renderer. I haven’t dug into the details, but hopefully it offers a way forward on this issue.

[kennykb]

@1ec5 - Maybe. I wanted pictorial route markers on my own maps, and it was such a long road figuring out how to make Mapnik's GroupSymbolizer do my bidding that I thought it was best to start a project so that at least the workflow was documented for others. (And so that I wouldn't forget how it worked!) If it turns out to be useful for OSM Carto, that would be a plus, but I'm not actively lobbying for that at present. I haven't the time and energy for that - it's a very high bar to clear.

[nvkelso]

We open sourced 100s of road shield artwork as Mapzen was shutting down for all USA state shields and ~50 countries around the world (federal down to state and sometimes county).

See the blog post (scroll down to the bottom) and artwork repo (Bubble Wrap is farthest along, and the map preview shows a demo using Tangram). The artwork is vector in Adobe Illustrator format and exported in raster. Can easily be converted to other formats.

[pnorman]

We can't use GroupSymbolizer. It isn't supported by CartoCSS. I don't think shield pictures are a serious blocker for this feature, given the other difficult problems faced.

[1ec5]

We can't use GroupSymbolizer. It isn't supported by CartoCSS.

Ah, good point. mapbox/carto#349 was proposed a long time ago to address that, and seeing that reminds me that I had proposed an alternative syntax (1ec5/carto@1c9ff62ceb06e8a8b5abf5762f9d296472541602) but never followed through with a PR. 🙈

[jeisenbe]

@1ec5 were you still considering submitting a new PR to carto so that we can use GroupSymbolizer in CartoCSS?

[JimFlasch]

How close are we to having proper highway shields on OpenStreetMap by now?

[matkoniecz]

In this style? Quite far away. Unless at least "We can't use GroupSymbolizer. It isn't supported by CartoCSS." was fixed or some alternative was found.

Though there was work in https://github.com/ZeLonewolf/openstreetmap-americana using a different technical stack, one of main planned features are US-centric highway shields.

[ZeLonewolf]

How close are we to having proper highway shields on OpenStreetMap by now?

As @matkoniecz notes, we expect to have working highway shields in openstreetmap-americana, which is a vector style, shortly after OpenMapTiles completes its 3.13 release, which will include support for concurrent highway routes. This was completed in openmaptiles/openmaptiles#1152. However, they will not yet be aligned properly until we can get a fix for maplibre/maplibre-gl-js#188. So, this is actively being worked in other technical stacks, but I'm not aware of anyone actively working on highway shields for raster stacks like the one used by openstreetmap-carto.

[attilakundev]

Thank you for this well-documented request.

How do paper maps handle this? I suppose US paper maps show the shields? I can't remember ever having seen shields rendered on map in continental Europe. What about the UK?

https://map.hu/wp-content/uploads/2020/11/2271_hu_450k_2013_puha_balaton.jpg https://mindentudasboltja.hu/Magyarorszag-autoterkep https://www.avenzamaps.com/maps/897982?utm_source=affiliate&utm_medium=affiliate_link&utm_campaign=szarvas.andras%40map.hu&utm_term=2201846899

@matthijsmelissen Sorry, but your statement is totally (or at least partially) wrong, because hungarian road atlases DO display road numbers with shield and even the E-roads. (And Hungary is in Europe)

Well, I had to say this after talking with @ZeLonewolf about route shields and he mentioned this issue. I also used to have a road atlas that was from 2004, but i got rid of it recently because it was literally outdated, and back in the time i needed it (2007-2013ish) because we didn't have smartphones and GPS, so by that i could navigate my dad from A to B

[pnorman]

4431 will unblock #596 which unblocks this.

[ZeLonewolf]

The OpenStreetMap Americana project is a CC0 renderer that is working towards a comprehensive rendering of highway shields. As a CC0 project, this work is license-compatible with this project and osm-carto contributors should feel free to re-use any of this work that may be applicable.

Shield artwork can be found here: https://github.com/ZeLonewolf/openstreetmap-americana/tree/main/icons

Network and shield definitions can be found here: https://github.com/ZeLonewolf/openstreetmap-americana/blob/main/src/js/shield_defs.js