Ahh you beat me too it :-D

See list of discussions here:
osm.wiki/WikiProject_Waterways/River_modernization#References

Either footway or pedestrian areas would be a good fit here.

In OpenStreetMap we add correct data, and we do not map for specific apps or data consumers. If an app you are developing is crashing, that's a problem with your app, not with OpenStreetMap.

No worries, I've already made the correction. Just wanted to make you aware because I don't think the editor gives you any warning when the role is missing.

Hello, this item broke the boundary for Plandome heights. Each member of a boundary polygon needs an "inner" or "outer" role.

Hey, sorry got distracted and forgot to respond.

On ways that are part of a route, the ref tag contains both network and route number information packed into a single tag. In the US, we might do something like ref=I-80 for Interstate 80 or ref=I-80;I-90 for places where a road is concurrent with both Interstates 80 and 90. The "I" of course refers to the "Interstate" network that the roads are a part of.

When modeling routes as relations, however, the network tag is used to hold network information, so it doesn't need to be replicated on the relation. So you'd have network=US:I + ref=80 for Interstate for example. This allows, for example, highway shield renderers to display route numbers on highway shields by directly reading the ref tag and eliminates the need to extract out the route number from the network tag.

The standard tile layer does not consume route relations, so the compacted ref tags (e.g. ref=I-80) is what will get displayed on the map. However, relation-aware renderers are able to parse the separate network/ref components on the relation. That's the reason for the different tagging style for ways versus their parent relation.

See https://zelonewolf.github.io/openstreetmap-americana for an example of a relation-aware shield renderer. At some point I would like to add support for Mexico's highways as well, once we can sort out the tagging and make it consistent nationwide.

@Fred What source are you using to determine the value of place tags?

Thanks for the cleanup! The old borders had a lot of stuff glued to them and I got mired in edit conflicts.

Sorry, I accidentally conflated two uploads in JOSM. Did not intend for the BBOX to be this big.

Okay, I've got Triana and Huntsville boundaries re-imported from TIGER/2021. It would be great if you could double-check to see if they show what you expect to see.

Triana boundary is now broken, was valid as of 3/11. Probably impacted by https://github.com/openstreetmap/iD/issues/8286

What was the issue with the boundary?

This isn't a rule specific to the US, though of course capital/territory relationships will be quite different from country to country. In any case, I would expect that any contributor working in a country other than their own to have the responsibility of understanding what the local conventions are.

Typo... meant "admin_centre" in comment above.

To elaborate, simply assigning the node associated with the most prominent built-up area of a city or town the admin_label role is not good geodata. admin_label specifically represents a capital/territory relationship.

Yes, it was discussed on the tagging list, most recently in Oct 2021.

A village would not typically be the "capital" of a city or town.

There also appears to be an unattached place node for Jenks:
node/151731482

admin_centre is only used for administrative centers such as capitals and county seats. Label is used for holding the ordinary place node associated with a boundary. Typically entities below county wouldn't have an admin_centre role.

Harassment sock puppet account Shipu Innu documented at osm.wiki/User:ZeLonewolf/Sockpuppets

I could use a hand untangling this MEX 1 / BCS 1 routes as they're mixed up in the changeset where I updated the federal highway 1 route.