Discouraging URLs in wiki:symbol?

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 :slight_smile:

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. :wink:

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=GLCT with a unique ref=* 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 same network=*, 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 set ref=* 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?

Unfortunately, license and authorship for a given image isn’t available on the OSM Wiki in structured form. Unlike Wikimedia Commons, the OSM Wiki doesn’t consistently use the {{information}} template, neither that template nor any of the license tags contain any microformats, and the wiki doesn’t have the CommonsMetadata extension installed that would consume these microformats. I suppose we could specifically whitelist some “clean” images by adding them to a special category that data consumers would look out for. But that still wouldn’t help data consumers determine attribution requirements.

It would be easier to migrate this files to Commons

This is another topic. But the answer is: yes, unfortunately there is legal precedent that route geometry is granted legal protection in France. Which creates a relational quagmire between OSM and our hiking federation.

Have you talked to the LWG about this?

As far as I know the talks with the hiking federation are (or were) carried out by the national OSM advocacy organization a few years ago. I’m not sure how much LWG was involved, given that one key member of this national organization was more or less involved in the drafting of the law that ultimately should resolve the issue.

Meanwhile we focus on mapping routes that are published by local governments, and we discourage mapping of litigious routes as much as we can… Hopefully having high quality mapping for everything except “their” routes should make them react.

Maybe we need another thread for this topic as well?

How are these litigious entities establishing their routes? Is there anything on the ground, or do the routes exist only on paper?

In the U.S., we’ve prioritized mapping “public” cycling and hiking routes that have markers or blazes on the ground, whether they’re maintained by a government agency or an enthusiast group. While it can sometimes be difficult to track down a decent source for these routes, we’ve been confident that mapping them based on groundtruth would avoid any copyright issue.

Private groups also publish more ephemeral routes as guide books or maps, but we’re more careful about those. Over the years, we’ve developed a relationship with groups like the Adventure Cycling Association that give us permission to copy from their route logs, but in general we aren’t very aggressive about getting every privately designated route onto the map. After all, local running clubs publish their favorite routes too, but we have to draw the line somewhere.

Does the situation in France follow a similar distinction between public and private routes? Could this distinction also clarify the requirements around route marker symbols, so that mappers don’t inadvertently put renderer developers in a tricky legal spot?

As I started to explain, things are very much intricate. We are talking about a national non-profit receiving public subsidies, who federates local non-profits receiving public subsidies, and whose role has evolved over time from designing and maintaining routes to something that is more akin to managing a brand and a national network. To ensure its monopoly it claims intellectual property over the design of routes that have sometimes been designed by local governments (with or without subcontracting to the local non-profits), sometimes have been co-produced, etc.

The other legal means it uses to protect its monopoly is a couple of trademarked symbols (white and red, yellow and red) that are visible on the ground and instantly recognized by a huge portion of the population. And to make things more tricky, these signs have been adopted long ago in a few other countries (Spain, Belgium, Netherlands)

(now we are deep into off-topic territory; maybe a moderator could move this to another thread?)