Hey! This changeset appears to consist mostly if not completely of spam, similar to the spam we previously saw from unknown246's account (discussion on osm.org/changeset/169357242). For now, I've gone ahead and reverted the whole thing in osm.org/changeset/169829340 .

What happened? Was your account hacked too? If you are intentionally creating new accounts in order to continue spamming, I'll have to ask what tools the Data Working Group has available to stop this. If you believe some of your edits to elements are valid, please explain which ones and where you got the data (your changeset has an unhelpful description and no source) and we can reinstate those edits.

Thanks for your cooperation.

OK, I reverted the remaining parts of your changesets 169310048 through 169373059, even the parts that looked potentially valid. (Technicality: I didn't revert discardable tags.) I think this is the best way, to make sure that other users don't contact you with questions about data you didn't intend to submit. If any of the changes are valid and important, someone can redo them later.

I didn't touch your changesets after 169373059, except I reverted osm.org/changeset/169482172 because I didn't think it made sense to leave the business with a city, state, and zip but no house number or street. If you can vouch for all the address tags, feel free to resubmit them.

Thanks again for your cooperation. I'm glad to see that this incident apparently hasn't turned you off of contributing to OSM.

See osm.org/changeset/169357242 for discussion.

I've cleaned up almost all of the 5TDGBRCH4MS037831 stuff as well as some links to irrelevant photos on Flickr. However, some of the same changesets that included the obvious spam also included other edits that look like they could be either truthful or bogus. unknown246, did you intentionally make any edits to OpenStreetMap since July 21, or can I assume that all the edits from your account in that time period are from the hacker? If the latter, then I will revert the rest of the edits. (I was going to leave them alone, but then I noticed osm.org/changeset/169310048, with stream names that look pretty unlikely to be truthful.) Thanks for your cooperation in getting this mess cleaned up.

See the discussion on osm.org/changeset/169357242 . I'm already working on reverting the "5TDGBRCH4MS037831" spam in all of unknown246's changesets. But I'm a relatively junior user; if DWG wants to take this over and has better tools, go for it. Is there a better place to put a notice so other mappers don't inquire on more individual changesets?

Oh, that makes sense. Thanks for letting us know what's going on. I assume you already locked the hacker out (e.g., by changing your password and revoking any OAuth authorizations they could be using)? I'll work on cleaning up the 5TDGBRCH4MS037831 stuff.

Hey, why did you name so many elements "5TDGBRCH4MS037831"? I don't see how this could be accurate. Did your editor go haywire?

This change looks good. Thank you for the contribution! I only found two minor issues:
1. osm.org/node/7515008604 should not be tagged highway=crossing because the intersecting way is not a road. (It's unclear if the intersecting way represents a trail or a park boundary, but that's not our problem here.) I went ahead and fixed this in osm.org/changeset/169027531.
2. osm.org/way/1412528283 has an extra node on the west end after the connection to the crossing. That could be valid if the sidewalk extends a little beyond the crossing, but looking at the imagery, I think you may have intended to connect the crossing to the west endpoint of the sidewalk instead of the second node from the west. I'll leave this for you to change if you feel it's appropriate.

Looks good. Thanks.

The change itself looks good. I'd encourage you to specify the source as you did on some of your other changesets. I know the iD editor doesn't make this obvious (https://github.com/openstreetmap/iD/issues/7755 for the record).

The change looks fine to me. Thanks for contributing. It looks like there are some other service roads internal to the plant that have no access tag. If you think it's safe to assume they're private too, you could consider tagging them so.
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/168872107

Thanks for pointing this out. I performed the deletion in osm.org/changeset/168986891. To delete part of an OSM way, you would select both the way and the cutoff point, use the "split" command, and then delete one of the two ways left after the split.

In the future, if you need a change made to the map but are not sure how to perform it, it's better to create a note with the information (osm.wiki/Notes) than to add dummy data to the map. Thanks for your contributions!

Oops, the source should also include "Esri World Imagery" for confirmation of the approximate location.

FWIW, technically the source should include "Mapillary Traffic Signs" because I took the precise location from there (via Osmose) after checking it was consistent with the approximate location from my survey.

I noticed that the remapping of shops from nodes to areas in this changeset lost some tags from shops I had previously edited. I restored those tags in osm.org/changeset/168573989. I haven't checked whether tags were lost from other shops in this changeset too.

Note that I haven't rechecked the validity of any of these tags; I'm assuming their removal in osm.org/changeset/145780465 was unintentional. Feel free to overwrite this changeset if you have information that is newer than when the tags were originally added prior to osm.org/changeset/145780465.

I am assuming the highway=primary tag was just a mistake in osm.org/changeset/76241229. If there is some justification for it, feel free to revert.

Are you sure that the time-conditional restriction is correct for the service road? I visited this location on January 15, 2025 and there was an unconditional "right turn only" restriction from the service road, like the one in this Mapillary image: https://www.mapillary.com/app/?lat=38.9026429&lng=-77.0382639&z=19.243399386914778&mapStyle=OpenStreetMap&pKey=578009907499172&focus=photo&x=0.4265917848549031&y=0.3344586912640908&zoom=0.665217391304348 . (That's even stricter than the unconditional "no left turn" that OSM had before this changeset.) I suspect the time-conditional "no left turn" is intended for the main road, and that restriction is already mapped (osm.org/relation/6528323).

If you could recheck your imagery, that would probably be the quickest way to resolve this. Otherwise, I'll resurvey the restriction if and when I have an opportunity to visit the location again. Thanks!

It looks to me that the first relation added in this changeset (osm.org/relation/12475896) is redundant with the second (osm.org/relation/12475897): the first contains an extra via way. I suspect this may have been due to a glitch in the iD turn restriction editor. I deleted the redundant restriction in osm.org/changeset/166413518. Let me know if you disagree.

- The newest aerial image I could find in JOSM was from Esri World Imagery. Trace the building from there, adjust parking to not overlap, and delete the pitches since they're confirmed to be destroyed by the construction.
- Adjacent intersection changes from survey
I'm sure the campus could use a lot more work, but at least this is much better than what we had.