I believe that they think about the effect that they want to produce mainly in Waymarkedtrails, then in Freemap Outdoors and Mapy Outdoors, mixing shields and blazing as best as they can.
I was referring to the symbol list. Here’s what the documentation said for a long time:
Valid elements for a osmc:symbol are found in this list of symbols. Note that the set currently targets hiking paths used primarily in Germany. In other countries, other symbols may be defined and documented elsewhere (possibly in a page on this wiki)
Please note that, in order to be truly useful to renderers, the number of different values for the subparts should be kept small. Always try to approximate the symbol of your hiking route using existing values first. If you need a frequently used symbol added, contact Nop with suggestions. Don’t invent a new tag, simply use text/textcolor or refrain from using osmc:symbol altogether.
Finally, don’t just add a osmc:symbol to a hiking route because it looks good on the map. osmc:symbol should always reflect the route symbol that is used as waymarker or on guideposts to give the direction.
I’m not against further decoupling this key from its developer – as I’ve made clear, I have relatively little stake in how we record blazes and similar markers. However, as things stand, there’s a disconnect between how you say the key is used and how it’s documented. I think that would be worth resolving somehow, that’s all.
Any line of action from here?
- improve the wiki?
- introduce new tag names, with a long period of overlap?
Probably the best action would be to add a paragraph to the wiki pointing out that current usage of the tag in OSM does not appear to be exclusively aimed at German Reit- und Wanderkarte any more.
1 Like
I’ve gone ahead and added a line to the opening paragraph of the wiki (italics are just for highlighting the text here)
This renderer specific tag was invented to automatically render symbols for hiking and riding routes on the OSMC Reit- und Wanderkarte and is understood by the OSMC map generator for Garmin maps. It is also used at CMarqu’s hike’n’bike map. The idea is to compose the symbol from different input graphics and text components. This tag is intended to be read by rendering software and, thus, completes rather than invalidates the symbol=* tag which should contain a human-readable description of the symbol.
Mapping of this key has seen steady growth, and appears to have outgrown the original renderer specific purpose. Instead, it is used generically for machine readable description of any trail blazing symbol for any renderer.
1 Like
What would you think of adding a sentence or two saying that “This tag is intended to reflect the actual blazing on the ground, not a symbol that is used otherwise to communicate about the route or a synthetic shield to represent both the blazing and the route’s reference or name”?
1 Like
The wiki starts with:
osmc:symbol=* is machine readable equivalent of symbol=*, both describe route symbol that is used as waymarker or on guideposts
I think that is clear enough?
BTW many route markers include the ref. A short code or a number. The routes I operate have stickers and small shields with the symbol; I use them about 66.6% without and about 33.3% with characters on them. If there is a ref number or code I usually include that in osmc:symbol. The name also appears on many stickers, especially where routes cross each other, I put that identifier only in the name tag.
BTW2 I once suggested in the Dutch community to replace the made-up reference codes (e.g. Pi for Pieterpad, FV for the Floris 5th trail) with their official route number issued by the national operator. This idea did not fall into good earth, as we say. So we are stuck with the mnemonics, for now.
My understanding is that this is the exact opposite of what Minh says about the difference between shields and blazing: osmc:symbol to reflect blazing, symbol to reflect shields.
Documented is:
symbol=* is a human readable equivalent of osmc:symbol=*, both describe route symbols that are used as waymarkers or on guideposts.
I think for a shield description as opposed to blaze description another tag should be used. I think that is a better option than trying to uncouple this twin.
This would indeed solve the ambiguity that I was stressing earlier. So, we could write something like osmc:symbol and symbol are dedicated to blazing; see tag XXX for additional shields and route logos?
Well, how things are is different than how we wanted things to be, is different than how we want things to be going forward. As far as I know, the symbol=* documentation was never particularly prescriptive about what counts as a symbol. That’s why U.S. mappers so frequently reached for this key when they wanted to associate a route with a shield. The osmc:symbol=* documentation may always have been stricter, but that didn’t prevent people from bending the rules and using it for shields too. The more recently approved trailblazed=symbols tag could have the same problem.
Most likely, this documentation was written by mappers from different parts of the world who are only familiar with the trailblazing practices in their respective countries, unaware of such significant global differences. So I’m glad we’re having this discussion. 
It all reminds me of the other kind of shield. If we establish a convention of tagging boundaries with their coats of arms, sooner or later we contrarian Americans will put our seals in there instead. I bet Central European mappers didn’t expect that we use these terms interchangeably:
If we want mappers to stop diluting symbol=* and osmc:symbol=* with shields, then there needs to be an alternative. At the same time, designing the perfect machine-readable shield language would be a distraction for OSM, and a less machine-readable shield key probably wouldn’t strike mappers’ fancy as the OSMC symbol renderers have for blazed trails.
To me, network tags are a suitable, if imperfect, mechanism for communicating the need for a particular shield design. Shield designs are reasonably frequently associated with entire networks in reality, so the ones that are specific to a particular route can be treated as exceptions. The display of shields to end users won’t be as automated and data-driven as for blazes via osmc:symbol=*. But as long as some renderer can display shields based on OSM data, I think the U.S. community will definitely be able to convince mappers here to leave shields out of symbol=* and osmc:symbol=*, just as Americana has been able to help the community rationalize highway classification and route tagging.
You mean that the shield would be obtained outside of OSM, deduced from the network? So, taking the only network in my country that has something akin to a shield, we would change osmc:symbol in most Camino de Santiago routes in France to yellow-blue stripes and remove all references to shells? We can try this. I expect an upward battle to keep shells from insinuating into tags until Waymarkedtrails has an additional mechanism for such network-based shields, but why not?
However, coming back to my example of Chemin d’Amadour, it is one of the very few in the network to have its own logo/shield, so either we decide to ignore its shield or we need a tag to describe it.
I guess I shouldn’t be surprised that scores of mappers have set logo=* to a URL. Hopefully no one has done so hoping a data consumer would do anything with it automatically.
Personally, I would rather add wikidata=* and tag the Wikidata item with logo image (P154) or small logo or icon (P8972), as opposed to icon (P2910), which like symbol=* is more abstract and less prescriptive. At least editors could conceivably use these images, as iD does for brands and operators. (There’s a non-free artwork image URL (P6500) qualifier for copyrighted images that can’t go on Wikimedia Commons.)
One thing I learned from this discussion is that there are more than two kinds of trailblazing symbols. I thought it was essentially just route markers versus primitive blazes painted by hand, where the route markers are graphically complex and drawn to exact specifications, logos even, whether or not they appear on highway-grade sheet metal.
I hadn’t considered a middle category, like the scallop shells of the Camino de Santiago – more visually sophisticated than the blazes here, but with loosely defined symbols that don’t have to take a specific appearance. Up to now, we’ve been calling them all “symbols”, but I could see us distinguishing between the modern 
as a logo or shield, versus a more abstract requirement for any kind of shell as a symbol=*.
I would count shell and acorn as symbols. An artistically interwoven skyline or landscape-ish drawing on a shield, I wouldn’t. Of course it’s a continuum, a mapper would have to draw a line (pun not intended). I am pretty sure that people will agree in most cases, especially if the routes use shields now and again, and in between only the blaze symbol.
Bike routes are less likely to have intermediate blazes, because they go faster and use more infrastructure, so shields on guideposts are much more common for cycling, and authorities are much more likely to want all kinds of text, logo’s and intricate artwork on them. I would say, just a bicycle is the symbol, often also used as intermediate waymark for direction changes.
Since you don’t really need to specify a bicycle as symbol for a bicycle route, I can understand that bicycle route mappers are likely to put the shield information in the symbol tag, and find osmc:symbol too limited for shields. I suppose we can live with “it’s different for bikes”; let’s just not try to apply that to hiking routes.
About trailblazed: that key is meant for paths which are only detectable by the trailbazes: cairns on plains, poles in snowy terrain, and sometimes by route waymarks. The route doesn’t matter in that case; just the fact that a blaze shows where the path is.
Sure, some hiking routes in North America also have symbols that aren’t too complex. The Appalachian Trail is the most famous hiking trail in the U.S. Its most basic symbol is a white blaze.
However, it also has a very recognizable “AT” monogram, which can occur in various forms by itself or as part of an official shield. Any variation in this very simple letterform is negligible and unimportant.
osmc:symbol=white::white_stripe is not very helpful I think…
2 Likes
As usual, ancient Cyrillic comes to rescue: 
Ѧ
[Yus - Wikipedia]
[“Ѧ” U+0466 Cyrillic Capital Letter Little Yus Unicode Character]
5 Likes
It accurately describes the white blaze symbol.
1 Like
Depends on how you interpret the osmc:symbol definition. It was never really defined what an empty background exactly is supposed to mean. Background is not optional. I’d argue that the way US trails use it, it reassigns the <foreground> placeholder the meaning of background. That seems a little bit odd and a workaround for the fact that no *_stripe background is defined. It gets even odder, when as a result foreground2 is needed to describe additional colors.
I’d rather go for a simple white:white_stripe.
Or, since it is most painted on dark trees or wood:
white:brown:white_stripe
or
white:gray:white_stripe