Yes, by all means!

You created version 1 of that relation...

Are you sure about County Road 25 1/2 in Weld Co, CO?

osm.org/relation/19320417

I can't find any evidence of this existing. There is a nearby county ROAD with this number on a different alignment.

Unfortunately there is no way to read the minds of users that take it upon themselves to conduct undiscussed imports that are at odds with community consensus. That is the reason for the import guidelines and the Automated Edits Code of Conduct.

osm.wiki/Import/Guidelines

Unfortunately, discussing things with the OSM community is more work than simply unilaterally uploading data. I totally understand if discussing imports in advance is too much of a burden and this causes you not to conduct future imports. Such is the nature of collaboration.

Hey Joe, can you jump on the discussion at https://community.openstreetmap.org/t/admin-level-for-michigan-wisconsin-minnesota-and-north-dakota/131136 ?

Ahh snap. If it's easier, we can do a revert and do.over

This change was reverted due to the presence of a posted no trespassing sign.

osm.org/changeset/167979764

Please join the discussion on these edits at https://community.openstreetmap.org/t/religious-administration-boundaries-in-the-united-states/131400

Unfortunately the bounding box treatment on undeleting nodes is not ideal

Oh huh, for that case, name:right and name:left are supposed to indicate what the name is on each side (relative to the direction of the way). Which of course, is also a colossal pain to do. Semi-colon delimiters in name tags throw a warning in JOSM because you're supposed to use the various ???_name tag variants to store alternate names. So I guess I'm not sure what properly belongs in the main name tag in this case, but :right and :left should be the proper way to do it. See osm.wiki/Key:name:left

Some data consumers can handle the semi-colon just fine:
https://americanamap.org/#map=18/43.500441/-96.587423

Some data consumers (notable the standard tile layer cannot:
osm.org/#map=18/43.500776/-96.588659

So this might be a good broader question to ask. I would be fine with putting back the semi-colons but I expect it will come up again because of the validator warnings.

At the moment, the Cody relation doesn't even have a name tag, which is why it came up on my list.

I haven't gone past the sign, but I think you could make an argument for either. It has attributes of either type. It's really narrow and looks like it goes to only one house. I'm not sure the distinction matters too much.

Hi Nick. Yes, there is a no trespassing sign, at least, on the Fishing Cove Road side. No, it is not a new sign. It was there when I surveyed it a year ago, and it was there a half hour ago when I went to check.

Here is the photo I took of it:
https://commons.wikimedia.org/wiki/File:No_trespassing_sign_lit_with_headlights.jpg

It was late in the day, so I apologize for the lighting. It is geo-tagged so you can see the exact location.

Given how prominent this sign is, I'm surprised you didn't notice it in your survey.

Thanks for a good laugh, 8 years later...

This edit is being discussed here:
https://community.openstreetmap.org/t/chicago-metropolitan-area-relation/131055

Please join the discussion.

Hi aduxas. I mapped what I hiked back in 2020, but that was five years ago! My GPS data is here:
https://www.strava.com/activities/3580163692

We attempted to follow the trail as best we could as it was marked on the ground at the time. However, the trail alignment has changed at times over the years, so I would not surprise me if it's different now.

RIGIS also has a trail layer here:
https://www.rigis.org/datasets/edc::north-south-trail/explore?location=41.926923%2C-71.754420%2C15.00

It looks like it is indeed showing a more northerly route along the pond. So if you've hiked this section and followed the signs, then by all means make the corrections!

I think that needs a community discussion that's worth opening a thread. There's several folks I can think of off the top of my head that ought to weigh in. Sub-municipal boundaries can be a controversial topic and I don't think there's a strong community consensus. Therefore I don't feel qualified to state a recommendation unilaterally!

The geometries were broken in various ways. Not in boundary relations, not connected to adjoining boundaries, and so forth. They are also not listed in Virginia's entry on osm.wiki/United_States_admin_level which suggests no community discussion occurred to add an admin level above 8. For these reasons I deemed them too broken to fix and deleted them.

Should be change to boundary=statistical + border_type=census_designated_place. This was after I curated the CDP list to match the census bureau.

Thank you!