… so we seem to converge on “osmc:symbol is for trail signing”. And, in my view, we need an outlet for shields when there is one (network shield or route shield) even if no renderer actually uses it
Of course, additionally. I just need some time to see “shield” as something different than a metal carrier for the simple symbol plus (sometimes) route ref and (sometimes) route name.
I think it would be very hard to come up with a machine-readable description format of actual (artwork) shields.
1 Like
It took some time for me too. Minh’s explanations about US roads, plus the intermediate role of bike routes, have helped a lot.
Note that Sarah says she does not intend to render route/network shields, and that Minh says that he prefers semantic descriptions to graphical descriptions of the artwork. I suspect that something like “see the woman and child logo visible at http://…” would suit him best. Or maybe a link to a Panoramax picture.
The main difficulty that I see is to come up with something that will be self-evident to beginners, so as to avoid misuse of the tags and loss of the original intention.
Right! In he meantime, maybe we could think about the issues with made-up refs (guilty!) full flavoured descriptions in the name tag (guilty but I’m almost clean), and the missing acorn symbol in the current osmc symbol list…
1 Like
You mean, all the unfortunate cases where route operators use fancy signs to blaze their routes? I also have a squirrel, a butterfly, and so on.
But before talking about this, I’d rather make sure that we are all set about shields. Particularly what information we want to convey and where to put it:
- someone tells me “in Wikidata, not in OSM” But if we do this we will need to document it heavily in the Wiki.
- with the
symboltag? But again, we know what confusions it creates withosmc:symbol. Once again, heavy documenting. - with a new tag in routes, e.g
shieldorlogo? - with a tag in a new type of object, e.g a network relation?
- other?
This is probably because you’re focused on route planning and navigation for real. OSM Americana doesn’t aspire to be a trail map per se. Our design inspiration still mainly comes from highway maps, but a conventional highway map isn’t just about highways; it also features parks, recreational trails, and scenic byways in order to promote a region as a travel destination or foster appreciation for sustainable transportation. If this coverage catches the reader’s fancy, they’re going to use a different map to plan their off-road excursion anyways.
Of course, Americana is actually a showpiece for OSM data – it only resembles a highway map to prove that one can be built on OSM. So hopefully you can see why the inscrutable logos might actually be appropriate for this map, even if they’re less useful in practice.
Trademark law is compatible in the sense that many countries coordinate registrations, and there are many similarities among our countries, but the laws aren’t completely harmonized. These are fair questions to ask, since organizations with good lawyers will often demand more than they’re entitled to. I am not a lawyer, and I know even less about the law in France. But I believe we as a project can steer clear of the thorny issues by sticking to our core competencies.
If the federation is concerned that someone would create a competing GR map based on OSM data, I don’t really think this is our problem. The mapmaker won’t care about osmc:symbol=*. They’d pick out the specific routes to show on the map and style them all identically. If they then go out of their way to plaster a big 
on the cover, that’s their choice and we take no responsibility for their actions.
A more general-purpose trail map must either honor osmc:symbol=* or not honor it; it can’t deal with routes on a case by case basis unless there’s something else to go by. If we suppose that is trademarked and marking it on a trail map would violate the federation’s trademark, then a developer’s only recourse is to urge mappers to omit the (entirely accurate) osmc:symbol=* tag from the relation – or drop support for osmc:symbol=* altogether.
On the other hand, if we take a step back and provide some sort of stable identifier (network, Wikidata, etc.), then the renderer can use that to suppress the symbol when necessary. Moreover, if desired, a renderer could generate the symbol from scratch without using osmc:symbol=*. Again, that would be their choice and we take no responsibility for it.
To someone used to osmc:symbol=* support in existing maps, making data consumers opt into marking each individual route or network must feel like a setback. But if we’re worried about trademarks, then this is actually a measure of safety.
In fairness, there’s a continuum from metal shields to painted trail blazes. When we talk about shields versus blazes, the distinction is pretty clear, but people often use terms like “shield” and “blaze” interchangeably. In fact, the MUTCD even calls an Interstate highway shield a “trailblazer” if it points the way to the highway.
Trail signs can take many forms, from the decorative to the utilitarian. In San José, where I live, the city maintains a network of on-street bikeways as well as a network of off-street shared use paths. They mark the former with the green oval shields but the latter with fancy decorative trailhead signs. Each trail is associated with a color and a symbol (mostly animals). For example, the following sign for the Three Creeks Trail has a green background with a choo-choo train on it. This is verifiable and no one would bat an eye at a symbol=train on the route relation:
Needless to say, I’m not interested in reproducing this artwork in OSM Americana. It isn’t unencumbered by copyright or trademark, but it’s simply unsuitable for a map. Would it be better to mark the trails with colorful emoji instead, like 
? Maybe, but I wonder if cyclists or hikers would even notice these symbols on the signs.
(Aside: The local light rail system used to assign similar symbols to each terminus station. I think these logos were primarily used by the area’s many non-English-speakers. Occasionally, someone would ask me how to get to such-and-such station. After a few minutes of pantomiming with them, I’d point to the orange egret logo on the station sign and they’d be on their way.)
The trails also have official three-letter codes that appear on mile markers. As a local cyclist, I appreciate how Waymarked Trails marks these trails with the codes, because they’re more usable. But if I were making an illustrated map of the San Francisco Bay Area for tourists or children, I might choose the symbols instead because they’re much more attractive. Should I put this subjective judgment directly in OSM, imposing it on data consumers I don’t even know about? Or is this curation the responsibility of the data consumer?
In a data-driven project, curation should ultimately be the data consumer’s job, but they can do that job better if mappers provide more tools to base these decisions on. For example, trailblazed=* could indicate how each segment of a route is marked, so a designer can focus on special-casing the networks their audience cares most about, then fall back to a data-driven approach for all the other routes. Unfortunately, at the moment, trailblazed=symbols covers everything from blazes to these decorative signs. Maybe it needs more nuance.
As far as I know, the U.S. community has never had an expectation that it would be feasible to encode route shields in machine-readable format. After all, we aren’t heraldry specialists; few could even name the shape of a shield for some our most common networks. (“Escutcheon” sounds like a kind of fish.) The only reason a mapper would set osmc:symbol=green:white:green_circle:1:white based on a shield is that mappers see it’s a popular key and the quest for completeness kicks in. At least for bike routes, we know they don’t do it for Waymarked Trails.[1]
The cooked-up ref=* tags are different, and I don’t totally blame Waymarked Trails for them. Many trails in North America have unwieldy names, so people habitually initialize the names in writing. For example, planning documents and blog posts routinely shorten “Guadalupe River Trail” to “GRT”, even though the official code printed on every milepost is “GUA”. Like the X’s and O’s I mentioned earlier, these ad hoc initialisms don’t have anything to do with what’s on the ground, so they’re only useful for wayfinding to the extent that the user sees the full name in a legend or on a sign and makes the connection in their head.
It would be nice to get the ad hoc initialisms out of ref=* so we can tag the true reference codes. If a map needs to initialize trail names because it doesn’t have space to label the full name along the route line, maybe it could generate the initialism automatically in most cases, only requiring mappers to intervene with short_name=* when the initialism is ambiguous. This will be a tough sell as long as so many relations have random bits of junk in their names.
My Panoramax suggestion was in jest, in response to the suggestion that a generative AI model could reconstruct the shield from a description. (The Americana team played with this idea yesterday; it’s a hoot.) In seriousness, I’m still counting on either cycle_network=* plus ref=* or wikidata=* for all of Americana’s graphic-generation needs. Others can deal with osmc:symbol=* or some other *:symbol=* if they want.
Incidentally, back in the day, we did think the shortest path to getting shields on a rendered map would be to set symbol=* to the URL of a sign diagram, typically one in SVG format hosted on Wikimedia Commons, but sometimes just a JPEG on someone’s personal website. Americans’ fervor for this key diminished as we came to the realization that OSM Carto was disinterested in pictorial route shields, let alone a mechanism that would force it to load arbitrary images from the Internet on the fly. It seems obvious in hindsight. Nevertheless, almost 11,000 route relations still have these URLs in symbol=*, including most USBRS relations, as mappers have continued to cargo-cult this practice. I’ve thought about removing them from the relations in the U.S., so newer mappers don’t think they’re actually necessary.
And no one seems to have noticed for over a year that that symbol has the wrong number on it. ↩︎
Mine was not. If the purpose of a non-prescriptive description of a shield is to allow humans to get the gist of it, a picture is worth more than a few words in German (which is what we usually get as values for tag symbol here)
Earlier in this thread you mentioned something that, in my mind, approximated an osmc:symbol:trademarked tag that consumers can use to detect radioactive blazing. This would help clarify things a lot with mappers here.
Here, fortunately, the purpose is different. As you pointed out, many of us actually use flavors of OSM topographical maps plus Waymarkedtrails as hiking maps. When Peter (or most contributors here, including myself) use osmc:symbol it is mostly in the hope that the trail blazing will be accurate on the map. And sometimes to try and capture shields, but we agreed earlier that this is not the way to go.
OK. If we go back to your proposals for Chemin d’Amadour and add the result of later discussions, would the following be a good starting point?
type=routeroute=hikingref=81network=FR:GRnetwork:area=national(ornetwork:type=national)network:wikidata=Q1486662osmc:symbol=:white:lower_red:osmc:symbol:trademarked=yesshield=see https://...
The acorn symbol is all over England, used by different operators, and I would not describe it as “fancy”! Different stylings are used. Just 2 examples:
The acorn symbol is used on waymarks on all the National Trails . The trails provide continuous routes through about 2,500 miles (4,000km) of countryside an offer opportunities for both long and short distance walks and rides.
I think that should deserve to be a symbol, just like the “Gelbe Raute” in Germany.
As it happens, the symbol is available on wikimedia commons:
Does an acorn on a trail marker always look like this, or can it be rotated? Can it come with a twig? Does it matter if cross is a Latin, Celtic, or Russian cross? These “style” variations would all be valid even as they affect recognition. Even the relatively straightforward vocabulary for cattle brands allows for more variation.
I think some of my skepticism toward OSMC symbol tagging comes from having seen how emoji developed over the years. The Unicode Consortium has always been adamant that emoji are abstract symbols, not pretty icons that you can expect to look a certain way. Nevertheless, people are continually surprised when emoji render differently from screen to screen. That isn’t supposed to matter, but a central design committee can’t easily predict how people come to interpret and use the symbols.
Haha, radioactive blazing, hopefully that’s more universal! 
Sure, if this tagging equivalent of an asterisk allows mappers to scratch an itch without scaring away risk-averse software developers, then that sounds like an improvement over the current situation.
That said, I don’t know how rigorous this key can be. In some jurisdictions, a trademark can exist without any formal registration. All it takes is for the owner of a name or logo to assert the trademark, assuming they actively use it themselves. (This is how OpenStreetMap U.S. came to be the owner of the OpenStreetMap and State of the Map trademarks in the U.S., years before it was even a local chapter of the OSMF.)
By humans, you mean fellow mappers, right? History has shown that data consumers are less eager to do anything with symbol=* when it contains a URL, let alone a mix of text and URLs, so this wouldn’t be for end users.
If this shield=* is only for the edification of fellow mappers, then it might as well be symbol=* or even note=*, which is often the case these days. There would only be a compelling need for a new key if we foresee data consumers acting on it automatically. Otherwise, this is a fine sketch of a relation.
Based on where this discussion is headed, I foresee the name suggestion index someday adding an entry for network=FR:GR that adds osmc:symbol:trademarked=yes at the same time. That way, a mapper won’t accidentally omit this tag when splitting the pathway, leaving a tiny untagged stub that causes the symbol to pop up unexpectedly. (NSI isn’t quite there yet; it still hasn’t added road networks.)
More map developers than mappers. I was referring to what I understood of your own use for it: producing your own version of the shield in your rendering. I am not conceiving at all that the symbol tag or its successors would ever be exposed directly to end users.
My point was precisely that symbol is a confusing tag name for mappers, who interpret it as a free text version of osmc:symbol, thus defeating the distinction between shields and blazing. If there is no explicit conduit to describe shields, there will always be confusion and cargo cult.
I just put my finger on another confusion: in this thread there seems to be a consensus that osmc:symbol should describe the actual blazing on the ground. That’s good… except that, as you stressed @Minh_Nguyen, it is a tag defined for a specific rendering application. This does not help those who are trying to find consistency in the situation by themselves (nonwithstanding the fact that many of us actually abuse the expressive power of this tag to control the rendering in Waymarkedtrails)
(ob. pedantry) it’s one “operator”, and it’s in England and Wales - not that that in any way invalidates what you are saying!
Most of the alleged national trails “without an operator” in England and Wales are just the newest one (the England Coast Path) missing an operator tag, because the original mapper (in some cases, me) forgot to add it.
Scottish and Northern Irish mappers have mapped a bunch of national trails there, but I’m not familiar with the system in either of those places
If you look at route markers and guideposts with image tags added by me on route relations for English National Trails you’ll see a bunch of examples of the signage. Sometimes the acorn is a bit hidden, and other signage common to the route is more obvious (bigger picture):
sometimes the acorn more obvious (bigger picture):
Ah, so you mean it’s a way for mappers to communicate with the developers during the design process, as opposed to something more automated. I suppose that’s reasonable, though I think the wiki already suffices for that purpose. Back in the day, “Custom Highway Shields” was rather prescriptive, imagining that a data consumer might parse the wiki for SVG file names and substitute placeholders in these files based on the provided regular expressions. An older OSMUS shield renderer kind of did that, but otherwise, the primary use of this page and others like “Unusual Highway Networks” has been as a point of reference.
In all the discussions the U.S. community has had in the OSM Americana repository and OSMUS Slack’s #highway-shields channel, I don’t recall anyone ever consulting symbol=* tags, even though we knew it tends to contain URLs to shield diagrams. Part of that is because many Wikimedia Commons shield diagrams are actually works of fiction or badly outdated, especially in rural U.S. counties or Global South countries.
The Americana project does its own investigation to determine what the signs look like in reality. Sometimes we consult media reports and even Google Street View in case it offers a glimpse of the sign. Other times, local residents send us photos directly. This could go in a tag, but it would be less discoverable and probably raise concerns (rightly or wrongly) about linking to proprietary media. Because Americana is a public domain project, others riff off of Americana, as Stamen Design did for AWS, and the process continues.
It might suffice after some heavy editing to address all current misunderstandings. But currently, my own experience in QA on EuroVelo and routes in France tells me that it is not clear enough.
1 Like
It’s a simple symbol, always the same basic shape, just sometimes black, sometimes white, sometimes closed, sometimes open so it gets the colour of the surface it’s made on (or of). That is what makes it suitable as a basic symbol. It doesn’t serve to show how great the operator is, it marks the route with a basic symbol anyone can follow (ok, I admit I missed it a few times…).
Symbols such as arrow and cross are used so often that a few variations should be available. The "house-like) fat arrow is used a lot, because e.g. a number fits in it, and that is very different from the triangular pointer or the thin simple arrow.
1 Like
It’s been used a long time now without thinking about the original rendering application, it’s simply a machine readable format for describing not too complicated route blazes.
Really? No one cares what OSMC Reit- und Wanderkarte does with the tag anymore? Then we would have to make that renderer even less prominent in the osmc:symbol=* documentation than it is now. It’s a far cry from the situation up to last year, when the documentation named its developer as the sole person with the authority to change the syntax.
Do you think that the mappers using this tag all have this one application in mind? I don’t. They just use its syntax to describe the symbol.
Extending the symbol list does not change the syntax.
That said, I wouldn’t object to a similar machine readable tag with an originator independent name and an improved syntax. I just don’t think it is worth the trouble, because no information is gained by that move.
If it were done, I would think we would need commitment in advance from mapper communities and renderers using the tag, such as OsmAnd and Waymarkedtrails.