I just noticed that the Appalachian Trail is no longer showing up at low and medium zoom levels on Waymarked Trails. I don’t have time to look into it right now, but does anyone know what happened? @quincylvania, it looks like you’ve been doing some some work on it recently. Guessing that has something to do with it?
To whomever is working on it, thank you. I had been active in OSM AT stewardship but have gotten away from it. One important thing we need is a standard naming of the sub-relations so the exposed name is not an internal tracking name for the relation.
1 Like
I believe the relevant issue is Support route classification in `network:type` as well as in `network` · Issue #16 · waymarkedtrails/waymarkedtrails-backend · GitHub, i.e. changes in the network values. As said in the issue, I’m not against adding support for the new tagging to waymarkedtrails but I believe this should be discussed first, preferably on an international level.
3 Likes
Related discussions:
Hi all, I indeed changed the Appalachian Trail and other National Scenic Trail relations from network=nwn to network=US:NST + network:type=nwn. This may have been a bit premature and broke some apps, but my intention was to “be bold” and spur some change. The network=xxx format has a number of issues discussed elsewhere that I’m happy to go into further.
1 Like
You’ve just hit the reason why it is complex to turn these discussions into concrete actions.
Got it. That makes sense why it disappeared 
. Yes probably a bit premature, but I agree that the network=xxx format is not great and a better way of classifying trails would be good. Seems like that’s going to need a wider discussion with the international community for any such change to happen though.
I see you’ve also decided to split up the overall AT route relation in more detail by the club that maintains each section. Before a few weeks ago the route had 14 sub-routes, now it has 30 and some are quite short. I can see the logic in this, but it seems a bit overly complex and leads to some awkward discontinuities. For example, the AMC section has a gap in it where the Randolph Mountain Club does maintenance. Maybe there’s no problem with this, but I can’t help wondering if it is really necessary.
As far as the AT sub-routes, 30 is sort of a lot but the Pacific Crest Trail has 29, and I’m not sure those are based on real-world subdivisions. Having a single long route is feasible but is troublesome for some tools, and some mappers only want to download a local segment. The state-by-state subdivisions are okay but break down when the trail keeps crossing the state border in NC/TN, plus they’re a bit arbitrary.
As far as I can tell the trail maintenance club jurisdictions are the primary real-world organizational structure of the AT. They don’t always correspond to an operator tag either, as some local park may “operate” an AT segment but have an agreement where the trail club can do certain activities to maintain it. And tying in with the OSM US Trails Stewardship Initiative, some of these trail clubs may want to maintain their GIS data in OSM and having these relations may help with that. Even if people don’t think these routes should be the primary subsections of the AT relation in OSM, it would be nice to keep them represented somehow.
1 Like
Oh, also each trail club has its own neat little shield logo. It might be fun to show these along the AT on a map like Americana or OpenTrailMap (assuming we get the right permissions).
1 Like
Could you provide some examples in the other thread about shields and blazes? I don’t think folks realize how many different kinds of symbols a given route can have that all matter simultaneously.
1 Like
@quincylvania I appreciate your stewardship of trails like this one! Regarding operations of trail segments by ‘Friends of [park name]’ organizations, a convention I’ve landed on with Maryland DNR is to set the owner='name of park/landowner' and operator='name of the friends organization'. This is a simplification because those agreements will vary depending on what has been established. I like the idea of setting up the sub-relations by local club jurisdiction and setting the owner to land owner but operator to the trail club.
Here’s an example trail in Maryland where the operator is the Friends of Patapsco Valley State Park. The Maryland Department of Natural Resources owns the land and performs some functions like 911, but the FPVSP designed, built and maintained the trail.
I like the approach of breaking it up by real-world subdivisions especially if there is real on the ground supporting evidence. It’s a bit awkward that some sections are quite long and others are quite short, but I guess that’s not really a problem. 30 members is not a large number compared to some of the mega relations out there.
A potential issue I see is that a number of these “sections” are actually two discontinuous sections maintained by the same club:
This means the sub routes can’t be sorted into one linear route for the whole AT. Maybe this is less of a problem than I’m imagining and data processing tools should be able to assemble it all together somehow. It doesn’t seem quite right for a linear route though. If this is a problem, there could be two sub-routes for each of these clubs–one for each continuous section.
OK, I had to take a deep dive into this and make a map to support these claims 
I set up a quick web app showing that NPS data in a more visually distinctive format that delineates the various trail club sections. There are indeed, quite a few small trail club sections:
An alternate to trail sections’ sub-relations could be doing it by “A.T. Region” of which there are fewer and the sections are contiguous.
edit: cleanup legend on regions
7 posts were merged into an existing topic: Hiking route network tagging
I have started an international discussion topic here: Hiking route network tagging
Circling back to this… I agree that it’s annoying to have noncontiguous relations when segmenting the AT by club. 30 is really too many subrelations to maintain, and I’d be more than happy to segment by the four regions, or even just have a single relation. However, I’d still like some way to model the club data.
I went ahead and added operator, operator:short, and operator:wikidata for the trail clubs to all the highway member ways of the AT relations. This is useful in itself, but doesn’t seem like a full replacement for the club relations. There are some complications, like how some of the ways are public roads or sidewalks that are really operated by a town or DOT. There is also the hiker ferry which is operated by a subcontractor, apparently through the ATC itself and not the local MATC.
Overall, operator is a little unsatisfying as a full replacement for the club relations. maintainer is in use but I’m not sure it would solve all the issues. Maybe it would make sense to make a new tag that indicates the “friends of” group that takes care of a trail?
“Friends” groups came up in discussion about what eventually became community_adopted=* and community_adopter=*.
I hope this isn’t too tangential, but there is a “Goldilocks” (sweet-spot: not too big, not too small) relation management scheme / size / scope (strategy, algorithm) which OSM continues to seek for gigantic relations. Too small (for each relation / sub-relation / component of the whole) and we have “30 is too many relations to manage.” (I might disagree with that particular number, going somewhat larger, but that’s me). Too large (thousands of elements in each relation) and we really do choke and painfully bog down our software tools.
As an editor of many huge relations (route relations of vast bicycle networks, route=railway and route=train relations, among others) stuffing over 2000 or 2500 elements into a single relation really does become unwieldy, even for “big iron” machines (fast, many cores, dozens and dozens of gigabytes of RAM…). I have seen others (especially in Europe) say they prefer relations to contain no more than “hundreds” (even the LOW hundreds) of contained elements. That also seems too extreme in the “smaller relation size” direction (to me, clearly others disagree).
As some say here, “state boundary” is somewhat arbitrary, but it is also useful and even appropriate, for example in the case of USBRs (national bicycle routes patched together state-by-state by state DOTs), “by state” is 100% correct and appropriate. Perhaps we can agree that for any particular (hiking, biking, rail…) network, a “set of rules” (which could start out as strategies and evolve into guidelines…) can emerge that achieves Goldilocks for that particular network. There are a number of considerations that might feed into this discussion.
And (back to what seems more on the main topic): if we’re going to make changes to network=*, and I mean ANY value of that key, VERY wide discussion must take place. Preferably first, before (structurally large) changes are made to our data (at literally the level of whole networks).
Thank you for reading.
Hey! I recently started creating hiking guides using Wikivoyage, and made this topic: Aligning OSM hiking sections with Wikivoyage - #5 by SomeoneElse.
Currently the route is described as it is most often described, state by state (combining 2 states where the trail crosses the state border often). The sections in OSM are split up by trail club, as mentioned here.
This causes some problems for me as well. I’d like to visualize the trail for each state, but this is not convenient if it’s split up more than that, see Pacific Crest Trail – Travel guide at Wikivoyage for an example of section maps (using the official PCT sections).