If I understand correctly, Oklahoma’s border can remain at its current size and overlap the reservation boundaries, the same way that Arizona, New Mexico, Colorado, and Utah include areas that are formally part of the Navajo Nation and Hopi Reservation.

Thank you for taking care of this update. It’s very timely considering today’s Supreme Court ruling in McGirt v. Oklahoma. https://github.com/gravitystorm/openstreetmap-carto/pull/4113 was unfortunate timing, but at least we’ll have something to show upfront to people who are now interested in the reservation boundaries.

I’m so glad to see the jagged to-do boundary line I drew around Peninsula a decade ago is no more. 😀

There’s already a separate area for the “Defund the Police” addition to the south, which makes it easier to tag the different artist and subject information about each part.

Not yet, the yellow “Black Lives Matter” was composited in for the time being while waiting for updated satellite imagery. Otherwise the muralists painted over the hoods of some parked cars. 😬

They were separate because of a turn lane at the southern end. I’ve reverted this change in changeset 86284396.

Whoops, I accidentally copied the GNIS feature ID from way 161269489 nearby. Thanks for catching that!

There’s another “Charleston Drive” a couple blocks to the west, off of Ames Boulevard – is that Manor Heights Drive, if this is is Charleston Drive?

Thanks for catching that copy-pasta; fixed in changeset 79904988.

“Findlay Post Office” is the post office’s name in general, not just its local nickname. This goes for almost any USPS post office. After you upgrade a post office’s brand tags in iD, you can override the name tag in the raw tag editor. A search engine should probably know how to look at the brand tag at this point, but if you want to ensure “United States Post Office” remains a searchable term, you could put it in alt_name.

Fixed the spelling of “Phõ Láng Hạ” to “Phố Láng Hạ” in changeset 79716166. (“Phố” means an urban street.)

Hi, it looks like this changeset introduces some flag:organisation:wikidata tags. I think it’s a great idea to link flags to the entities they represent. However, I’ve been using subject:wikidata for a similar purpose; maybe that would work better, since the flag:type can be something else like governmental or municipal?

Yes, thanks for spotting that mistake. Fixed in changeset 79308549.

Not sure what happened here, but the building ended up being an odd multipolygon relation and the tags of three POIs were mushed together onto the relation. If you see a name that contains semicolons after merging, most likely that means something went wrong and you should undo the change. If this keeps happening unexpectedly, please report a bug about iD. Thanks!

What’s the reason for moving Amtrak to the front of the list? Is there a convention that the national service should be listed first? Previously, Caltrain had been listed first at the two stations it shares with Amtrak. Signs at these stations and roads leading to them always place Caltrain first, with Amtrak sometimes coming last:

https://commons.wikimedia.org/wiki/File:Santa_Clara_Transit_Center_Brokaw_Road_pillar.jpg
https://commons.wikimedia.org/wiki/File:San_José_Diridon_0943_03.JPG
https://openstreetcam.org/details/1256063/559

For what it’s worth, I also use en dashes in situations where a name would properly include an en dash in running text. It doesn’t particularly matter whether the sign or the agency’s house style applies proper punctuation. Longer dashes and curly quotes are usually excluded from standard typefaces that sign shops use, but we aren’t making signs.

To the extent that OSM makes a distinction between en dashes and hyphens, renderers can display these en dashes where appropriate or perhaps replace them if the font lacks an en dash. But if OSM only uses hyphens, then there’s no way for a renderer to reliably insert en dashes even if desired, other than using Wikidata labels instead of OSM names.

Any search engine (as opposed to literal string comparisons in Overpass and taginfo) needs to perform some amount of normalization to work properly. A basic step is stripping all punctuation when indexing places and from input. Otherwise, the search engine would be fooled by searching for “Washington, DC” instead of “Washington, D.C.” (Search engines also need to perform case-folding and diacritic-folding at a minimum.)

Anyways, if you discuss this issue in the talk-us mailing list or OSMUS Slack before making the change again, these would be some of the arguments in support that could help make the change stick next time around.

osm.wiki/Tag:railway%3Dhalt primarily refers to size, the presence of a platform, and whether trains stop always or only by request. If you had instead changed these nodes to railway=halt on the basis that there’s no shelter or station building, that would’ve better fit the documentation and thus data consumers’ expectations.

The rule about the presence of switches is specifically for German-speaking countries. Back in 2015, a mapper edited the page to apply this definition to the whole world, seemingly without discussion, but that change was reverted several months later. It’s possible that some of the switch-based tagging you’ve seen was from that time period. osm.wiki/w/index.php?title=Tag:railway%3Dhalt&action=history

For this rule to be adopted in North America as well, it would need to be discussed on talk-us or at least OSMUS Slack. This changeset comment thread isn’t enough because the switchover to railway=halt happened across multiple changesets. Together, they affected roughly 60% of all Amtrak stations nationwide, but only Amtrak stations, so now the map is inconsistent within the U.S. I’m not saying you necessarily have to go through the whole mechanical edit process, since you went through the trouble of manually inspecting each stop. But data consumers and other mappers should be kept in the loop about the changes taking place.

By the way, you can map the switches themselves as railway=switch nodes. That way we won’t lose information about switches no matter how the discussion turns out. I’m unaware of a special tag for distinguishing flag stops, since that was the original meaning of railway=halt.

What’s the rationale for making so many stations into undifferentiated halts, other than a rule on the wiki that was meant for very different countries? The distinction between fixed stops and flag stops is common among American passenger rail systems (and bus and light rail systems for that matter).

Amtrak is unique in that they don’t have to remind passengers to flag down trains at flag stops, since the reservation system does it for them electronically. But try explaining to a layperson that Cincinnati’s grand terminal is but a halt because there are no switches visible in aerial imagery. And consider what impact the German rule would have on other rail systems: a distinction based on the presence of switches, which is much more arcane than a flag stop rule that passengers get reminded about.

That definition isn’t generally used in the U.S. railway=halt is used for flag stops. Some unstaffed Amtrak stations are flag stops, but for instance the Oakland-Coliseum/Airport station (OAC) is a fixed stop, about as built up as most stations along commuter rail lines. An extreme example is Cincinnati Union Terminal (CIN), one of the largest station buildings in the country, now tagged as a halt because Amtrak replaced the ticket counter with a vending machine during a recent round of layoffs.

(What’s more, some tram systems as a rule only stop when flagged, but we’re still tagging all the stations as stations rather than tram stops, because Americans don’t expect rail passenger facilities to be as built up as in Europe.)

Note that some routers assume barrier=yes is access=yes, so you also need to add access=private or access=emergency if the general public isn’t allowed to cross the barrier.