There's a discussion on OSM US Slack about what parts of this changeset may have been appropriate: https://osmus.slack.com/archives/CCN1KJ76U/p1781742162221729

@Flap Slimy Outward, please don't continue with the changes until we have some agreement on this.

Good idea! If you're working on boundaries in SoCal, you may bump into some that I updated recently. Keep an eye out for boundaries with recent dates in the source tag on the member ways!

Also, FYI, here's where you can find out what all those TIGER fields mean: https://www2.census.gov/geo/pdfs/maps-data/data/tiger/tgrshp2025/TGRSHP2025_TechDoc.pdf

I see you updated the Census boundary for Beatty. The update is welcome, but when you make an update like this next time, you might check to see if there's an existing Census boundary in place first. In this case, relation/170095. If there is, the correct thing to do is to update the existing elements with the new geometry rather than deleting and replacing them. That helps preserve the edit history.

Also, I can see that you did not translate the coordinates from TIGER's NAD83 coordinate system to the WGS84 coordinate system used in OSM. That's important for boundary relations like this where the coordinates can't be verified on the ground -- particularly in places like Beatty which is in one of the most geologically active regions of the US. The earth moves here!

Here's how to perform the coordinate transformation if you plan to import other TIGER data in the future: osm.wiki/How_to_transform_data_from_NAD83_to_WGS84

Similar to changeset/181391951, please keep the source tag on ways in imported boundary relations, such as way/33164086. Thanks!

Similar to the comment on changeset/181646686, please keep the source and datum:* tags on the ways in imported boundary data, such as way/33178232. This information helps us maintain the boundary data over time! Thanks!

Similar to the comment on changeset/181391951, please keep the source tags on ways used in boundary relations, like way/33178326. That's important so we can tell which version of the TIGER data the boundary came from. Also, please keep the datum:* tags on these ways. Those tags document that the data was properly transformed from NAD83 coordinates to WGS84 coordinates before the import so that the boundary ends up in the right place. Without that, it's not clear whether the boundary data was properly transformed, and that makes it difficult to resolve alignment issues between imported data that comes from different coordinate systems.

I noticed you deleted all the tags from way/37913359. It's ok to delete most of the tags from the ways that are only used in boundary relations. But please keep the source tag. That's very helpful when we come back in a few years and try to figure out which version of the TIGER data this boundary came from. I see there's a copy of the tag on the relation itself, but keeping the tag on the member way makes it much easier to find boundary data that's out of date.

Good catch!

Thanks! I think we're getting closer. Let's work things out there so that we're on the same page with this relation and the member ways.

I see that you have unilaterally decided to undo much of my recent work on this relation, even though you are aware that the changes were discussed in the Community Forum (https://community.openstreetmap.org/t/cleaning-up-historic-us-route-80/139776/14). I still intend to make the changes that have been discussed in the forum, but I don't think an edit war is productive. Could I ask you to participate in that discussion so that we can settle on a consensus of how this relation should be mapped (if at all) and so that we can work together on the revisions instead of bumping into each others edits?

Those changes are intentional. If you'd like to discuss the changes further, I invite you to join the discussion at https://community.openstreetmap.org/t/cleaning-up-historic-us-route-80. Thanks!

Hi! Looks like you found a water source for the Impossible Railroad. Some of the tags for the features in this changeset are unusual. Maybe I can help with some improvements. Can you tell me more about what you found out there?

Hi! We're discussing Historic US Route 80 in the Community forum (https://community.openstreetmap.org/t/cleaning-up-historic-us-route-80/139776). Would you be able to help by explaining the original source of the Historic US 80 (CA) relation (relation/9712655)? Is there a way of verifying which road segments were included/excluded?

That's great that you were able to get to the hill you remembered -- and even better that it led to some good updates to OSM! Sounds like we both enjoy the area, so maybe I'll see you out there!

Thanks for doing a survey and making some updates out by Ocotillo! Just FYI, there might be some differences of opinion about whether the gated roads going to the wind turbines are highway=service or highway=track. Personally, I'm fine with either one and I mostly leave the highway=* tags on these roads as I find them. But you may find that other mappers will switch the tags.

It doesn't seem like we're making progress on this discussion. So, what I plan to do is take out the bridges and restore the other ways and tags for the BLM routes and turbine spurs. If you don't agree with those changes or you would come back and undo them later, now is the time to speak up so we can get on the same page.

I'd like to continue the discussion here and on the other changesets where I've made comments, but I'm going to be out of touch for a few days. Please be patient if it takes me a while to respond to comments.

@dvlpmnt thanks for getting in touch. I noticed you've been doing a lot of work on mapping around energy infrastructure and that's a really great contribution to OSM!

I just think there was some confusion here and I think we can work it out.

If you're there in person, you can see that many of the spur roads have gates and the roads are signposted "Closed to Motorized Vehicles," which presumably means other than the maintenance staff. That's an important distinction because the signage does not otherwise restrict access. And whatever the site manager may say, this is still BLM land and it is open to foot travel or other forms of non-motorized travel.

So, the right way to handle this is to map the gates with "access=private" and tag the turbine spurs (and only the turbine spurs) with "motor_vehicle=private." Fortunately, that's something that most data consumers including routers should understand.

But there's also an important principle here. We're mapping what's on the ground, not mapping things that don't exist in the hopes of getting data consumers to behave a certain way. There aren't any signposted turn restrictions here, so we wouldn't map those. Likewise, there aren't any bridges.

Would you mind if I went back over the areas to take out the bridges and put in access tag where they might be missing?

The roads in this changeset do exist. The issues are likely a misunderstanding of the conditions on the ground and how to represent them in OSM. (And I'd blame some of the phantom bridges on overly aggressive validation in iD.)

I haven't checked other changesets by this user, but I did notice that they like to use some very recent imagery sources that have roads that don't show up on the typically older Bing/Esri/Maxar imagery.

If you have evidence of improper changesets even after considering the most recent Sentinel-2 imagery, I'd suggest that you comment on those changesets and follow up with DWG if you cannot resolve the issues.