Thank you!

I’m not sure that’s fair. If you only disagreed with the highway classification changes, you should’ve only undone those changes without all the others, unless you had reason to believe you were dealing with vandalism, fiction, a copyright violation, or some other bad-faith edit. The revert plugin is convenient but not always the right tool for addressing problems in the database.

Looking at the history, you weren’t responsible for adding the tag originally, but your revert effectively added it back in. Please be careful using the reverter plugin; sometimes the mapper you’re reverting says they’re only changing one thing, but in fact they’re changing a lot of stuff that you might not disagree with (such as the relations in this changeset).

I think every way in this changeset was affected, for example: osm.org/way/1119506496

Hi, is “OLD 31” signposted anywhere? This changeset seems to have introduced ref=OLD 31 as an alternative to old_ref=US 31, unless I’m misreading the history.

https://community.openstreetmap.org/t/dwg-username-impersonation/101212

Hi, I don’t think Mehring Way should be a primary road. Despite the routing of U.S. 27 and U.S. 52 along this street, it’s basically only for accessing the stadiums and parks and for some local truck traffic, but I don’t think it’s as much of a through route as 2nd and 3rd Streets (which aren’t part of any numbered route). Any objection to downgrading Mehring Way back to secondary?

Globally, many more intersections are named (osm.wiki/Named_spots_instead_of_street_names ) than numbered in the real world (especially in Japan), so I’m not surprised about the disparity in the database. I had been under the impression that OSRM calls out junction refs at intersections, but junction names aren’t implemented yet (https://github.com/Project-OSRM/osrm-backend/issues/3500 ), so this might just apply to mistagging as junction:ref (which is for link roads).

Perhaps these should be redundantly tagged with ref for the time being, since that’s the more semantically correct key?

Should these numbers go in ref rather than name? I suspect most renderers and routers that understand junction names would also understand junction refs.

The discussion continues in https://community.openstreetmap.org/t/infrastructure-edits-in-usa-such-as-https-www-openstreetmap-org-changeset-137533993/100397

👌

These names were probably place names. Since it’s possible that these names came from a survey that’s difficult to reproduce, consider bringing back the names as place POIs. Otherwise, this changeset results in a loss of information.

Deleted in changeset 136957643; see note 2772893.

Asked in https://www.facebook.com/groups/openstreetmapvietnam/posts/1602562726821377/

Thanks for spotting these license=* tags. A more descriptive key is probably warranted, since ref:license=* isn’t used anywhere else, but we’ll have to consult with the local community on the exact key to use.

Technically, these numbers are the numbers of decisions by local governing bodies. “SYT-GPHĐ” stands for “Sở Y tế – giấy phép hoạt động” (Health Department – operating license), while “CT-CCHN” stands for “Cần Thơ – chứng chỉ hành nghề” (Can Tho province – practicing certificate). It’s typical for any decision/law/license number to contain a slash followed by a descriptor of this sort.

Not sure, but some OSM-based renderers do try to depict rooftop solar panels realistically:

https://community.openstreetmap.org/t/streets-gl-a-new-3d-renderer-for-osm/98594/56

Hi, it’s correct to tag these solar panel structures as roofs (or more specifically, carports). Updated in changeset 136353699.

Hi, as you redraw roads to be dual carriageways, please remember to align the imagery layer you’re using with other features in the immediate vicinity of your edits. In this changeset, for example, the surrounding roads and other features had been aligned to a high-resolution imagery layer (OSIP 6in), so your edits based on Maxar imagery created a rather significant kink in the road that could have affected routing.

In iD, open the Background panel and scroll to the bottom, where you can adjust the Maxar layer’s offset. For best results, find a point feature that you can see in both the older, high-resolution imagery and the newer, low-resolution imagery (such as trees or crosswalks) and make sure that feature aligns with both layers.

Thanks for your attention to detail as you update these roads.

https://community.openstreetmap.org/t/rainy-lake-super-relation/97627

Sorry for implicating you in this multipolygon mess. Indeed, the split multipolygons originated even earlier, in changeset 56736435 by a different mapper. We’ll continue to discuss this as a community, but you’re welcome to participate in the discussion if you prefer the current approach.