Who is the owner/issuer/operator of the national GR network? Who owns the copyright/trademark?
I deliberately chose this example because it has a ‘shield’ and because it has been awarded the GR label some time after its design. With the available information I would say:
- that 4 local governments jointly:
- hold the copyright on the design of the route
- hold the copyright on the mother-child logo
- operate the route
- that FFRP:
- owns the GR trademark (the two letters and the white-red logo)
- operates the network (maintaining the list of routes, the quality criteria, managing the brand)
Thank you Minh! Just to make sure: you deliberately leave aside the white-red sign, considering that it is derived from network (or from hiking_network, depending in the chosen solution)?
It wouldn’t be wrong, but it would be less important in my opinion, because the same information can be derived from the network. Since some data consumers currently do use osmc:symbol=* for lack of something better, I’m inclined to view it as a backwards compatibility shim.
If there is a plausible legal risk to OSM or data consumers in reproducing this symbol, then not explicitly tagging the osmc:symbol=* would keep those legacy renderers from rendering the symbol by accident. More modern renderers can choose whether to display the symbol on their own, based on the network.
Without a doubt, a U.S.-based renderer would have no problem displaying that bicolor logo under copyright law. For added protection regarding trademark, it might label the network as Grande Randonnée® in the legend, with some additional fine print that this name and logo are registered trademarks of the FFRP. A project based in France might take different precautions. Regardless, the network tag doesn’t need to contain a ® symbol, because that’s just an internal implementation detail that isn’t meant for consumers.
None of this is particularly novel. Over here in the U.S., the famous Interstate shield is a registered trademark of AASHTO, the NGO that designates Interstate highway routes. Yet you’ll be hard-pressed to find a map of the U.S. that does not feature this shield – other than OSM Carto, of course. No map has even bothered to acknowledge AASHTO’s trademark for decades now. The map merely needs to avoid causing public confusion by misrepresenting other route networks with this shield, as TracesMap did when it debuted last year.
Among the reasons that incite mappers to use more concrete forms such as osmc:symbol, there is the less than perfect mapping between semantic information and concrete information. For instance there is at least one member of the GR network that has a yellow-red sign instead of the usual white-red sign (the yellow-red sign is supposed to belong to another network named GRP)
As a hiker, I’m not so much interested in the “fine-grained” network, I just want to know which colour and symbol to follow on the road and in the field for the route I have chosen. The level I use to match the route to available time, or to decide between hiking the whole thing or part of it, practical reasons. E.g. if I have a week, want to do a complete roundtrip in hilly terrain, and prefer to stay in one hotel all week, I can choose regional level in a region with good public transport such as NL Limburg (Krijtlandpad); from the map I see that I should follow the yellow-over-red signs. Further details are nice to know.
osmc:symbol provides exactly that. Network info, operator info, is an extra, I’ll find that out in popups or detail panels or as I go. Th map doesn’t need to reproduce exactly copyrighted logo, trademark or symbol. It just needs to give enough of a hint so I can recognize it and tell it apart from it’s brothers and sisters.
yes but what Minh says is that this is a case of tagging to control the rendering.
And maybe this underlines another difference between Minh and us, beyond being american or european: he manages a rendering, while we are mostly hikers who contribute to the map. We are directly interested in the final result and want to control it, he is interested in allowing the renderer to make its own choice.
1 Like
No, no! I don’t want to control the rendering. I want to record information about what’s on the ground, to enable the renderer to do something with it that represents on the map what is there. As a user, I would like the representation to be clear enough so I can use the map and later, on my trip, recognise on the ground what the map represents, and I trust that the renderer will choose nice colours, line styles and such.
If the signs guiding me on the trip are a certain colour, I describe the colour, but I don’t need to be very exact. I also don’t describe the exact length, width and sticker size or shield size. It’s about recognition, not reproduction.
If the shape is a shell, I tag shell, but I do not need to tag exactly what type of shell, and the renderers can have their way with it, as they see fit.
A decent network tag has a lot of good uses for rendering but I suspect that shield building is a niche application that only applies to a handful of countries. Most routes with complex shields have their own unique design. Rumor has it that tourist boards explicitly go for the complex designs so they would be able to trademark them. Statements like that are one reason why I’ve only allowed complex shields on waymarkedtrails when requested by the route owner. But there are others.
Complex shields are imo distracting cartography-wise. They bring in too much detail compared to the amount of information they add. This is made worse when you want to create a map that shows all routes and not just those of one operator. The different operators don’t really care that their shield designs go together very well, so the end product will seldom be pretty. As a map producer you need to have control over the kind of symbols you render.
The osmc:symbol tag has exactly that problem. You can make a decent and consistent map with the base symbols. Once you add the labels with their color-styling and allow full unicode, you pretty much loose control and the result is rather colorful. So I’ve always been reluctant to accept new colors and symbols. And I never enabled osmc:symbol processing for the cycle map. I find the purely label based symbols more readable. The fact that it is not uncommon to make up values to influence the rendering, doesn’t help.
So I’d say, use the osmc:symbol tag for the trail blazing description. It’s the kind of thing it was made for. Leave the complex shields out of OSM. For the specific case of US-style maps, where complex symbols seem to be expected, it seems that improving the network tag combined with an external shield repository will do the trick. The proposed network tag is in general a good measure to give a renderer more fine-grained control over what is displayed. Just don’t expect it to be a replacement for current symbol tagging. More of an addition.
3 Likes
For sure; this happens plenty with highway routes too. There are a variety of solutions, none quite as complex as osmc:symbol=*. Arkansas state routes are generally a white shape of Arkansas, but then for some reason Highway 980 has a blue shield with an airplane on it, and two others are brown with a boat on them, apparently because they were funded through taxes on boat fuel. The ref=* tag already gives data consumers enough information to special-case these routes.
Each of the routes in Canada’s Yukon has a different color, just like in a subway system; this information goes in colour=*, just like on a route=subway relation. Each of the touring routes of New Zealand has a different pictogram with a common motif. The local community at first tried to tag ref=* with emoji representing these pictograms, but they’ve since updated the routes to have unique network=* values. Spanish autovía signs are so varied and unpredictable that the background colors are specified in ref:colour=* as a property of the route itself.
OSM Americana currently maintains its own mapping from ref=* or name=* to route-specific colors or symbols, though there’s a to-do item about making use of colour=*, ref:colour=*, or wikidata=* (the last one pending OpenMapTiles support), to be less vulnerable to descriptive naming. Even though the routes in these networks don’t consist of a common design defaced with a number, they still share a common identity. A common network=* tag results in a consistent minimum zoom level and a shared entry in the map legend – with a name that has nothing to do with the symbol.
That makes sense. For some of these organizations, the trail is their top responsibility and the trail’s identity is their only brand asset. Some organizations have an informal attitude reflected in quirkier logos.
Earlier, I described the U.S. highway authorities’ gradual takeover of bike route designations. As they took responsibility for more routes, they also began to deemphasize brands of individual routes (and their maintainers) in favor of a shared, functional identity, reducing each route to a number. Similarly, scenic byways used to have one-of-a-kind logos telling the route’s story, but over time these logos have given way to more uniform signs as part of regional marketing campaigns.
Toll roads are another category where every individual route traditionally has its own logo. How about symbol=
! In states that have many toll roads, like Florida and Texas, confusion over these logos eventually led the state to impose a regularized system.
This trend toward uniformity makes the remaining one-off logos all the more interesting to capture on a map with a nostalgic bent. I guess that makes it a particularly “Americanan” niche.
Generic shields or plain badges are totally reasonable too. Every map has its design goals. Unfortunately, most of the ref=* tags on North American trail route relations are initialisms cooked up principally for Waymarked Trails, some at odds with what’s signposted in the wild. I’m hopeful that the U.S. community will come together to build an alternative that renders something more graphical, to discourage hacks like that.
OSM needs to enable the full spectrum of approaches without unduly focusing on a particular use case. The variation we’re talking about is more than one kind of shell versus another. Data consumers need to be confident that mappers aren’t shoehorning information into a key that wasn’t designed for that kind of information. If osmc:symbol=* satisfies your needs as both a mapper and a user, good for you! Just don’t withhold from the data consumer what else you know about the route, just because you personally don’t envision using that information.
Indeed, guilty as charged. That is a problem world-wide. The root issue here is that on the one hand we don’t want to map for the renderer. On the other side, if you want to offer a global map with reasonably up-to-date OSM data, automatic processing and shield generation is indispensable.
So maybe it is time to accept the reality and officially define to two tags:
symbol:osm- machine-readable description of the official OSM icon for this featureref:osm- official OSM abbreviation of the feature for use in labels and similar. Must consist of a maximum of 5 numbers or letters. No special unicode characters.
The latter could be used as-is by renderers. For the former we could maintain a symbol:osm to SVG/PNG converter. It might then also include original shield designs where the trademark owner has given permission to use the shield on OSM maps or research has shown the shield is trademark-free.
1 Like
Are we on the way to supporting two kinds of renderers, generic ones such as Waymarkedtrails that perform only tag-based rendering, and more custom ones such as OSM Americana that make their own design decisions when mapping each network?
Can we try and build a consensus based on these two positions? In my mind, this would need some clarification between what tags are for trail blazing and what tags are for shields.
We are talking a lot about renderers here, and that is good. But we should also talk about contributors and how they understand how tags are used. Currently, symbol is extremely ambiguous and probably misused. In France we tend do remove it. But maybe we should to something else?
I believe that we can use France as a laboratory, because the contributing community is now reasonably connected here and we can agree on how to apply what is discussed with a few authors of renderers.
I keep wondering if we’re actually grappling with incompatible trademark regimes. There’s no need to avoid trademarked symbols in the U.S. The rule of thumb is that, as long as the use of the trademark is accurate (and especially if it’s acknowledged), then there’s no trademark violation. Misappropriating the trademark for something else would violate the trademark.
If someone were to take OSM’s coverage of the Buckeye Trail and sell a map of that trail to compete with the association, the association might have a problem with that. But the logo wouldn’t even matter at that point: the use of the name would be a trademark violation, even if the map were to substitute some other symbol. Fortunately, an accurate map of all the trails that shows tiny replicas of the logos in passing is much less likely to run afoul of any individual organization’s trademark.
This is an important point not only for trail symbols but also for things like bus company logos on a public transit map and brand logos powered by the name suggestion index in search engine results. It remains important to avoid violating copyrights, as with the Ohio River Scenic Byway logo that I simplified for a small size. But fashioning a clean room for reverse-engineering trademarks may turn out to be counterproductive.
If this conflicts with the legal situation elsewhere, then U.S.-based projects may desire a totally different source of graphics, yet everyone still needs something in the OSM relation that they can key off of. A description of a symbol in OSM would serve one side but not the other, and perhaps a network tag is not as useful in a context in which route-specific symbols are the norm rather than the exception. Still, a positive identifier for the route or route network could serve everyone. Your description of ref:osm=* sounds almost like such an identifier, apart from uniqueness.
It’s almost as if we should just tag routes with Wikidata identifiers and that external repository can map the QIDs to premade or generated graphics, whatever the case may be…
Sure, I very much agree that osmc:symbol=* should be limited to more primitive trail blazing. The use of this key for route markers (shields) was always a hack. It seems more suitable for blazes, which are generally even simpler in North America than the painted symbols in Europe. Many trails in the U.S. would technically need nothing more than a colour=* tag.
To further clarify the distinction between route markers and blazes, here’s a tree trunk in Canada that has both, referring to the same trail:
The trail is part of a network; the side trail has a marker and blaze of the same design but a different color:
(Fun fact: Some bus systems in the U.S. also mark bus stops with blazes on utility poles, since paint is relatively cheap to install.)
I am pretty confident that trademark regimes are compatible, if only because of international treaties. My perception is more of incompatible interpretations of what the law says, because we are not educated enough and because some actors may even be taking advantage of our insufficient education.
If you build and trademark mechanical parts, it is easy to know what the trademark applies to. If I sell oil for those mechanical parts, I should be OK saying that my oil works for your parts and to use your trademark as a reference. Still, things apparently are more complex if I create a web site to sell mechanical parts, or a catalog, or even a lottery where the prize is one of your mechanical parts… How a map fares with this regard is unclear to me: is it like a catalog?
Then, there is the question of what the trademark owner says that the trademark is for. Here, as stressed by Peter, it is not only the routes. It is everything that has to do with the routes: maps, guides, tee-shirts, rucksacks, etc. Is it legitimate? How would drawing a route trademark on our maps constitute a misrepresentation of another map? Not sure.
How can we make this crystal clear to contributors, even when they are beginners? Experience shows that it is preferable to have a tag that they can use to describe what they see, even when this tag value is not consumed; otherwise they will use other tags at cross purposes. Should we have a shield tag?
I would say that the issue is even deeper than this. Waymarkedtrails shields are great but they blur not only the borderline between shields and blazing, but also the borderline between describing ground reality and controlling what is rendered. You see that the name of the route is reflected on the shield by its initials, so you edit ref to change the shield, then you start tweaking osmc:ref and the deed is done: you have learned to tag for a renderer.
Here, all GRs have a shield in Waymarkedtrails with the (trademarked) white-red stripes and with the route’s number in black and it looks sooo good! But it violates sooo many principles…
I have to confess I didn’t make much difference between “shields” and “trail blazes” and “Symbols”, where others seem to see those as different.
odmc:symbol describes a relatively simple route symbol that can be painted or carved on trees and objects, nowadays in my region of the world mostly replaced by stickers and yes, shields. Smaller or larger plastic and metal plates. Especially for cycling, shields are used as a carrier for the symbol. Also, the route symbols are often used on signposts.
The habit of including all kinds of artwork is used more and more, especially on on plates, together with or intertwined with the symbol. I tend to ignore the artwork. Stylized symbols, I tend to simplify. Of the symbol is a dark brown acorn, I don’t care much what hue of dark brown it is, and how creative the acorn has been stylized. I may like it or not, on the mechandise, but I don’t really care where the map and hiking/cycling is concerned.
If not too many completely separate routes use the same symbol, no problem. If these routes cross each other, or have common sections, another identifier attribute is needed, typically the ref or the name. But these, same as the symbols, need to be short and concise for a general map. Recreation organizations usually like special meaningful names and themes for their routes, which is fine but only for maps of their own routes.
OSM stores the information for special use cases, not for labels on general maps. (That said, if an application allows me to toggle route names on their map, I will occasionally use that).
So, in all my posts, it’s about the symbol and the ref and making those details (machine readable and) renderable as a simple route label. I don’t want to describe the artwork shield in tags, only the (simplified) symbol, the ref and the name.
If someone creates (or has someone already?) a collection of images of all signs and symbols and shields and signposts hands, fine, and no problem if mappers map a link to that in all route relations or network relations, but I think that will be very hard to complete, to maintain, to guarantee quality, and to use.
I totally agree that the rendering and the style is for the renderer to decide; when left to the community of mappers, the map would surely become a disaster. We all want “our” routes to shine, right?
Have the French sued Poland yet for the abuse of their hiking symbol?
3 Likes
I don’t know. We don’t talk to them, actually. It’s too bad, but I’m told that OSM France and them have not reached consensus last time they met and nobody has yet contacted them again. I might do it, but I’m still trying to understand the situation and our options.
I have tried to talk with the european federation, since there is one of their leaders here in the OSM community. But they seem to have less influence on these topics than, say, ECF has on national cycling associations.