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

Meant to import this using the Minh Nguyen_sjimport account.

More information about this closure: https://tatetownship.org/2019/11/13/s-r-133-road-closure-nov-18-20-2019/

Hi, thanks for noticing the road closure. SR 133 was only closed for two days and reopened over a week ago.

Does your team have a plan to promptly revisit these roads after tagging them as temporarily inaccessible based on a live-updating traffic website? If not, I’d recommend ignoring temporary road closures for the time being. Depending on the use case, lingering outdated closures can be worse than missing closures. (Data consumers can supplement OSM with traffic and incident data, but it’s more difficult to override OSM road closures in postprocessing.)

Hi again,

Changeset 77670122 undoes some of these changes, including a 500-foot-long, dead-ending driveway that you had promoted to a trunk road. Once again, please follow the on-the-ground rule, as described in osm.wiki/Good_practice#Verifiability . I don’t dispute that SR 348 is proposed to become a divided highway, but please be patient and use proposed:* tags for the time being.

Unlike some other states, ODOT doesn’t signpost Appalachian Development Highways. Once completed, the highway would remain SR 348, so “Corridor B” should be left off of name tags. If you’re interested in mapping the ADHS routes, please follow the examples in osm.wiki/Ohio/Route_relations/National_routes#Appalachian_Development_Highways. Thank you for your understanding.

This is an unofficial running route that isn’t assigned or maintained by a road, trail, or park agency. It doesn’t belong in OSM proper, but it can be overlaid on an OSM basemap in a third-party website or application, for example using umap.openstreetmap.fr.

Speaking of Bing, I’d highly recommend switching to a different background imagery layer so you don’t waste effort mapping stuff that’s outdated. While editing, open the “Background settings” panel from the right side of the map, then switch to OSIP 6in or Maxar. Both are much more current than Bing. OSIP 6in is higher-resolution, but Maxar is slightly newer. osm.wiki/Ohio#Resources has a comparison of the various available layers.

Thank you for the attention you’re giving to buildings in this area. In Hamilton County, we’ve been retagging demolished buildings rather than deleting them outright, because the default imagery layer, Bing, is quite outdated. There’s a strong risk that someone will think they see a missing building and feel the need to add it to the map because of all the other buildings we’ve imported. The demolished:building=* areas hopefully give mappers a reason to double-check.

If you do accidentally delete one of these demolished:building=* areas, it isn’t a big deal, but I just wanted to make sure you didn’t feel compelled to take the time to delete them. Most likely we’ll delete them em masse once Bing updates their coverage of the Cincinnati area.

By the way, I restored several demolished:building=* ways that you deleted in this changeset. Normally it’s OK to delete a demolished building outright, but lately in the Cincinnati area, we’ve had some problems with demolished buildings being restored multiple times due to outdated Bing imagery or an import of slightly outdated municipal building data. The demolished: namespace ensures that no data consumer will treat these features as extant buildings, but the presence of these areas also hopefully gives mappers pause before adding them back as buildings.

It probably isn’t worth your time to find and delete these already retagged buildings manually. We’ll do a sweep of them once the default imagery layer, Bing, finally updates their imagery in the area. But if you spot additional buildings in the area that have been demolished, please feel free to either retag or delete them.

Really appreciate your updates, by the way – it made it easier to spot areas that needed remapping based on even newer imagery.

CAGIS 2019 orthophotography was a source for these changes.

Hi, I’m not sure what all is contained in this very large changeset, but I noticed that it includes some incorrect changes in Reading, namely merging a crosswalk with a traffic light and deleting turn lanes that are important for correct router behavior. Turn lanes have been mapped very extensively by hand in the Greater Cincinnati area. If you see a road that appears to be cut up into itty-bitty ways, it’s probably because of turn lanes, so please leave the ways as is.

Incidentally, you may find it helpful to use the OSIP 6in Most Current Available imagery layer when realigning roads and other features. That layer is much higher-resolution than Maxar but just as current in many counties of Ohio.

Thank you for your attention to these details.

The source tag seems to be a holdover from changeset 76867595 and previous changesets where buildings were being imported instead.

Remember to add access=customers to store parking lots so the “P” icons don’t crowd out POI icons. Renderers generally give parking lot icons more prominence than POI icons when they represent public lots.

Thanks a bunch!