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.
No, it might just avoid polluting the debate with questions about whether there should be or should not be a relation there. The question about names (and the answers found so far) would become the same, whatever the nature of the trail.
It does, just brought this up since it’s the most powerful hiking-shield rendering map.
My hiking experiance in the US is limited, though I would agree, that the majority of the US trails having names and the route descriptions are based on those names. Like follow xyz-trail until reaching abc-trail, then follow abc-trail till the peak.
Copying name tag from relation to its child members does not seem to me like a super hard problem. What about data consumers that don’t want to show trail names or are using names from relations but the names on ways make a duplicate label?
Copying name tag from relation to its child members does not seem to me like a super hard problem.
I’d just you try out using PlanetTiler, Tile Maker, or osm2pgsql to create a non-trivial tileset from OSM data. It’s fairly eye opening to deal with some of the surprising challenges of converting OSM tags to renderable data.
To add a couple of examples, I believe that the flex output of osm2pgsql would support that in lua (though the old “standard” output doesn’t). There’s a version of OSM Carto around which uses flex which worked when I tested it. It’d be an interesting exercise for someone interested** to copy relation names down to ways.
It’s also been supported by mkgmap / Garmin since basically forever (the example code has a proof-of-concept for buses); it’s trivial to do something similar with hiking etc. routes.
** which wouldn’t be me; I have an OSM Carto-based style that handles route relations in a different way. If someone wanted to port that to flex, fill your boots; but it’s not been a priority for me.
If a way is a member of just one relation then it shouldn’t be terribly hard, though a bit more work than simply getting the name tag off the way. However, for ways that are members of multiple route relations (the whole point of route relations) it can become complex, raising questions with unclear answers. If you are trying to just display the most local path name (not all route names) it is not clear how to identify which relation represents this. If one relation has a network of lwn and the other is nwn it may be reasonable to assume the former is the name of the path. [1] But maybe they are both lwn, or maybe there are 5 different lwn routes, or maybe a mix of lwn and lcn. Which name should be chosen as the path name then? A situation like this can also mean that the named routes are all following a pre-existing unnamed path, in which case it isn’t appropriate to use any of the names from the relations as the path name because the path truly doesn’t have one.
Thought his could be wrong if the longer route is older ↩︎
I don’t think neither of you is right or wrong. It’s simply not the question. Either the way has a name, then the way should get a name-tag. If the way has no name, but there is a route using the way and having a way, then the route should have the name-tag.
If a data-consumer decides not using route-relations, that’s ok. Though it should never be the reason to change our data just to make data visible in a specific service.