Just to give more context, in Connecticut not all trail have names, but they are almost always marked with blazes of different colors. Some of the trails can cross distances and can follow paths and roads that have an actual name that is different from the trail name itself. And on top of that multiple trails can share the same physical path e.g. New England Trail.
Slight off topic:
It is not only Carto but nowadays also apps like AllTrail, Gaia, Komoot, … that don’t show (among other important information) hiking relations. People then often come to OSM and try to hack this info into name= tag so they see it an their maps. I think maybe this whole discussion could be boiled down to whether we cave in or we rather make the app companies to adapt to us.
I am personally more for the latter. If you have time consider upvoting or commenting here: AllTrails: Adding-official-hiking-trails Gaia: Add-support-for-route-hiking
Why would Highway=path/footway be different from other highways in this regard?
On all other highways, they get a name tag if the road has a name, even if we divide the road into separate ways for bridges/tunnels/differing surfaces/etc. and then if there is a ‘route’ that happens to share the road (ie state way 101 is concurrent with Main st for a while) it gets added as a relation.
Saying every trail needs a nameless way and a route relation seems like a lot of unneeded complexity in 90% of cases.
Even waterways have duplicated tags on way and relation. It’s extremely common practice in OSM so it seems best practice by consumers to just be aware of that.
On that point, entirely separately from the question being discussed here, I would have thought that an app without that capability was entirely useless in an area where they may be more than one named route.
Where I am right now I’m on (checks map) a locally named stretch of riverbank that is on 4 different walking and hiking routes, each maybe 10-100 miles long.
Would it make sense to have one topic (this one) where local practice in the US is discussed and another about the global situation for hiking? I personally would perceive a level of inconsistency in doing that.
I would say yes that makes sense. This topic was opened about a dispute between mappers in Connecticut and I would like if it could remain focused on US trail mapping practices.
Appreciate your esprit de corps, Mashin. It is unfortunate that these companies choose not to support relations. I find it rewarding to map them and see them on sites that show that info.
However, we are not in the business of making app companies adapt to us. They can do whatever they want. Instead, we the OSM community, should provide incentive to adopt open standards because the community here embraces them.
I have experience working with some of these hiking map focused firms. They are careful and conservative about even minor cosmetic changes to their products. Product management is a major, driving force behind every decision. They are respectful of the OSM Community, but they tend not to wade into open controversy directly, especially if it is newsworthy or if they are a high value/public company. Absent any community action, I think they will sit on the sideline until the rest of us figure this out.
Within the OSM:US Trail Access Project, a number of us have gotten together to meet these companies (and government agencies) directly to say, ‘hey look, we’re doing this cool set of tagging recommendations and striving for consensus… come join!’ My opinion: that is the way to inspire change.
I assume you consider the route relation to be the source of complexity. But many route relations represent non-routes because Waymarked Trails only recognizes route relations. As a result, a router might avoid departing from the “route”, even though it’s just a trail name and there’s no shame in taking a shortcut around part of it. It’s a classic example of why we frown upon tagging for the renderer. There’s already route=fitness_trail to consolidate some named trail infrastructure; should there be a route=trail for the rest? I’m not too keen on further stretching the concept of a “route” for more kinds of non-routes, but at least it’s better than muddling route=bicycle etc. as mappers do today.
Would anyone’s opinion change regarding naming a road based on the numbered routes it carries if we apply this same situation to trails? Many shared use paths and rail trails are still known by their original local names even if they now carry a numbered long-distance cycling route, but we can expect the route numbers to become more prominent than the names over time, especially on the U.S. Bicycle Route System. I grimaced at labels like “State Bike Route 3” when they first appeared on Google Maps many years ago, as overzealous Map Maker contributors eschewed locally well-known trail names. But eventually users will come to expect bike route shields, at which point a spelled-out label conveying the same information wouldn’t seem so weird either.
Do these applications have a strong incentive to do more than the bare minimum of supporting name=* on ways? Regardless of whether these trails in Connecticut should have explicit name=* tags, if enough trails have name=*s nationally or globally, a data consumer might not see the benefit in ingesting relations and all the complication that comes with them.
It reminds me of the tortuous history of way ref=*s and our yearslong hopes of deprecating them in favor of route relations. These days, the situation is looking up, with multiple renderers now supporting route shields based on route relations, but that’s only because the state of the art and user expectations have finally advanced beyond a single number inside a bland badge. It’s gotten to the point where we seldom include some minor kinds of route numbers in way ref=*s anymore, a sort of soft deprecation. Maybe someday, eventually, we’ll drop the other shoe and start removing way ref=*s altogether, but it’ll require a hard decision to leave some data consumers by the wayside.
What would a similar shift look like for trails? If a community-developed renderer such as OpenTrailMap or Organic Maps could draw route shields or something else from route relations, and if a geocoder such as Nominatim could return results for route relations at all, then deemphasizing way name=*s might start to sound more attractive to more mappers.
I feel like we crossed that point before I joined the project, considering relations were being actively developed for this exact problem way back then. ref on ways to describe routes is something that should already be long dead.
There has been a lot of talk about long distance hiking routes like the Appalachian Trail in this thread, but mostly the dispute in Connecticut is over much shorter walking trails in small parks. Take for example the Chimney Trail in Chatfield Hollow State Park. @ConradWardadded the name and the next day @Mashinremoved the name from the way in favor of the relation. This small loop is less than half a kilometer long and doesn’t overlap with any other named routes. It’s pretty clearly a named path. I’ve certainly added route relations for short paths like this so they would show up on Waymarked Trails. However, I don’t delete the name from the trail ways when I do so because I know there are many OSM based trail maps that don’t pull names from route relations. Truthfully I have a hard time rationalizing how such short paths could really be considered hiking “routes”. So maybe short trails like this shouldn’t have route relations at all, but what exactly the criteria should be for a hiking route relation is unclear.
Definitely not a route in the real-world sense. But a route in the sense of type=route? In my opinion, only if we find some value of route=* other than hiking for it, some value that isn’t there purely because of Waymarked Trails. And even then, it kind of stinks to stretch the meaning of type=route beyond a real-world meaning of route.
It’s been enlightening learning about different situations in different parts of the world regarding long distance routes. Specifically in Connecticut, the vast majority of trails are short. You wouldn’t assign a route number to every little side street in town. Likewise, most mappers aren’t creating routes for every local trail. It’s just a trail, nothing more. And if the community can’t agree if it’s just a trail or a route relation, just add both in. Are they really duplicates if they both refer to different things, even if it’s a subtle difference?
This is the first time I have seen this Waymarked Trails website, thanks for sharing! It seems like an effective way for renderers to display a world with both names and routes is to have the ability to toggle between the two. Much better than just deleting all the names, which is destructive.
Yep, the reference implementation for osmc:symbol. Unfortunately, that syntax – and the overall concept of a universal ontology for blazes – doesn’t scale well to the wide variety of route marking in North America. And wiki:symbol is problematic for other reasons. Does anyone know of a renderer that has implemented arbitrary route marker support along the lines of what OSM Americana did for highway routes?
I agree with that. But I also have to say the other part: We are not in business of fixing someone’s map by hacking info into name tags.
You guys did an awesome job with the trail stewardship initiative. Back then we also didn’t allow landowners to delete all private trails from OSM just because AllTrails didn’t display them properly on their map.
In case you are still meeting with them at some point, I would be super happy if you could just even bring up the topic of hiking routes to them. I am really curious about their reasoning.
I don’t think that having two standards of trails mapping based on some arbitrary length parameter is a good idea. Ideally we would want to have all trails mapped the same so it’s easy to query them and programmatically parse all the information.
I think that if someone put colored blazes somewhere they meant it as a route for hikers regardless of it’s length. If there are no blazes and only a name, that’s a bit more complicated and I don’t think I have a clear cut solution to this.
There is OsmAnd App that supports both names and osmc:symbol tags from relations.
And there is also Mapy.cz that also seems to have a smartphone app and support name and colour tag from relations.
In addition Gaia has this trail overlay based on hiking relations.
Edit: I also just found that Komoot uses the names from hiking relations but in thier paid Premium layer.
Another issue arising from name tags is how far are people sometimes willing to stretch the meaning of name. Strings like red trail or blue-yellow / blue trail is clearly not an actual name, but a description that was put into name tag for a purpose of being displayed on AllTrails map.
Regardless of whether not there is a route, removing names from the highway way representing a named path is outright hostile to most data consumers.
Sure, really advanced trail consumers might be convinced to deal with all the logic necessary to pull them from routes, but for a data consumer whose focus is not trails but that does want to show them on their map, suddenly the amount of code/effort to do that is increased substantially.
I certainly may be missing something, but I have a hard time seeing the the major benefits removing names brings that would warrant making the data so hard to use/different from the way every other highway is tagged.
If you make the data unnecessarily hard to use people just aren’t going to use it, or go elsewhere for it.
