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.
Perhaps start a separate topic then?
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. @ConradWard added the name and the next day @Mashin removed 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.
And yet irrelevant to us United States based mappers as it apparently only covers Europe.
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?
On the one hand, these small trails do not match the criteria discussed earlier in this thread for creating type=route.
On the other hand it can be handy sometimes to have relations. The situation looks similar to streets, actually.
Would it make sense to have a relation type for that, so that documenting it helps clarify the results of this discussion for beginners?
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.
I think Komoot offers this as part of their “premium” product - they call it “sport-specific maps”.
This is probably worth a broader discussion that isn’t limited to the U.S. Previous discussions about street relations have run into a familiar slippery slope argument, that an overzealous mapper might blanket a city in street relations, making any kind of street editing a royal pain. Indeed, this has happened anyways in some cities using route=road, in the absence of a dedicated tag for streets. On the other hand, fears of relation overarchitecting haven’t borne out with either route=railway or type=waterway.
Between that and the community’s apparent acquiescence to route=fitness_trail, a tag to distinguish non-fitness trail relations from trail route relations would seem quite logical to me. That said, I’m not sure it would clarify the issue at hand, about naming the member ways. No one would feel comfortable deleting names from roadways just because they’re members of street relations.
These two points are the core of the issue. A name on a way is a valid and proper way to tag a path’s name. That it may also have a route relation does not change that and is not an acceptable reason to delete the name from the way. Maybe in some far off future it will be, but that’s not the case currently.
