Sounds like a cool project! Creating the route manually in Komoot using a round trip with waypoints is probably the best free method. Strava used to be a great option as well before they pay-walled it. There should be plenty of tutorials online for how to do this (here's one: https://www.youtube.com/watch?v=0Kw-HcIOYQc), but long story short you not need to create the temporary relations as long as the trail ways exist in OSM.

Thanks for understanding. While I may not know your exact use case, I can share that Komoot does have the capability to plan a round trip with waypoints, and it’ll tell you the distance between each of the waypoints. I would recommend sticking to their desktop app sincs it’s a little more intuitive for adding waypoints and ordering them correctly. Best of luck!

Might I suggest Komoot or a similar routing app instead? OpenStreetMap is a data source for all users, and others might find the data with vague naming a bit confusing. Hiking routes in OSM are reserved for documented, official routes that hikers can easily follow through signage, or in this case perhaps NY State resources.

Hi - is there a more appropriate name for this relation besides "Hike"? If not, I would suggest leaving the name blank or removing the relation.

Hi rennur - this way: way/1463263289
appears to be a duplicate of: relation/175474
West Point is a census designated place/military reservation and not a city. Since the original boundary is more representative of West Point's boundaries, I'm going to delete the new way unless you have any opposition.

This has been corrected. changeset/166473416

Hi - can you please specify which area of the village you believe should be in Rye? I’m happy to adjust as necessary, but I would argue that reverting would put the map in a much worse state than simply revising the border as necessary. This was several months ago and there will likely be many conflicts with reverting, and if memory serves me correct, the Town of Mamaroneck boundary was excluding both the Maramoneck and Larchmont village boundaries prior to this change which is not correct.

No problem, happy to see others taking interest in mapping NPS and USFS public lands! And to comment on your note that you left on the NF relation - this is a bug with the rendering engine and not the relation itself. Unfortunately, it doesn't seem like there's been much movement to correct it: https://github.com/gravitystorm/openstreetmap-carto/issues/4198

An example of a rendering where Ozark-St. Francis (and other complex, "checkerboard" NF relations) is properly displayed: https://americanamap.org/#map=9.21/35.6946/-93.3143

Hi - this has been extensively discussed on multiple forums whether to map proclamation vs ownership boundaries of NFs. Ultimately it's a matter of opinion, but the majority seems to agree that it's misleading to map private inholdings as part of the NF since the USFS has no jurisdiction. The boundary is tagged as boundary=protected_area, and it would be incorrect to say that the entire proclamation boundary is protected, public land.

I've linked some resources on this topic below. If you strongly feel that this needs to be revisited, I would suggest starting a conversation on one of OSM's public forums where others can weigh in on it. Happy mapping!
osm.wiki/United_States/Public_lands/Forest_Service#Replace_proclamation_boundaries
https://community.openstreetmap.org/t/tagging-inholdings-private-land-in-us-national-forests/104346/4
osm.wiki/US_Forest_Service_Data#National_Forest_and_National_Grassland_Boundaries

To my knowledge, this trail has not yet been constructed and is still in its planning phase. I would suggest reverting this changeset or changing to access=no until construction is complete to avoid confusing unaware cyclists and pedestrians

I see what you're referring to on the redundant relations and agree. I didn't make any changes to the structure of the relation so I can't speak for which one is the correct one, but I trust your judgement.

As for the naming, my opinion is that "cycling" and "hiking" are descriptors that are not officially part of the name, and therefore do not belong in the name tag. route=hiking and route=cycling are already in present and function to differentiate. I would go so far as to say it's redundant to have separate hiking and cycling relations. Why not just have a single relation structure, all tagged with route=hiking;cyling? It would still render on both the hiking and cycling waymarkedtrails, and prevent users from accidentally adding members to the wrong relation should the trail be rerouted.

Of course, this is a much larger change that I would suggest discussing in the NY State slack channel at a minimum.

Again, please don't use the name=* key for descriptors. highway=cycleway and abandoned:highway=residential perfectly describe what you're seeing on the ground.

way/1274747417

I understand you may want this information to render on the map, but this is a bad practice that should be avoided. See: osm.wiki/Names#Good_practice
"The names should be restricted to the name of the item in question only and should not include additional information not contained in the official name such as categories, types, descriptions, addresses, refs, or notes."

Please stop using descriptors in the name=* key. Unless these dams are known as "rock dam" or "mill dam ruins" by signage, maps or local knowledge, then it's best to leave this key blank.

node/11970836297
node/11970836295

I wrote out my proposal in a few of my replies now, but I’ll try to describe in a little more detail:

1. Super relation (tier 1): name=Empire State Trail
2. Tier 2: name=Champlain Valley Trail; name=Erie Canalway Trail; name=Hudson Valley Greenway Trail
3. Tier 3: name=Erie Canalway Trail (Buffalo to Rochester); name= Erie Canalway Trail (Rochester to Syracuse); etc.
4. Tier 4: name=Erie Canalway Trail (Tonawanda to Amherst); name=Erie Canalway Trail (Amherst to Lockport); etc.

The existance of the 4th relation tier is a little overkill in my opinion… most national hiking networks stop at 2 tiers. But I’ll concede on that since it is segmented very nicely on the official website. Appreciate the patience and consideration as we try to come to an agreement.

I reviewed your recent changesets and there is still a lot of unnecessary information in the name key. Again, the name key is reserved for the actual name of the feature. Anything additional would be classified as mapping for the render and is highly discouraged. osm.wiki/Tagging_for_the_renderer

> Consistently using common codes EST, EC, HV and CV are analgous to using US, NY and CR for road numbers.

Sure, but these codes are not found on the name key for roads, so why should they be on the name key for hiking relations? For instance, name=New York State Thruway and ref=I 87.

> I have used these in the reference field and added them to the name, to assist with understanding.

OSM's objective is to map what is in the real world, not what we believe is the most appropriate naming convention to assist with understanding. Adding codes and descriptors to the name key is redundant, incorrect and in my opinion even more misleading. The WayMarked renderers are already very robust and will render the ref key over the route and only render the specified route type (hiking, cycling, etc). Is adding this information to the name key really going to assist in understanding what the route is actually named?

Looking forward to seeing your alternatives. My comments around the EST cycling relation (relation/11486089) were directed as an example of not using abbreviations in the name=* key. I would suggest reading over the key:name wiki for more clarification: name=*?uselang=en

Simply put, abbreviations do not belong under the name and the name should be representative of the real-world. There are other tags that can utilized for the information you are. Take the super relation for example, currently named "EST - H - an Empire State Trail hiking network":
1. "EST-H" can be conveyed via the ref=* key (although I would argue it should just be "EST" due to next argument...
2. "-H" and "hiking" is represented via route=hiking
3. "network" is represented via network=nwn
With these tags already in place, we're left with "Empire State Trail", which is what most individuals would commonly say to refer to this hiking network. Next level of relations could then simply be "Hudson Valley Greenway Trail", "Erie Canalway Trail" and "Champlain Valley Trail" - no need for any other descriptors in the name since it's implied they're part of the EST by being part of the super relation. The next two levels below are where I can see the need for some creative liberties. I think a concise way of doing could be as simple as "Erie Canalway Trail ({Point A} to {Point B}). Hopefully this explanation makes sense, otherwise would be happy to provide an example revision if you agree.

To ellaborate on this further - if I did a google search of “EST - H - ECa08”, do you think it would provide any relevant information about the Erie Canalway Trail or Empire State Trail outside of the OSM feature? I understand you may find the abbrevation format useful for your own purposes, but I strongly suspect a wider audience would not.

Yes, I’m well aware of WayMarkedTrails and use it regularly. Howver, I have not found any reference to this abbreviation system that you are using on the ground or on the official website. The name=* key is reserved for verifiable names, not abbreviated codes that were privately developed for an individual’s convenience. I am ok with the relation names following the format used on the Empire State Trail website or signage on the ground, but I am not satisfied with it’s current state and implore you to reconsider.

Hey there! Can you please advise on how you came up with the naming convention that you're using for the Empire State Trail and its subsections? I'm not finding these abbreviated references (e.g. EST - H - ECa08) on any of the official maps or websites. While I think there may be some room for creative naming on the child relations, they should be more aligned with the official names that are universally accepted by those who utilize the trail. For instance, the main super relation could simply by "Empire State Trail", followed by "Erie Canalway Trail", and then "Erie Canalway Trail (Buffalo to Rochester). Or we could just follow the system developed for the Empire State Trail cycling relations. Please let me know your thoughts. Cheers!

P.S. I used to make the same mistake several years ago... I was frustrated by it at first, but it began to make sense after I started importing state park boundaries myself.