This has been corrected. osm.org/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.

osm.org/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.

osm.org/node/11970836297
osm.org/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?