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

Can you please explain your reasoning for changing Indiana to a city? Relative to other cities in Pennsylvania, Indiana has a very small population.

Please read over these wiki articles before making any more edits. While I'm sure the intent was not malicious, these edits and many like it do not align with best practices in the OSM community. Most notably, it is discouraged to not "map for the renderer", i.e. creating features or adding tags so the features will be visible.
osm.wiki/Good_practice
osm.wiki/Tagging_for_the_renderer

I did not add the access=no tag to this trail. Looks like the extent of my edits to it was adding a bridge which was clearly visible from aerial imagery, hence the v1 ways that were generated from splitting the original way.

I'd say if you've field surveyed this trail or have a reputable data source that indicates that the trail is public access, then you're welcome to correct the tag.

Hi scarapella, aplogies for taking awhile to reply and address this. I did some digging and you're correct - it is not a part of White Mtn NF. In the USFS dataset I was using for import, it for some reason shares the LOC_NM tag with the other parcels of the NF despite having no formal association. Thanks for catching this... already corrected.

Understood, but it's generally a good practice to keep it separated so that an edit to the land use does not affect the boundary, or vise versa. For example, I'm in the process of adding all inholdings to Daniel Boone NF, and some of them are within Clifty and Beaver Creek Wilderness. Updating the boundaries would also change the cover of landuse=forest. On a similar token, if a wildfire were to wipe out a large portion of forest in the wilderness area and require some land cover updates, a new mapper may inadvertently change the wilderness area boundary unaware of what it represents. The most common example I've seen is someone adding ponds or lakes as inner members of the forest relation, making them appear as private inholdings of the boundary. So please, try to avoid this going forward.

Please do not add land use tags to protected area relations. It should always be drawn as a separate feature since it's an oversimplification to call this entire wilderness area landuse = forest

Welcome to OSM! Did you intend to delete an entire National Forest off of the map? I can only assume this was an error and will be reverting this changeset. Before making any more edits, might be best read:osm.wiki/Beginners%27_guide

Please be more careful with your edits - seems like you accidentally deleted a portion of the Monongahela NF boundary which has caused it to no longer render! You also tagged this piece of the boundary as highway=path, which I can only assume is also an error since it overlaps several other paths. osm.org/way/716001847

I will be reverting this changeset in order to properly restore the boundary.

Martin, I disagree that mbeyerle's tag removal was misguided simply by the premise that sells:wine is a more specific tag. Would it be logical for users to replace generally standardized tagging schemes with keys or tags that they believe add specificity on the notion that it will provide end users with greater detail? By your logic, it would be acceptable to replace surface=gravel with surface=crushed_stone_#5 because that specifies the exact grade of gravel. How will the community ever reach harmonious agreement on tagging standards if we don't do small and harmless cleanups like the one in this edit, where the lesser used sells:wine key was replaced with one that implied that wine is sold based on established wiki definitions?

Hi Dufekin, you've made a lot of very questionable edits around the State College area that can be considered vandalism. Can you please explain why you've made a very large prison ground that covers forest and residential areas? Converted a wastewater plant into a park? Converting roads into a bus guideway? There's several more that make no sense. Please reply soon or I will take it upon myself to revert your edits.