Hiking route network tagging

[Minh_Nguyen (Minh Nguyễn)]

@Peter_Elderson

@Minh_Nguyen

“Roles for recreational route relations” suggests creating a superrelation to hold the route and any related special routes. Some U.S. mappers occasionally make these superrelations for U.S. Routes (which are highway routes), thinking they might be useful, but we delete them because they’re basically categories and a bit of a maintenance headache.

This suggestion is for a route with one overall name and overall ref, including all side branches, shortcuts, variants etc. Not for the route collection of one provider/operator/administration, which they usually call their ‘network’.

This tangent was mainly about bike route networks, which are slightly off-topic here. But to address this point: the difference between a Route 25 and a Route 25 Alternate and a Route 525 is not a network within a network. In the U.S., we call them special routes and auxiliary routes; the collection of the main route and its special routes and auxiliary routes forms neither a coherent route nor a coherent network. It’s just a collection of numerically related routes within the network’s established numbering pattern.

That said, due to the potential for error by data consumers that don’t recognize modifier=*, the U.S. community has taken to also jamming this information into network=*, forming a sort of “subnetwork”, such as network=US:NY:Alternate. This doesn’t mean the routes are part of a distinct network from US:NY, but we figure that any data consumer who cares will know what to do with these values anyways.

Sometimes mappers have attempted to fashion superrelations out of these related routes because they mistakenly thought relations work like an encyclopedia article’s “See also” section, or because they aren’t familiar enough with the network to know that these modifiers or route number suffixes indicate distinct routes.

While the real-world concept of special routes is currently limited to highway and cycling routes, I suppose nothing is stopping a trail operator from extending this system to hiking routes at some point in the future, since trail users would likely be familiar with it from other modes of transportation.

@Peter_Elderson

Some mappers have voiced the idea to record information that is currently present in all the routes belonging to a particular network, only in a parent network relation. Such as operator data, or a shield description common to all the routes in this network. Data users could then in theory retrieve this common information from the parent network relation. I don’t see this as a viable way forward in the OSM ecosystem. (Every time I say such a thing somebody is bound to prove me wrong…)

The idea is alluring to computer scientist types who like database design, but less alluring to computer scientist types who like database usage.

From what I’ve seen so far, countries in East Asia have historically relied heavily on network relations at the expense of indicating this information on individual routes. Inevitably, mappers saw those network relations and began fashioning fantastically elaborate superrelation structures five levels deep, so that nowadays there isn’t a single numbered road in all of South Korea that isn’t indirectly part of a single monster of a category relation, while the bottommost route relations contain no indication of the network whatsoever.

If there is a data consumer out there that does anything with network relations, it’s probably only as part of a hard-coded special case that could be reimplemented more effectively as a simple tag comparison.