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?

Looking forward to seeing your alternatives. My comments around the EST cycling relation (osm.org/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: osm.wiki/Key: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.

Hey scetron, this actually isn't the best practice to be adding landuse tags to park boundaries in order to make it render nicely. This is called "mapping for the renderer", and it's generally discouraged because it may conflict with true data. There's several portions of this state park that includes sections of the Hudson River, which most certainly are not wooded areas. Because of this, I'm going to remove the tag.

Fahnstock Park may look like it has a natural=wood tag on it, but it actually has a separate feature that was drawn overtop of it with the natural=wood tag. This also isn't the best practice because it makes it hard to edit in the future if park boundaries change or sections of forest are clear cut or burned. I would recommend you use Storm King State Park or Black Rock Forest nearby as examples of some of the work I did to add landuse data without conflicting with park boundaries. Happy mapping!

Some of my favorite spots to go hiking! I'm finding new trails there all of the time. But sorry to hear your visit was under those circumstances.

Thanks for the input and hard work you put into cleaning up all of the admin boundaries!

No kidding... appreciate the very detailed explanation. As you suspected, my confusion was around the place nodes and when it is appropriate to use place=city/town/village/etc. vs. place=municipality. I believe I'm understanding correctly now that place=municipality + not:place=town is included to ensure the admin boundary (but NOT the place node) renders, and I understand cases like Newburgh where a place node for the town would be redundant and not represent the center of a settlement.

My confusion was more directed towards instances like Blooming Grove (place=town) and Cornwall (place=municipality). Both towns have villages within their boundaries with distinct names. And for locals in that region, the name "Cornwall" is typically used for the region bound by Firthcliffe, whereas "Firthcliffe" is very rarely spoken. Based around the your outline, I would've tagged Cornwall with place=town, Blooming Grove as place=municipality (no defined settlement where the node is placed), and Firthcliffe as maybe place=locality (still found on some old signage, but rarely used these days). Any reservations with this proposal?

Just curious - what distinguishes these places (Cornwall, Newburgh, etc.) as townships and neighboring places (New Windsor, Blooming Grove, etc.) as towns? Still adapting from PA to NY local government, but seems like the two terms are used synonymously and they could be consolidated.

This logic may hold true for much larger regions of low density population (e.g. Alaska), even then I think it's questionable. For Pennsylvania and surrounding states, Indiana would be considered on par with most small towns. Seems like most other mappers would agree with the population being over 20,000 on 95% of place=city osm.wiki/Tag:place=city?uselang=en#place=city_vs_place=town