In other words, wherever there’s a gap in dedicated off-road facilities, the trail’s managers or route log don’t prescribe exactly which sidewalk, crosswalk, or parking lot aisle you need to follow to follow the trail. It’s much too specific for a long-distance trail.
We specify these details because our data model requires a contiguous linear path, rather than a collection of trees and poles that happen to have blazes on them, but you could make a point of walking on the grassy verge or the middle of the street for all the organizers care. Yet a long-distance trail is still a route, when you zoom out a bit metaphorically.
Can we find another example? I think the Appalachian Trail is a bit of an outlier. Few trails are so famous. I wouldn’t be surprised if the trail has even lent its name to nearbystreets.
I don’t quite agree. A long-distance trail is different in nature than a dedicated physical trail. It’s a technical distinction that relies entirely on intuition. Pointing at the ground and asking “What is it?” is silly and doesn’t help at all, because no normal person would care about this distinction.
Perhaps an extraterrestrial visitor can pick up on the fact that one tends to hike or bike on a dedicated trail but follow a long-distance trail as it in turn joins, continues on, and forks from a road, path, or dedicated trail. Or that many long-distance trails are marked by Reuleaux triangles or blazes, and one can order a guide book from a non-profit association. Or that a route log might refer to some trails by name and others by descriptive terms.
In the US, for the sort of situation where you drive to a trailhead and there’s a blazed hiking trail that loops around the forest back to the parking lot, and the trail really serves no other purpose, would you still consider a route relation appropriate (even if it only has one member) or would most appers consider that unnecessary?
I saw a related exchange on the waymarkedtrails issue tracker: someone suggested that the map could show paths with the trailblazed tag, even if there isn’t a route relation, because otherwise people were mapping route relations “for the renderer”, and the response was (paraphrasing) that they should absolutely be mapping route relations and if the community disagreed that was to be discussed on the forum and documented on the wiki before a change would be considered.
I’ve seen quite a few named trails in North America without route relations, and I’m not sure if that’s because mappers generally agree they’re unnecessary, or if it’s more that no one’s got round to creating them yet.
Seems likely. There certainly are businessesborrowing the AT name. That said, this particular street just looks like a typical mix up from our orange feline friend .
I don’t know if it’s appropriate or not, but it happens all the time. I’ve done it myself since it seems to be common practice. I just don’t want the presence of such a route relation used as justification for deleting the name off the way(s). With some OSM based trail maps pulling info only from relations and others only pulling from ways, trails basically have to be dual mapped like this if they are to show up on all the different maps. If using a route relation for a minor hiking loop like this were deemed inappropriate, then the criteria for where a route relation is appropriate in the US would become quite vauge. As @ZeLonewolf said above, “US English vernacular draws no distinction between hiking trails that are 1 mile long versus ones that are thousands of miles long”. They are both just called hiking trails.
The name of a way and the existance of a route-relation are simply two pair of shoes. Adding such route is as mandatory as anything else in OSM. Though adding such route-relation would be the global best practice.
If a way has a name, that name should be tagged in name of that way. If there is a hiking, biking,… route using that way, then in OSM this route is added as route-relation. If the route has a name, that name is tagged in name of that relation. The two names might be same or might be different.
The North South Trail is a nearly 80-mile long trail that runs the length of the Rhode Island / Connecticut border, mostly on the Rhode Island side. I’ve personally surveyed the entire length of it while I was bored during COVID.
For a brief stretch, the NST follows US 6 in Foster, Rhode Island. In the snap below, you can barely make out the blue blaze painted on the telephone pole on the lower-right corner of the image.
Much further south at this location, the NST passes over the Ben Utter Trail, which is one of the named and blazed trails in Rhode Island’s Arcadia Management Area.
I’ve modeled the NST as a hiking route relation and the Ben Utter Trail just as a set of ways with a common name. Why is NST a “route” but Ben Utter Trail isn’t? Well, like Potter Stewart, “I know it when I see it.”
New rule: OSM should have a route relation for each street by name.
Sounds extreme, right? Some folks thought so about the per-street “route” relations in Australia that were created to allow Wikimedia Maps to highlight them on a locator map. But this is clearly analogous to the route relations that many mappers have created to represent trails by name, presumably for the sake of a conveniently highlighted and detailed presentation on Waymarked Trails or OpenCycleMap, semantics be darned.
At least this was my motivation when I created route relations for local trails spanning 2½ miles (4.2 km), 4¾ miles (7.8 km), and 78 miles (125 km) back in 2011, after seeing that others had done the same. Whatever the developer thinks, I definitely was mapping for their renderer, and I don’t think I’m alone. No one should be removing name=* from these trails’ individual ways, because the relations are merely compatibility shims that technically shouldn’t exist.
This would be 100% consistent with the “one feature, one object” rule, provided that attributes which apply to “the whole street”, e.g. name, only appeared on the street relation.
This discussion has been very interesting to follow. Regarding the original post, I certainly think that short trails should preserve name= on the ways. Relations are fine if some mapper really wants to, and might even be best practice, but are not required for such short routes and definitely don’t replace names on the ways.
But to continue digressing toward the broader name vs relation issues, I’d like to put forward an example near me that’s been the subject of some slow-motion edit wars to help with this:
The Backbone Trail is a regionally, but I don’t think nationally, well-known 70 mile long trail that traverses the ridge of the Santa Monica Mountains in Southern California (network=rwn). Along its route, it uses some trails, some wider, but unpaved, fire roads, and brief stretches of paved road. The naming in OSM can be sorted into a few broad categories:
Some portions follow another named way which clearly has a separate name, so name does not contain “Backbone Trail”. This is most obvious when the trail follows a major road for a brief portion: this way is clearly called Malibu Canyon Road despite carrying the Backbone Trail.
Some portions are only referred to, in speaking and by signage/maps, as “the Backbone Trail”. These are simply name=Backbone Trail, like this way.
Some portions are part of the Backbone Trail, but also have another identity. These are more murky, and their tagging has gone back and forth. Take for example this way. It seems like it has a separate name than Backbone Trail, Temescal Ridge Trail, but just happens to carry the Backbone Trail for a portion. You can tell because the name continues to the south when the Backbone Trail branches off. This is what it looks like on a map at the Hub Junction, at the north end of the way:
On this map, the Backbone Trail is just indicated by the red and yellow blaze along named trails it follows. I think this way should have name=Temescal Ridge Trail, but you can see the OSM name has gone through a few different values over the last few years, and is currently name=Backbone Trail - Temescal Ridge Fire Road, which seems like tagging for the relation-naive renderer.
That one seems fairly cut and dried, but there are more complicated locations. Take the Etz Meloy Motorway, currently tagged name=Etz Meloy Motorway (Backbone Trail) (aside: sometimes fire roads, usually tagged highway=track, are called ‘motorways’ in Southern California, which is quite the OSM oxymoron). This seems like the same deal as the Temescal Ridge Trail above, but look at the guide sign along it!
Compare especially to the southeastern portion on this map, which was my second example above. That part is clearly named “Backbone Trail” on the map and also carries the Backbone Trail, whereas the central section has its own name. But here are the signs on either side of “Sandstone Peak Trail”:
This looks to me a lot more like the trail is named the Backbone Trail, with Sandstone Peak as a destination. That’s why I settled on tagging it name=Backbone Trail + alt_name=Sandstone Peak Trail, with an explanatory note.
This ended up being long winded, probably because it’s been bothering me for a while. But I guess the summary is that on many US trails, the division between a route and a named trail is pretty ambiguous and hard to pin down. I think favoring the most local possible name as the best value for name is probably a good rule of thumb, but there will certainly be weird edge cases abounding, and local knowledge will be key. I think having hyphenated names or other separators is not to be encouraged unless it’s really clearly signed or referred to as such on the ground. That is what route relations are for, although it has the unfortunate side effect of hiding the route on naive renderers.
I’m slowly building a hiking map for Canada/US. This has been a fascinating thread to follow.
As a mapper, I’m focused on a single object at a time. When locals would call the thing I’m standing on “Trail X”, it feels right to me to duplicate the name onto the way even in the presence of a containing relation also named “Trail X”. My understanding (prior to this thread!) was that this was the consensus in Canada/US trail mapping.
As a consumer, I’m trying to unify locale-specific mapping norms, data coverage problems and data quality issues. I’ll do whatever I can to get something to show up. You could maybe argue that it’s nice to duplicate the name onto the way so that it lures the newbie in to OSM with a seductively simple seeming data model. I’d argue this isn’t tagging for the renderer, it’s tagging for a lower barrier to entry. Then, by the time the newbie understands that relations exist, it’s too late, and sunk cost fallacy has set in. (I speak from experience here. )
To me, this is a pretty good example, why trails should have a roote-relation. One way can have multiple routes. In your sample, there are two trails, but could be more. You ending up with a similar situation as multilingual names. To me your descission is rather random. I believe the majority of hikers just doing the Sandstone Peak Trail and would never talking about, they hiked a part of Backbone Trail. Where would you put the name of a third trail?
Secondly, as a data processor now it’s pretty hard to highlight one of the trails or offer as gpx-download…
How does this differ from the situation where a a street is renamed after someone famous, but only for one block, and both names are posted on different kinds of signs? We could model it as concurrent street relations, or as the collection of signs that I mapped, but name and alt_name seem like a decent solution for anyone who doesn’t want to overthink it.
alt_name can be a semicolon-delimited list too. And loc_name and reg_name are also possibilities.
To me your descission is rather random. I believe the majority of hikers just doing the Sandstone Peak Trail and would never talking about, they hiked a part of Backbone Trail.
I can see why you might think that, but that’s the problem with trying to decide these things without local knowledge. People definitely would say they hiked part of the Backbone Trail here, in order to go to Sandstone Peak. For example, here’s a couple of hiking guides for Sandstone Peak, as people usually make a loop out of it: Sandstone Peak Trail | Malibu | Hikespeak.com, Hike Sandstone Peak on the Mishe Mokwa Trail - HikingGuy.com. Both of these sites are written by locals. A quote from each:
To reach Sandstone Peak, continue on the Backbone Trail, which curves southward and then east.
And here’s the sign from that junction. We’re heading up the Backbone Trail for 0.9 miles to Sandstone Peak.
Seems like that’s the name of the trail! In fact, I couldn’t find any evidence on the ground that there is a Sandstone Peak Trail, except for the spur to the parking lot: all the other signs say Backbone Trail. Perhaps this is a cultural divide: Americans in a variety of contexts would say they took a portion of a long-distance trail if that was its only identity.
Of course. However, this is the US forum, where the distinction in the map is not obvious because we don’t really have language to distinguish it in our local vernacular. I’m sure there’s clear bright distinctions in other languages, locales, and systems of signing trails.
No, there isn’t: An edit of mine of the sac_scale documentation where I mentioned the term “alpine route” as it is used here – the meaning of: Do not expect a way there, but certainly, the terrain is passable on foot – to spell out, what this key is currently applied to – was reverted by another local mapper with the reasoning: The key sac_scale is documented to not apply to routes (in the OSM sense.)
Maybe it is less about language, rather how deep entrenched in OSM-Speak somebody is?
To summarise the replies to my question about creating route relations for short circular hiking trails, they ranged from “I create relations for them all the time” and “it’s best practice even if not everyone does it” to “you have do it if you want them to show on certain maps” and “I don’t always do it” (Ben Utter Trail) and “we really only create them for compatibility with renderers and they technically shouldn’t exist” (Sharon Woods Park Trail). No clear consensus then, like so often in OSM! Clearly renderers play a role in the motivation to map them, but views differ as to whether that’s reason enough.
If this is the current Overton window, then in terms of the original question, aren’t these two sides of the same coin?
Every trail should get a route relation. The presence of a route relation doesn’t say anything in particular about whether pathways are named. A basic park loop trail can have the same name on the pathway as it does on the route relation.
Some trails shouldn’t have route relations, but we create them anyways for certain renderers. The presence of a route relation doesn’t say anything in particular about whether pathways are named. A basic park loop trail can have the same name on the pathway as it does on the route relation.
I try to put in tagging to allow blazing information to be usefully rendered on hiking.waymarkedtrails.org. Presenting blazing information graphically is very challenging and hiking.waymarkedtrails.org does a better job than any other publicly available site that I have seen. You have to put the trail sections that have the same blazing into one route relation with osmc:symbol tagging. You can see how tagging gets rendered using a little window at Waymarked Trails - OSMCSymbol list . Mashin routinely changes my tagging to tagging that doesn’t reveal the sub-blaze. For instance, see Relation History: 11216247 | OpenStreetMap .
.
Though adding such route-relation would be the global best practice.
)