This seems reasonable to me
1 Like
I don’t recall a USFS road sign that shows a prefix, but I have run across some trail signs that seem to. This may not be an issue for this thread but the OCD part of my personality would like USFS road and trail tagging to follow a similar scheme.
1 Like
What about:
name=Middle March Canyon
highway=track
destination=Middle March Canyon
ref=227
It is actually a foot and horse trail rather than a track. At least at the point I took the photo.
My point of interest is simply that it would be nice if the scheme for tagging or creating routes for USFS ways was consistent between roads and trails.
We currently use ref=FR ## & ref=CR ## . Sometimes folks use FS, but either way it distinguishes a county road, from a USFS road.
1 Like
I’m nodding my head here.
I consider it perfectly valid to map these minor forest roads either with or without route relations depending on mapper preference and the particular situation being mapped. Having consistent tagging regardless of data type will be simpler for both mappers and data consumers.
I think this is a noble goal but out of scope for this particular proposal. I wish I had a better solution to this, but I don’t. The majority of software that uses ref=* on ways is agnostic of what network the ref belongs to, which necessitates encoding that sort of information in the ref itself in countries like the US.
I think there’s some confusion after reading some of the comments.
Is this proposal about tagging the highways themselves or the relations (route relations) that could be built containing the highways?
Historically, Australia was the one region that commonly tagged network on individual ways to express distinctions between their route networks. But they migrated network to route relations last year.
As I understand it, the rationale behind ref:colour is that Spanish shield colors are idiosyncratic and only standardized on a per-route basis. There’s no special meaning behind the colors, but they’re still important for wayfinding. It’s similar to how public transportation routes are often color-coded, except that the color doesn’t influence the route’s name.
By contrast, it sounds like the horizontal or vertical orientation of these forest routes corresponds to a route classification of some sort. It’s part of a system, so it should be encoded as part of network.
The proposal is mostly about changing the tags for route relations, but there’s a lingering disagreement about whether to also change the format of the ref tag on ways.
Ideally, way refs should reflect how people write the road/route’s number symbolically in plain-text situations in the real world. For practical purposes, some prefix is usually associated with the number to identify the kind of road/route, unless the number already has a recognizable prefix built in (such as in California county route numbers, which include a zone letter). Omitting the prefix means it’s proper to say, “Turn onto 124 and follow it until you get to 22.” But if there’s a correct alternative that includes a prefix, such as “FH 124”, then that would be preferable in my opinion.
If the secondary network requires graphical shields per se, as opposed to some other plain representation of the number, then that would be an argument for using route relations, inconvenient as they may be.
While I may be missing context as I say this, I frequently find using route relations (and other data which are truly “better expressed” as relations, like type=site relations) to be more convenient, not less.
I very much like and agree with “(if a or some) route(s) correspond(s) to a route classification of some sort…it’s part of a system, so it (they) should be encoded as part of network.” Yes!
Refs, routes, relations, networks…sometimes what is needed is to slow down and think about how these pieces logically fit together. Then, we can logically fit them together. (They certainly do so in complex ways, to accurately reflect a particular country’s networks, for example, or to support software to draw a shield). True, it can and does take some discussion to get there — often on multiple fronts as it happens. Please realize that at least part of the difficulty in doing so is not only getting the tagging / scheme right, but getting the concepts that those taggings / schemes encode right, too. And that can be a bigger, call it a harder-to-do task.
In the end, as long as if what we say (tag) encodes what we mean (not often talked about per se), we’re doing fine. Then, “we mean what we say.” It takes understanding both quite well to do this well.
Kudos to those willing to take the time to sweat such details.
1 Like
I think they are consistent within a province, but not across provinces (they certainly are in Extremadura, the only one I’ve done much driving). Most maps, both road and state topos (sometimes provincial as in Catalonia) use these colours, and they are prominent on road signs.
OK, that wasn’t the impression I got from these tables, but the English Wikipedia has been known to have inaccuracies and wishful thinking about shields in other instances. In any case, I don’t see much of a need to follow the ref:colour precedent here.
This seems like it’s taking the long way around just adding these to the vertically-signed roads:
motor_vehicle=discouraged
ohv=designated
As for the networks…I’m against deprecating the forest-level representation. The forest highway/road systems in Mount Hood National Forest and Jefferson National Forest, despite forming contiguous territories, are two distinct networks. And both are distinct from Angeles National Forest. And all three use different numbering schemes.
I think a lot of the folks who are posting in support of flattening forest network tagging are unaware that the Forest Service doesn’t maintain one, national, road network, but rather one network for every national forest.
1 Like
Separate from this thread, one of the reasons for the introduction of the “relation” primative around the time I got started with this project back ~15 years, was to move tagging of routes off the member ways but onto an object distinct to the route.
So, it’s less duplicative but hand-holding old software that hasn’t been updated in more than a decade to handle routes. Adding ref=* to ways to indicate routes is deprecated in favor of relations and it’s beyond time to kill the dinosaur.
2 Likes
The issue is that these are legal access tags. What distinguishes the vertically-signed roads is more of an expected appropriateness of infrastructure and maintenance condition rather than a legal access distinction.
2 Likes
It seems that many folks consider all forests service roads to be routes. I don’t share this view. I consider the more important forest highways using these signs to be routes:
The less important forest roads using these signs, I just consider numbered roads:
I don’t see anything wrong with mapping them as route relations for anyone who wishes to do so, but a requirement that they must be mapped as route relations seems misguided to me. The distinction between routes and roads/streets is admittedly somewhat arbitrary, but as long as that distinction exists in OSM, I see no reason why national forest roads should be different than the rest of the road network.
It strikes me that the status quo where way refs get a prefix and relation refs don’t could be improved by introducting a new ref tag. Something like this:
network=US:USFS:secondary
network:ref=3125
ref=FR 3125
This leaves the plain ref tag as the fully qualified reference value that can be used unambiguously in plain text while also providing richer data in the network/network:ref pair for identifying the road in a more nuanced way such as drawing a shield, or expanding to a full text name like “Forest Road 3125”. A scheme like this would relieve us from having to constantly explain to people why ref values are different on way vs relations.
That was the intended outcome, yes, since the vertical slats are a shorthand for “we’re not saying that you can’t take a car here, but we wouldn’t; this is primarily suited for offroad vehicles”. Which is the two tags I suggested.
They’re not part of a different network, it only conveys accessibility.
1 Like
Ideally, refs on ways shouldn’t be a thing in the first place, since that tag’s existence in the first place was the primary motivating factor for relations to come into existence.
1 Like
I’m not sure this is really bringing any information to the table compared to the existing method? Maybe instead of ref for that, something like network:ref=FR 3125 for that? Either way it kinda seems like this is dancing around tagging refs on ways to describe routes, which is something that we’ve been trying to kill off for a decade and a half now.