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.

railway=halt 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.

There’s nothing inherently wrong with contributing in an area where you don’t live or haven’t visited lately. That’s called armchair editing and I’m guiltier of it than anyone in this thread.

Once you get comfortable enough with OSM, you should feel free to fix what needs fixing beyond your neck of the woods. We don’t have a ton of mappers who live in the Ozarks, for instance, but there’s plenty to map there anyways.

However, all editing requires due diligence. I spent this weekend massaging flagpole tags around the country, including here in Missouri. Since I had zero local knowledge of any of the flagpoles, it was incumbent on me to squint at every available imagery source – and also keep my hands off any perfectly correct, valid tag, even if I wouldn’t normally use it in my own mapping. Circumspection goes a long way toward avoiding conflicts.

The worst GNIS tags have already been deleted by bots that were subject to plenty of mailing list debate beforehand. The ones that remain are either genuinely useful or so benign as to not really register on anyone’s radar. If the gnis:feature_id tag’s existence were really a problem, it would’ve been deleted by now along with the GNIS node tags.

There’s no hard requirement that a mapper copy over all the GNIS tags when transforming a node into an area. But if someone goes through the trouble of doing so, they’ve gone beyond the minimum requirements and it won’t break the map or mislead anyone as far as I can tell.

If you disagree with the status quo on GNIS feature IDs and would like to see them removed systematically, you should take the idea to a broader audience, whether one of the mailing lists or chat groups. If this park was an exceptional case where the individual GNIS feature ID didn’t belong, a note=* or not:gnis:feature_id=* tag would make that clearer. I don’t see the point in removing the tag selectively or haphazardly.

changeset/78131764 adds wikidata=Q49497832 to the park as mentioned above. I found this QID at the bottom of <https://www.wikidata.org/wiki/Special:Search/2477746>. You can also search for the item by name using iD’s Wikidata field. Either way, you’d want to visit <https://www.wikidata.org/wiki/Q49497832> to be sure it’s the right Happy Rock Park.

* virtually all parks in GNIS, that is

The gnis:feature_id tag and its synonyms are also documented at <gnis:feature_id=*>. Unlike many other import tags, gnis:feature_id contains a stable external identifier. In that sense, it’s quite like a Wikidata QID, except that it’s the U.S. federal government’s canonical identifier for place names (replacing older schemes like FIPS).

In my own mapping, I’ve not only preserved gnis:feature_id tags when converting POIs to areas, but I’ve also manually *added* gnis:feature_id tags where there’s a direct relationship between the feature I’m mapping and the GNIS entry. For one thing, it’s a more explicit kind of source tag. Even when GNIS isn’t my primary source, it serves as a citation so that a far-future mapper will know for sure that I didn’t just make up a park, lake, or cemetery to improve my Pokémon Go gameplay.

So no, the GNIS feature ID isn’t useless. But if you feel strongly that gnis:feature_id should not go on this feature for some other reason, then please at least replace it with wikidata=Q49497832. Virtually all of GNIS has been imported into Wikidata (and the Cebuano Wikipedia); you can usually find the correct item by searching Wikidata for the GNIS feature ID. At least the wikidata tag leaves the “paper trail” that some mappers clearly value.

Renderers and routers ignore the construction=* tag when highway=* is set to something other than highway=construction.

Thanks for noting this proposed road. In the future, if the road isn’t yet open to traffic, please use the Road Closed preset.

If a road is proposed and you know the specific path it’ll take, but construction hasn’t started yet, you’d manually add the highway=proposed and proposed=residential tags.

If you have any questions about tagging, please feel free to reach out to me or ask folks in the #ohio chat room of OSMUS Slack. (You can invite yourself to Slack at https://slack.openstreetmap.us/ .)

What you did in this changeset is a decent workaround, but I think it shows why it’s suboptimal to make roads themselves members of a boundary relation.

The alternative is to map a distinct way (which can be untagged or tagged boundary=administrative) to serve as the boundary relation’s member way. (You’ve started to do that, but only where there’s an overpass.) That boundary way can be joined to the roadway if it’s important to state that the roadway is defined as the border of the town, or it can be kept separate if the border just happens to coincide with the roadway around here.

At the point where the bridge crosses over Loch Raven Blvd., the boundary way can jump from one roadway to the other; the specific location wouldn’t make much difference as long as the roadways don’t intersect.

I think there may have been a mistake: changeset/77826640 affects a bridge in a different county than this changeset (SR 133 versus SR 123). I’ve already reopened SR 133 in changeset/77673713. But it’s reassuring to hear that you’re revisiting these closures.