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!

It would be great if the brand:* tags could also be changed to disused:brand:* or was:brand:*. Otherwise, these POIs still show up in queries for the current brand, and editors like iD still treat them as having associated Wikidata items (giving them a locked-down treatment).

Reverted in changeset/76619419. There’s no reason a highway=motorway_link can’t connect directly to a highway=tertiary. If an intervening highway=trunk were required, there would be a trunk road at the end of every freeway off-ramp and the beginning of every freeway on-ramp.

highway=trunk has an unfortunately ambiguous definition in the U.S., but even so, it isn’t intended to be a way to “average out” the road class of an adjacent link way.

If your team has systematically introduced highway=trunk tags in situations like this, could you please review and revert them, or coordinate with the community to do so? Thank you!

Reverted in changeset/76619187. changeset/76619335 merges the POI to the correct building based on Bing Streetside imagery.

If you don’t know which building it is, please leave the POI alone and skip the MapRoulette task instead of merging the POI into multiple buildings. POIs imported from GNIS aren’t precise enough for you to assume that it corresponds to the building beneath it. Thank you for understanding.

(Also changeset/76372771.)

This changeset has been reverted fully or in part by changeset/76372508 where the changeset comment is: Reverted changeset/74350075: undiscussed import, incorrect tagging, duplicated some existing data

(Also changeset/76372493.)

This changeset has been reverted fully or in part by changeset/76372265 where the changeset comment is: Reverted changeset/74378574: undiscussed import, incorrect tagging, duplicated some existing data