Shields, blazes, artistic license, and intellectual property

Continuing the discussion from Bike route networks classification (ICN, NCN, RCN and LCN):

I’ve been harping on a lot about shields as a use case for specific network information on recreational routes, so in case there’s any misunderstanding: blazes and shields are different concepts. A route can have both, so OSM needs to enable data consumers to show both.

Indeed, a given route may have a single shield design signposted along the entire length of the route, a simpler shield on maps due to space or ink constraints, and multiple distinct blazes on the ground that vary by the segment. Sometimes a given route will use a blue blaze whenever it follows an off-road hiking trail but a more complicated shield whenever it follows a bikeway or roadway.

For example, the Buckeye Trail is marked with a blueish blaze on tree trunks but with a more intricate shield in the shape of Ohio on bikeway wayfinding signs. Hiking maps just show a blue line, but multimodal transportation maps show the shield instead.

(That sign shows a concurrency with the North Country Scenic Trail. The trails only overlap halfway, yet both trails have the same motto: “Follow the Blue Blazes”. Oops.)

Making matters worse, shield designs can change wholesale across a network. Several years ago, the Ohio state bike route design changed from a lozenge to an oval without notice. About a year ago, the standard design for all U.S. Bicycle Routes changed overnight, not the first time this has happened. Blaze designs tend to be more durable, even if paint can fade. After all, intentionally changing a blaze from one color to another could easily cause confusion.

Traditionally, in OSM, we’ve conflated the two concepts within symbol=*, osmc:symbol=*, or wiki:symbol=*. A renderer has no idea whether an osmc:symbol=* within the U.S. is a description of a blaze or (an oversimplification of) a shield. It all depends which one the mapper encountered while mapping. In the case of the Buckeye Trail, the shield is too complex to describe in the OSMC symbol syntax, so osmc:symbol=* only describes the blazes.

Ideally, a North American trail renderer would represent both the blazes and the shields somehow, so the user knows about both aids when wayfinding. For example, the path of the Buckeye Trail could be tinted in blue, dotted with the shield at intervals. OSM-based renderers currently show “BT” in a rectangle based on ref=*, but this is just a stopgap.

Shields are much more likely than blazes to rise above the threshold of originality, because printing and signmaking technology is far more advanced than hand paintings on tree trunks. At least the legal situation over here in the U.S. would clearly protect any heraldic description of a blazon or coat of arms, and any image drawn from scratch based on such a description.

Whether OSM describes the blaze or shield directly on the route relation or leaves the presentation up to renderers, the renderers still face the exact same legal situation based on what they’re showing. OSM is just an implementation detail. While a renderer can’t necessarily achieve a pixel-perfect rendering of an NGO’s fancy logo due to a copyright or trademark, it might be able to simplify the design down to very basic shapes that fall below the threshold of originality while remaining recognizable to map users.

For example, OSM Americana’s depiction of the Ohio River Scenic Byway only captures the essential elements of the true shield, which is too complicated to make out at a small size. I took some artistic license, omitting the riverboat, the scroll, and the text. The church steeple might not be structurally sound. But hopefully the user gets the gist, especially if they consult the legend. A different designer might take different liberties with the design, for example if the map has no legend.

Besides copyright and trademark protection, some laws specifically prohibit mimicking insignia, to prevent impersonation. A map can’t impersonate anyone, but the laws are sometimes worded too ambiguously. For example, OSM Americana recently had to back out some lovely shields for the National Historic Trail auto tours in favor of plain Reuleaux triangles, because the National Park Service legally controls usage of the insignia “or any colorable imitation thereof”. The Wikimedia Foundation once sent an epic retort to the FBI over these sui generis regulations,[1] but I think we’d prefer a more cooperative approach with park managers.

Beyond the law, some shield designs incorporate symbols that indigenous groups consider sacred. OSM Americana has sought permission from these groups before reproducing the symbols, out of respect, even if the symbol is legally unprotected and the authorities post it on all the signs. Some renderers may not care to this degree, but it isn’t a mapper’s decision to make.

The precise shield presentation will necessarily differ from project to project, even interactively. Unfortunately, the OSMC symbol syntax is too rigid and specific for this purpose. Maybe the shield should be simpler when zoomed out and more intricate as you zoom in? A completely different set of colors in dark mode, or a different kind of squircle if an older user has Large Text enabled on their phone? Or maybe the map dispenses with the official branding altogether in favor of generic shields or ad hoc symbols that the user can look up in a legend without squinting:

Regardless of these factors, the shield design is still part of a set that spans the whole route network. A semantic key like cycle_network=* is crucial for generating a usable shield or line style, even though that key isn’t explicitly about symbolization. The data consumer is responsible for translating the semantic information into pixels based on context that mappers simply don’t have.

Meanwhile, symbol=* or osmc:symbol=* can still be useful for communicating information about the blazes to map users. Imagine a router for hikers saying, in plain text or out loud, to “follow the blue blazes”. While this information can also come from cycle_network=* or similar, blazes can be less consistent on the ground yet even more critical for wayfinding than signs.


  1. One mapper colorfully calls them “eldritch copyrights”. ↩︎

1 Like

Shields and blazes are probably more american than european (fun fact: in French “shield” would probably translate as “blason” in this context), but this definitely would be useful in Europe too. For instance in France most Camino routes have a shell for shield and two yellow and blue stripes as blazes.

Here, as far as I can tell it is trademark protection that is used for this. In my job I have been involved in applying for a so-called “collective” trademark to protect a quality label awarded by the government, just like our national federation has applied for trademarks to install its network as a quality brand.

Unfortunately, here things go beyond this. The aforementioned trademarks are also used by our national hiking federation, in its capacity as a publisher that does not like competition, to not only protect the routes themselves but also their maps and their guidebooks. A couple of years ago a website that uses the Waymarkedtrail Hiking layer was asked to remove the white-red shield that appears on some routes.

I remember that trademark laws and treaties define an exception for “necessary reference”, when the description of your product must refer to another product to express its own value, e.g. “my software is iOS-compatible”. Does this apply to maps and routes?

Also, trademarks apply only in the countries that the applicant has requested. I do not know how this works with OSM

There are different kinds of copyrights and trademarks, with different implications. Some trademarks are limited to certain lines of business or certain mediums. As a map designer, I might want to be careful depending on my legal resources. When I simplified the Ohio River Scenic Byway shield to avoid copyright infringement, I risked trademark infringement in the other direction: if I had taken too many liberties with the logo, maybe made it look really ugly, maybe it could be construed as a misrepresentation of the trademark. And if for some reason OSM were to make this route difficult to distinguish from some competitor’s route, that could cause the map to violate the trademark too. What matters is the intention and the actual harm to consumers.

The sui generis laws are different, and especially frustrating. Works of the U.S. federal government are in the public domain, but the regulation I mentioned explicitly bans unauthorized reproductions of the insignia, despite its federal authorship. The authority it invokes doesn’t relate to copyright or trademark law at all. The ostensible reason is that park rangers might physically wear the same image as a badge or ID card; the law prevents someone from impersonating the park ranger and defrauding visitors. Common sense says this regulation shouldn’t apply to the dissemination of accurate trail maps. Hopefully that’s a legally sound interpretation too.

Governments abroad would have no reason to enforce this regulation, but that’s little comfort to data consumers based here. Let’s suppose the regulation does apply. Should we omit anything from the database that might lead a data consumer to unwittingly violate it? Why not instead state the indisputable facts: the identity of the route and the network to which it belongs. Then the data consumer can choose how to navigate the legal landscape on its own.

I proposed this to the French community a couple of years ago, given that our local hiking federation also claims copyright on the geometry of the routes it applies its trademark on. I was told this would never be widely accepted. Maybe it is time to prove them wrong :smiley:

2 Likes

Our national hiking trail provider holds trademark, licenses and whathaveyou on the logo’s/blazes/symbols, and on all its products with the logo’s on them. Stickers, shields, all with several forms and variants. Also, the trails themselves are their intellectual property. The licensed material, however, is very precise. Exact colours, materials and dimensions of all variants and products. They can’t say hey, we own anything white-and-red.
Too bad they have been saving pennies by using low quality stickers and shields, which fade and crumble in the sunlight, so now they have to spend many extra pounds on maintenance… I know, because I maintain some of the routes, and better materials would save me a lot of time. I they had to pay for my time… oh well.

What they do not want is for competition to make profit from their products. That is why they protested a lot against OSM, they thought we were using their products to market ourselves for profit. We have managed to get the fact cross that OSM is not a competitor, and that they themselves are free to use OSM for their publicity beyond their own website. We guide people to their website and webshop, and we do not add value to make a profit. I think by now they are aware of that.

Still I say, let’s stick with vague but recognizable descriptions, and leave anything too detailed out. The trend to use detailed themed infographics and stylized artwork for routes is noticeable in Nederland as well; we can’t use that exactly and heraldic-like descriptions are very complicated, I don’t see that happening in OSM any time soon.
As a hiker, I also dislike complicated shields. I am all for the simple one-colour paint dot, like for the Via Degli Dei crossing the Apennines. The paintblazer even dotted the official symbols and shields, and were especially helpful on terrains where no shields or stickers were present, dotting fallen trees, stones in the middle of a river, rocks on a barren mountain top.

I even saw painted sheep, though that might have a different meaning…

Who is “we” and “us” in this statement? US-OH:Buckeye or Q4983100 may be more specific than blue::blue_stripe, but that’s beside the point. blue::blue_stripe is much more prescriptive. What if I want to make a map that marks X’s along the National Scenic Trails and O’s along the Buckeye Trail for readability, then describe them both as having blue blazes in the legend? Since when does OSM say that motorways must be blue and trunk roads must be green?

I would say it’s descriptive, and not very detailed, a renderer has lots of freedom how to use it, or not to use it at all. I have to say, I ignore the first colour (blue in this example) altogether. I know OsmAnd gives me a choice to display the routes with this osmc-specified colour.

I am not thinking about shields for motorways and trunk roads, just recreational routes using paths, cycleways and foot-accessible roads.

There may be a difference in perspective. I come from more of a cycling perspective: over here in the U.S., bike routes don’t have blazes, and the shields can be systematized as rigorously as highway route signs for motorists. The usability of the routes varies, but this isn’t a situation where every route is one of a kind.

The national standard sign for an official state or local bike route consists of a green oval with a network-specific logo or pictogram cut into the top:

Each of the 18 routes in the county bike route network of Marin County, California, has signs that include a green mountain pictogram. The relation for Route 6 has cycle_network=US:CA:Marin, allowing data consumers to call it “Marin County Bike Route 6”, or highlight the route at the same zoom level as all the other California county bike routes, or display a replica of this sign, or simplify it down to just a 6 in an oval, as space allows. osmc:symbol=green:white:green_circle:6:white cannot achieve any of this.

Just across the San Francisco Bay, there’s a different citywide network for San Francisco, marked by an image of the Golden Gate Bridge. This is the sign for a concurrency of San Francisco Bike Routes 30 and 47. They combined the signs into one since the overlap is so well-known.

On the other side of the country, here’s a private multistate route, not to be confused with any national or state network, bearing the logo of the nonprofit organization that designates the route:

The national standard also allows a jurisdiction to display a more generic shield:

Thus, just by looking at the following three signs out of context, you wouldn’t know that they mark routes that belong to the Ohio state network, North Carolina state network, and no network at all. But as mappers, we can tell the difference.

So goes the standard. Plenty of networks don’t follow the standard, like this county route network that uses a green pentagon on each of its routes:

Imgur

Or this state route network that uses the shape of the state:

I have no problem with continuing to describe blazes or symbols for hiking trails in the OSMC symbol format, especially for routes that don’t belong to a broader network. But this should not be the only way to distinguish one route or route network from another. Otherwise, it’s rather like saying: just map the signs and ignore what they mean!

We consider mtb and bike routes two different things, right? Here, the former are blazed and the latter are not as far as I remember

I think it varies. In the U.S., I think they tend to be blazed like hiking trails or just marked by name, whereas some of the MTB trail signs I’ve seen around the Internet from elsewhere look like organization logos that have been repurposed as trail markers:

It’s probably because MTB trails are still largely the domain of enthusiast associations and park managers, rather than transportation agencies. Bike routes in the U.S. were much the same way back when I started mapping, and some still are. But since then, highway departments have taken more responsibility for bike routes as part of various sustainable transportation and school safety programs. It’s an awkward fit – sometimes you get the feeling that the highway engineers don’t really understand what bicycles are, that they think of them as strange little half-cars.

On most pictures I see a mostly green oval shield with a white bicycle and white route ref, sometimes a second colour for the picture part indicating operator or administration. For those osmc:symbol can describe the shield. Owner and operator details go in their own tags. If it’s some kind of separate network, cycle_network can hold the name or ref for that.

The osmc:symbol scheme can be expanded (or extended? I never remember the difference) with more colours and more shapes. For colours you could use the hex codes. For shapes, you need keyword-shape pairs. The thing is, you need route renderers to support the expansions. If you are the main route renderer for an imaginary (yeah, right!) country that uses very special colours and shapes, you can implement the whole thing yourself.

PS. With routes, you can never be sure of anything from one shield, even multiple shields, unless you know more or have other sources.

Just to chuck in some more examples - here are some northern English route markers and guideposts, mostly on hiking routes and cycling ones. There are some MTB ones, such as this, but those are really variable depending on the operator of the route.

This is about networks, not owners or operators. A network is a set of routes that operate together as a system, whether through interconnectivity or consistent branding. As a rule of thumb, a given route number doesn’t repeat on multiple distinct routes within a network, though there are exceptions. A given agency may be responsible for managing multiple networks (so we tag the agency as the operator=* of each network’s routes), and various other agencies may maintain the physical infrastructure that carries these routes (which we tag as the operator=* of individual cycleways).

I focused on the standard green ovals to avoid overwhelming this discussion. The vast majority of bike route shields have nonstandard designs. This makes it all the more important for some renderers to attempt to simulate these designs. The good news is that most of these designs, once simplified, probably will not be subject to copyright protection. Ironically, it’s only those federal Reuleaux triangles that we need to be careful about until we get ahold of the right officials.

Tentatively, I agree with you that these separate networks belong in cycle_network=*. It’s an unfortunate key name, but it’s what we’ve got for now.

If only.

The osmc:symbol=* scheme has many problems. It symbol selection is explicitly eurocentric (“hiking paths used primarily in Germany”). Very few of the symbols ever occur in North America. It doesn’t even provide for a bicycle pictogram, by far the most common element of a bike route shield, let alone the ingredients necessary for describing the hundreds of local network pictographs that occur on those oval signs, let alone the probably thousands of nonstandard shield designs across the U.S. Adequately expressing this diversity of designs would be a massive distraction for mappers who just want to map.

Until very recently, the wiki insisted that osmc:symbol=* was a proprietary scheme, take it or leave it. Though the wiki no longer defers to the scheme’s original author to such a degree, it still isn’t clear whether we can ever extend it beyond the current set of shapes. As a workaround, some mappers have tried to turn the wiki itself into a rendering engine using wiki:symbol=*. This idea is a nonstarter in practice.

You’re absolutely right, the renderers should be responsible for drawing their own graphics. Fortunately, this is what they’re good at! Renderers do not need mappers to encode alt text for route markers. They need us to interpret the markers for them. By analogy, when you see a :no_bicycles: sign, a router wants you to say that bikes are prohibited, not that it’s decorated with slashy-bikey ornaments.

I realize you don’t care about road routes, but I ask you to consider the innovations that are taking place in that department. Many renderers already draw their own shield graphics for road routes. Some are limited to a simple set of generic shapes, while others like OSM Americana aim for higher-fidelity designs. Each implementation has a different artistic style. Beyond shields, routers and geocoders use network=* to construct a systematic name for a numbered route. The format of a systematic name usually has nothing to do with the shield’s appearance. It may vary by language and diction.

This diversity is good for users. It’s only possible because road mappers set network=* to a presentation-independent value. Based on this value, the renderer chooses a template image from its own repertoire and fills in the ref=*, recolors the image based on colour=*, or adds a pictograph based on name=*. The OSM Americana project publishes a freely reusable repertoire of over 180 template images plus a dozen basic shapes. That’s just for highway routes, and we’re far from finished with those. I expect hundreds more once we’re through with bike route shields. The contents of these SVG files don’t belong inside the OSM database.

Never is a strong word. Many biking and hiking route shield designs incorporate text in case the symbols are too obscure. I think this is the Continental Divide Trail, just a guess:

And I’m almost positive that this is the Mount Carbon Loop Trail:

But you’re right, I have no idea what this sign is for – it must be the Lollipop Route. :stuck_out_tongue:

As said before, cycling is somewhere between road routes and hiking routes. And the more we talk the more I feel that there is an intrinsic difference between roads and hiking: often with hiking signs/blazes/shields/whatnot there is no room for consumers to be creative or to avoid reproducing trademarks. Things like “yellow bar” or “white and lower red bar” leave little room for imagination…

I regard the osmc:symbol as a format to describe symbols in text… As such, it is not limited to any selection of shapes, colours and symbols. Anyone can make a selection of symbols, colours and shapes. Some selections are currently in use, but they are not THE selection. I say, let’s try and come up with a selection of shapes that better fits the US, and add some shapes for Nederland, I mean Europe, at the same time! Then mappers can describe the signs more accurately and renderers can decide to support it to improve their maps for their users.

It would be nice to have someone with knowledge of rendering before proposing such an extended selection, because the extensions should be manageable for renderers. Think like a renderer when proposing shapes and symbols, keep it simple, that kind of thing.

Alternatively, I just read about an AI assistant that can create images based on descriptive text. If open source variants of such an AI become available, we could just stuff a load of descriptive text into the symbol=* tag and the AI at the renderer’s side can come up with a nice shield image.

Your opinion is very reasonable and would aptly describe symbol=*, but it isn’t how osmc:symbol=* has ever been documented. It’s no coincidence that the key is named after a particular renderer. Then again, we’re talking about making sac_scale=* depart from the SAC scale, so anything goes, I guess.

Take it from someone with knowledge of rendering: this is a fool’s errand. Extending the OSMC symbol scheme is a very sensible move that I would wholeheartedly support, but it won’t address the use cases that I’m referring to.

It is possible to describe this logo of a bike/hike trail in plain language, but without basically encoding the source code of this SVG file inside the tag, we would be misleading a renderer into violating the organization’s trademark. Faithfully reproducing their trademark is not a problem. Distorting their trademark against their brand guidelines is a problem. And how is a data consumer supposed to know that the trapezoids form the number eleven anyways, so that it can know what to call the route network?

Why tag symbols at all? Just point mapillary=* or panoramax=* to a photo of the marker and let the machine do the rest.

That’s true to some extent, but we aren’t mapping quilt trails; the consistent application of these symbols also has meaning apart from the symbol’s literal appearance. All I’m asking for is that we also interpret the symbol and record that fact.

I suspect some of the hesitation to tag networks semantically is that it forces a data consumer to maintain a mapping from network identifiers to actual graphics. But most renderer developers would prefer that to a much more complicated system that requires them to dynamically compose an arbitrary set of graphical elements. Even the very advanced OSM Americana shield renderer still falls back to premade graphics organized by network 95% of the time. Ironically, without something like cycle_network=*, an application is also forced to maintain its own mapping from these descriptions of logos to the names of the networks. “Yellow bar means yellow bar” is not a very informative map legend!

Allow me to give another strained analogy. The Golden Arches are some of the most prominent features on the American landscape, but we still tag a McDonald’s as brand=McDonald’s brand:wikidata=Q38076. Yes, brand:symbol=double_arch:gold would be technically correct, but then someone might come along with a logo that differs in some subtle way that we didn’t account for. How will a search engine know the difference between “McDonald’s” and “McDowell’s”?

Then you would be reproducing/distributing copyrighted materials, in a way that in some countries is not legally allowed.

Ah, so you want generative AI to paper over those legal inconveniences. That’s still an unresolved legal issue. :crossed_fingers: Anyways, generative AI isn’t a solution to the problem. Mappers want to map, not moonlight as prompt engineers.

I recognize that the laws protecting trail symbols may be stricter in some countries than others. A data consumer may need to avoid a particular symbol in one jurisdiction but the same symbol must be reproduced faithfully in another. If a data consumer must fall back to just the name of the trail or route network to avoid infringing on copyright or trademark, it should do so based on a positive identifier rather than guessing based on visual resemblance.

Fortunately, neither copyright law nor trademark law protects human interpretation of signs. A public toilet may be marked by a copyrighted or trademarked symbol, but you don’t have to pay royalties to the artist just to use the facility, and neither must the search engine that led you there.

I am a bit lost as to who is pointing which problem and defending which solution, so could we take a concrete example?

In France we have a recent nwn route named Chemin d’Amadour who was designed by four local governments and that has a complex logo representing a stylized mother and child. They received (or will soon receive) the right to be blazed with the white-red stripes of the national federation, to be known as GR® 81, hence becoming part of the national network. How would you tag it, ideally?

IMG_3291

With the caveat that I’m not very familiar with how hiking trails have developed in France, I’d imagine something like this ideally:

  • type=route
  • route=hiking
  • network=FR:GR
  • ref=81

or perhaps, following the tagging scheme for railway and public transport routes:

  • type=route
  • route=hiking
  • network=Grande Randonnée
  • network:area=national (or network:type=national)
  • network:wikidata=Q1486662
  • ref=81

or, succumbing to inertia:

  • type=route
  • route=hiking
  • network=nwn
  • hiking_network=FR:GR
  • ref=81

The important thing is to explicitly indicate the route’s membership in the Grande Randonnée network somehow. A data consumer will need to translate that information into visuals, text, audio, depending on its form factor.

If you want to add osmc:symbol=* too, no problem, but just osmc:symbol=* alone is inadequate, because completely unrelated trails are marked similarly in other parts of the world. network:area=national alone doesn’t positively identify this network, even with spatial queries, because national routes can wander into neighboring countries. (Some of the U.S. national cycling routes are mostly in Canada.)

If the Chemin d’Amadour keeps its original identity in conjunction with GR 81, as an independent route that happens to overlap, then the individual ways might be part of both the GR 81 relation and another one at the same time:

  • type=route
  • route=hiking
  • name=Chemin d’Amadour
  • wikidata=Q117602254
  • symbol=Mère et enfant (to be shown in plain text as a hint where appropriate, never parsed as machine-readable syntax in order to choose or generate an image)