We have set up an experimental instance of Waymarkedtrails, in cooperation with Sarah. Maybe we could test options together?
Currently, as stated above, I am working on wiki:symbol. But we can explore other topics.
You mean they were using the last segment of the tag value to put the reference text? That would be standard use of that field, wouldn’t it?
They started with putting numbers, but then the numbers weren’t visible enough. In the end they put osmc:symbol=red:white:red_frame:25:black, which broke rendering, and it only showed the ref=*, which is when people were happy. As I said, the rendering of the symbol is pretty much irrelevant in Croatia, because most routes have the same symbol. But if there was ref and the symbol rendered, that would be great.
To me, the short-term workaround for Waymarked Trails should raise concern that there’s an undue temptation to tag for the renderer. Presentational details like this are the proper responsibility of a stylesheet, as long as it has access to an unambiguous network identifier. Recreational routes (other than cycling routes) are in an awkward spot, because the only valid values of network are three-letter acronyms that effectively only indicate the mode of transportation and minimum zoom level, but not the network. Thus we’ve devised an image description language plus an external image mechanism that raises security questions.
We don’t have as much of a problem with road routes (other than outliers like network=motorway in a few countries). When a mapper disliked how OSM Americana marked Vermont’s state highways with an oversimplified shield, they opened a bug report and it was fixed in one spot. There was no need to coordinate changes to the tagging scheme with other renderers like Mapbox and OsmAnd, nor did each individual route relation need to be updated.
While I agree that the current set of values for network is next to useless, I don’t see what it has to do with the problem at hand. The most important visual aspects of a hiking route are ref and symbol, and both have dedicated and unambiguous tags. The problem lies with the renderers (one particular) which is unable to show them both, or at least choose one on a case-by-case basis.
That’s a symptom, not the root cause. This topic started because wiki:symbol is dangerous to implement naïvely. wiki:symbol exists because, despite our best efforts, osmc:symbol will always be incomplete. Hopefully the mitigations I suggested will be helpful, but there are a lot of other problems with the idea of loading arbitrary tagged URLs or image names. This may explain why only one renderer has previously attempted to consume wiki:symbol – the renderer that serves as the reference implementation of osmc:symbol. What other key do you know of that replaces the “Any tag you like” principle with the authority of one person?
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.
My point is that ideally the symbol would be derived from ref and a more meaningful network-like key. Consider the fact that most of the routes in Croatia have the same symbol design: is this a mere coincidence, or is it a consequence of these routes belonging to the same network? If a particular renderer is misinterpreting osmc:symbol, then by all means, the bug should be fixed. But please note that, if we keep putting effort into building out the osmc:symbol language without solving the problem more generally, then recreational route symbols will remain limited to a small club of renderers.
I started Talk:Key:osmc:symbol - OpenStreetMap Wiki (if someone wants, feel free to start discussion at forum here - just ping me, or on tagging mailing list)
In Croatia it could be said that the prevalent blaze is connected to the Croatian Mountaineering Association. Would then your solution be to put a tag like network:operator=Croatian Mountaineering Association, and then renderers would download the symbol connected to that association, from the wiki? That looks like the solution with wiki:symbol=*, or maybe I’m not understanding your solution.
I share your concern about what part of rendering should be specified in tags and what part in rendering code or stylesheets. The text field in osmc:symbol is probably very much debatable in this context. It is common practice in France to use that field to introduce all or part of the reference, but I agree that this raises lots of questions.
However I believe that we should not fall into the trap that equates semantics to text and rendering to graphics, so as to draw a deceptively simple borderline between what should be in tags and what should be in rendering styles. After all, letters are symbols too; and SVG is a text language just like the mini-language in osmc:symbol. In my view, the question is rather “what is observable in the field, and how should we represent it?”. If a sign has a name on it, I put this sign in a tag. If it has a symbol on it, why not describe this symbol in a tag? Sometimes the symbol is too complex to represent with a mini-language, and SVG is the perfect language for that.
1 Like
Would you agree to start a discussion about network in another thread? It’s been bothering us in France for some time too, but I believe this deserves a thread of its own.
Sure, although, it isn’t a problem in Croatia because the tag is only used with the nwr, rwr, lwr and similar values. But maybe we’re missing out on something by not using that tag that much 
I have no immediate solution, but bear with me. If not for the three-letter acronyms already occupying network, you’d just coin something like network=Hrvatski planinarski savez network:wikidata=Q12957482 (following the model of public transport routes) or network=HR:HPS (following the model of highway routes), and editors and general-interest renderers would already be quite close to supporting it. But as it is, to keep the routes from completely disappearing in renderers like Waymarked Trails, you’d have to choose a different key such as network:name or network:guid. These keys aren’t recognized by any renderers yet.
You’ll notice that these tags don’t name a specific image on the wiki. How then would a renderer know how to render a marker for the route? It depends on the data consumer, but I would expect most to maintain a lookup table from network:guid or network:wikidata to icons that are maintained as part of the same renderer project. Some renderers might find it convenient to just draw a circle programmatically.
This would not require writing a complex parser. In more complex cases, this would not require the renderer to maintain a network connection – useful for outdoor navigation! It would not assume that the platform is capable of rendering SVG. It would enable the stylesheet to choose the shade of red that matches the rest of the map and size the circle to fit the text, no matter the font. Best of all, the network name or GUID would be useful to routers when giving directions and useful to maps when displaying a legend. It would be silly to translate wiki image names back to network names. 
On the other hand, this approach would require individual renderers to specifically add support for this network. But I assure you that most renderer developers would rather do that than have to parse a language that’s even less specified than opening hours syntax, or have to load arbitrary images from an external source whenever the tags call for it. Ultimately, more renderers would end up marking Croatian Mountaineering Association routes by something recognizable than with the current approach.
It’s a real pain to write network=lwn when you know that this route belongs to the “Chamonix - Mont-Blanc hiking network”. Reconquering this tag for more meaningful information would be a win. We’d just need to do something for the local/regional/national/international scale, if it is really useful.
However, I’d be careful with the assumption that one network has one symbol. Here in France we have networks that dedicate one symbol, or one color, to each route in a network. We also have exceptions (“all routes are like this, except that one”), etc. Maybe the network symbol could be used as a default value, for when no symbol is attached to a route.
1 Like
This also happens very frequently for other kinds of routes. Metro routes in many cities are color-coded (primarily identified by a color), in which case they’re tagged colour=*. Spain’s autopistas and autovías are primarily known by ref=*, but the shield backgrounds are idiosyncratic and inconsistent, so those routes are also tagged ref:colour=*. (At first, mappers in some other countries howled about this key duplicating network=* because they didn’t understand the Spanish situation.)
Lately, the OSM Americana project has been focusing on tourist route networks. Many of these networks assign a different image or glyph to each route in the network; some images are quite elaborate. To the extent that mappers have even bothered to tag these relations as part of a system, they tend to rely on the hierarchical network=* format or ad hoc ref=* values. For example:
- The binational Great Lakes Circle Tour network uses a coherent set of shields depicting a map of the lake that the route encircles. Each route is tagged
network=GLCTwith a uniqueref=*set to the route’s well-known acronym. - In Australia, Queensland’s touring routes used to be tagged e.g.
ref=muttaburrasaurus, but they recently decided to switch to a scheme similar to the Great Lakes Circle Tour. - New Zealand’s touring routes each have a completely different logo. So each route is tagged
network=NZ:Touring:*, suffixed with a unique identifier. The idea is that unifying the routes under the samenetwork=*, as with the Great Lakes Circle Tour, has little benefit because it wouldn’t be possible to design a simplified fallback shield that applies equally to each route. For fun, the New Zealanders have setref=*to an emoji corresponding to the logo, but that’s kind of kitschy and they really just got lucky that there’s even a resemblance.
The OSM Wiki has SVGs and PNGs of
these tourist route shields for documentation purposes, but we might have to delete some of them to avoid violating Crown Copyright. It’s definitely not OK for renderers to use these images directly via wiki:symbol=*. Renderers can display heavily simplified versions of these shields without issue, but the exact image would differ from style to style.
OSM Americana has run into several edge cases along these lines. We’ve been simply hard-coding the exceptions. I can see the desire to make these exceptions more data-driven, but the ones I know about aren’t nearly compatible with osmc:symbol and some aren’t suitable for wiki:symbol either (for copyright reasons).
It would be nice to have a tag that says: yes, it may be part of the same network conceptually, but there’s some unspecified visual difference that travelers rely on. A renderer could choose to ignore that distinction, or display a generic shield as a fallback, or display the correct one-off shield, depending on user needs.
My interest in this topic is twofold. As a wiki administrator, I’m wary of any tagging scheme that imposes non-wiki-like constraints on how people can edit the wiki, and I oppose any scheme that might force us to push the boundaries of copyright law. Meanwhile, OSM Americana’s contributors are chomping at the bit to start adding recreational route shields.
In North America, hiking and cycling route shields are even more complex than highway route shields. osmc:symbol=* syntax is only suitable for primitive trail blazes, but these days almost every hiking route has a proper shield that maps would show, while no cycling route has blazes. Unfortunately, many of these routes are maintained by agencies and organizations that are allowed to claim copyright over their work, including the official shields.
Same here in France. Fortunately, we have a recent law about government-managed data that balances this, because the actual route design process appears to start with local government projects, then goes on with the delegation of route management to an agency that can claim copyright on geometry or trade marks on symbols. So our game is to catch new routes while they are still government projects…
Speaking about trade marks, I am not convinced that osmc:symbol puts OSM in a much better position than wiki:symbol. Here, red:white:red_lower: breaks a tradmark when it’s rendered on a document aimed at the French market.
Interesting, I’m only familiar with U.S. trademark law, which recognizes fair use of trademarks and focuses heavily on whether an infringing use creates any consumer confusion. A map published in the U.S. would only have to worry about copyright, not trademark, when faithfully adding shields to the map. That said, if we need to replace a copyrighted shield with a symbol that’s simple enough to be ineligible for copyright, we need to make sure users wouldn’t confuse it with another shield.
For example, OSM Americana can mark an Interstate highway using the public domain Interstate shield without infringing on AASHTO’s registered trademark. In fact, marking it with anything else would create consumer confusion. However, AASHTO would probably go after us if we were to use that same shield as OSM Americana’s logo and advertise the project on a roadside billboard. (The project’s logo is actually based on the U.S. Route shield. By coincidence, it looks almost identical to a South Korean national expressway shield, go figure.)
Most of OSM Americana’s supported highway route shields are too simple for copyright protection, while the fancy state route shields are explicitly in the public domain as part of the MUTCD. By contrast, most hiking and cycling route logos are owned by private non-profit organizations and aren’t specified in an MUTCD, so we assume they’re copyrighted. It’ll be a fun challenge to design alternative shields that are simple enough but not too simple.
Obviously I have no expertise to provide professional opinion, and unfortunately it seems that none has been sought so far. But the French hiking federation claims trademark protection against map makers and we’ve been told about a recent case where they asked a web site that uses Waymarkedtrails to stop displaying their “white-red” distinctive sign adjacent to a route on the map.
It maybe unfounded, it may be because of nuances between trademark fair use and our own legal concepts, or it may be because the hiking federation is in the business of selling maps and it makes a difference. I am eager to know, but this would require professional advice.
1 Like
Understood. Even if it’s unfounded, no one wants to go through the headache of receiving a cease and desist letter, or worse, a frivolous lawsuit. From my perspective as a wiki administrator, I feel even more uncertain about it because we don’t have any control over the manner and context in which applications would be hotlinking images from the wiki. Those uses could undermine whatever already flimsy claim the wiki makes regarding fair use.
There is always the option of using the metadata associated to the image file, isn’t it?
If the symbols are trademarked are the routes themselves proprietary?