The reason for the disagreement on display here, is that mappers working in Louisiana have not yet formed a consensus on how highway classifications should be applied, consistent with:

osm.wiki/United_States/2021_Highway_Classification_Guidance

Both txemt and 1T_money (and other locals) have been involved in discussions on Slack in #local-louisiana to hash out classification guidance for Louisiana. As part of these discussions, A Flappy Civic and txemt have collaborated on the following draft (according to the link above) guideline:

osm.wiki/Louisiana/Highway_Classification

The Slack discussions have stalled, largely over disagreements about what role FHA functional classifications should have in determining highway classification values. Thus, we are in a situation where the mappers involved have (a) discussed and are intimately aware of the issue and (b) have not come to an agreement on how to tag.

Given this state of affairs, unilateral edits to change highway classification, particularly by the mappers which have been in active discussions over the issue, are tantamount to edit warring. Agreements on how to classify highways should be made through discussion and consensus in community fora (Slack, mailing list, Discourse, wiki talk page, etc), and NOT via unilateral edits to the map.

Additionally, this edit and others like it have vague descriptions like "updated tags". Given the high level of attention to US highway classification tagging in the US (thousands of Slack messages, multiple email threads, several presentations at State of the Map US), such vague descriptions may give others the impression that the author may be trying to hide classification changes amongst more minor edits. It would be better to note the source and rationale for such changes.

In short, I would encourage the local community of mappers to continue forging ahead on establishing agreements on how to classify roads, and avoid making classification changes which are known to be controversial.

Hi, can you tell me what the source is for these street names? I'm sure they're not visible on Bing Maps ;)

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