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.
Perhaps that makes sense in Germany, but in other parts of the world, the situation is very ambiguous. Sometimes there are obvious cases where the “XYZ Trail” or “Something Road” is a section of the “ABC Long Distance Trail.” Sometimes, there are sections of “ABC Long Distance Trail” that have no other name. Our common cultural understanding of those situations in the United States is that those sections of trails are simply named “ABC Long Distance Trail” and thus we would generally consider it correct that the path ways and the route relation would have a matching name.
A similar debate in the United States extends to roads and road route relations.
There are no clear-cut answers because there is no clear-cut reality. Be very very cautious about trying to apply local or national cultural understandings elsewhere, because they often will clash in different contexts.
Ironically, the better analogy is in other countries besides the U.S. At least in most U.S. states we have something of a distinction between roads and the routes that follow them. If you go to London, point to Lewisham Way, and ask someone on the street if A20 is the road number or the route number, you’d probably get a quizzical look in response. (Officially, it’s a road number, but road numbers sure behave like route numbers.)
Unless I’ve misunderstood, it seems to me that @aighes and @Zelonewolf may actually be in agreement but talking slightly past each other. There are essentially three different situations:
| On the ground situation | OSM tagging |
|---|---|
| Named route following a nameless path | relation: name=Name A way: omit name |
| Named route following a path with a different name | relation: name=Name A way: name=Name B |
| Named route following a path with the same name | relation: name=Name A way: name=Name A |
If the path is named, the way gets a name. If the route is named, the relation gets a name. If they are both named the same thing, they both get the same name tag.
My contention is that this situation:
and this one:
…are in fact the exact same situation and we are creating a distinction that either doesn’t exist or only exists in different cultural understandings.
I have no idea how you would survey a trail and decide which of these cases is extant.
This table is a bit of a tautology, just saying the same thing in human-readable and machine-readable terms. Isn’t the question before us whether the path is indeed nameless?
For a fifty-some-post-long topic, I’ve seen very few examples to clarify what we’re even talking about. Maybe someone can help me understand based on these examples in my neck of the woods:
Unfortunately, I don’t have much in the way of on-the-ground imagery to share for any of these examples. But what should I be on the lookout for, to decide what to create a relation for and what to name?
Imagine that “ABC Long Distance Trail” follows some pre-existing urban paths and sidewalks through a town. I would not consider ABC Long Distance Trail to be the name of these paths because they are first and foremost part of the town’s pedestrian network and in that context they do not have names. On the other hand I would consider ABC Long Distance Trail to be the name for a path built specifically for this long distance route. This is a suble distinction that requires good local knowledge to make, but I don’t see these two situations as exactly the same.
