Hey there - please, please, please don't do that. Deleting an object just to recreate it trashes its history. Also, this got rid of all the tagging on the building (address and stuff).

In this specific case, stuff that's glued together but shouldn't be can be easily separated using the disconnect feature in iD/RapiD (left click the point/node that connects the two object that need to be separated, then right click or hit space bar to open the context menu and chose "Disconnect" from the context menu).

Thank you!

Here's some further info: osm.wiki/Keep_the_history

Hey there - can you explain why the right turn was removed from the point in the middle of the intersection? The right turn traffic has to use the slip lane, and you can't (legally) turn right from the through lanes, no?

Hey there - any route relation in particular you have in mind? If you have an example I'll be more than happy to look into what happened.
I fixed the 59 relation which was quite messed up, but didn't review all other relations that may have shared points/segments with 59.
I still have some portions of IL59 left to lane-tag (further north); and I'm planning on doing the same thing for all IL state highways, including reviewing the relations themselves (I only did a handful of the shorter state highways so far, it can be quite tedious).

I'm not sparse editing though, I usually just download rather narrow rectangles along the route, mostly because I want to see a couple feet left and right - to do the lane tags on the first couple of segments of the crossing roads at major intersections too, and also to do turn restrictions and traffic lights where possible (also, the machine I am typically working on is powerful enough for sparse queries to not be nexessary for these types of edits most of the time).

Hey...couple of questions on this one:
- what's the thought behind tagging the fairways on golfcourses as landuse=grass (the wiki* says not to do that)? Tagging for the renderer of some sorts? Or was that inadvertent? Same question on the Tees and Greens (although these are not explicitly being mentioned on the wiki page).

- I believe a big chunk of the building on the SW corner of 103rd and 59 is some sort of medical offices (something Dupage Medical Group, if I remember correctly, not sure what exactly, and, I believe, a pediatrist's office also on the north side of the bldg). Are you sure this whole building should be building=retail just bc there's a liquor store on the back side?

-Same thought on the bldg on the SW corner of Rollingridge and 59 - mostly medical offices, I believe. building=retail just sounds super random for those. What is being sold there?

- what's the deal with the pool-inside-of-a-pool situation in Bristol Station? The actual pool was tagged fine, and the fenced-in area surrounding it isn't a pool...

- What's the reason for changing building=fire_station to building=public on Nap Fire Dep Station 4? building=fire_station is valid, and way more specific...
Are you aware of the differences** between building=fire_station and amenity=fire_station? One is the grounds, the other is the building, they do not represent the same thing. What you created is a fire station (amenity) within a fire station (amenity), but without an actual fire station building - that's definitely not what's on the ground.

- What's the thought behind removing crossing=zebra (on Conan Doyle Rd)***?

Thanks,

* leisure=golf_course

** building=fire_station

*** crossing=zebra

Hey there - first of all: welcome!
I just saw your changes around 75th and Hunters Wood - thanks for your contribution.
I made a couple of small changes - mostly relating to names on service roads. We don't typically tag these with the name of the business they belong to (e.g. the service road that is the McDonald's Drive in isn't actually called "McDonald's" - the restaurant is).

If you haven't seen it yet, the wiki* has tons of information on recommended tagging and is a good starting point for additional information if you're not sure how to tag something.

If you need help or have any questions, please feel free to message me anytime.

Thanks again,

* osm.wiki/Main_Page

Ah, nevermind, I didn't look at this right, I was referring to the other exit a little further west. All good.

Hi - are you sure there actually is a no left turn restriction from the parking lot into 111th?
Last time I was in the area, turning left into 111th was allowed, and in fact, that little access road was two lanes (one of them being a left turn lane). This may have changed recently, I haven't been there in ~1 month, so wanted to confirm.
Thanks!

Spam. Reverted in changeset/112306465

Spam. reverted in changeset/112306412

Those multi-building scenarios kind of sound like a textbook example for a multipoly, no?
Although that isn't how they're mapped in most places, I don't think. Gas stations are often like that...and many of them appear to be mapped as two separate objects, typically one with amenity=fuel+building=roof and the other with building=retail+shop=convenience. Not completely wrong IMHO, but not 100% clean either, since "the speedway at the intersection of x and y" feels more like one entity that happens to be both, a gas station + convenience store.

No worries; thanks for verifying. Just fixed it.

Hi - thanks for the explanation.

I guess you have a point about the outdoor areas - I suppose it would be *technically* correct to tag the outdoor area/patio/whatever separately from the bldg, and then create a relation and tag that rel as a store/restaurant/whatever.

Entity continuity is a matter of perspective, I guess... like you said, having the poi separate from the building makes it very easy to answer questions like "did this business move". In theory, that is. Practically, the decision whether "business xzy moved from A to B" or "business xyz closed store A and opened a new location B a couple months later " often requires inside knowledge of how that business is organized. It's probably fair to make an educated guess for the mom&pop shop moving across the street; but how do you know if the gas station/pharmacy/grocery store closing in one spot and reopening two intersections farther north is actually the same store reopening in a different location or not?
Also, what you gain in continuity on the poi is what you lose on the building (for questions such as "What store was in this bldg before?")

I 100% agree with the (strip) malls - where there's one building, we shouldn't be mapping multiple ones just to separate the stores.
What I've started doing in these cases is to map the building as one large poly, and then add multiple smaller polys within that (sharing nodes with the bldg itself around the outer perimeter) for the individual stores. (Each of the stores is, of course, not tagged as a bldg).
To me, that appeared to be a fair compromise that doesn't split buildings when they really shouldn't be; while it preserves the information about each store's area/size.
I mapped the majority of Chicago Premium Outlets up in Aurora this way in case you're interested in an example - it seems to work quite nice.
It also comes with a neat side effect - it makes it quite easy to see whether businesses are missing in a shopping center/(strip) mall - that's much harder with node-only POIs.

Perhaps that would be an acceptable approach for you as well (1:1 buildings = combined store+bldg tagging on one polygon; multiple businesses in one bldg = separate polys for each store + one surrounding poly for the bldg)?

I've seen many cases where people would change it the exact opposite way (merge the POI into the bldg) - not just around here (I'm sure you noticed this area is pretty much dead), but in general. I'm not sure that achieving anything that's even close to being consistent is really realistic (not as long as there isn't clear consensus that one approach is preferred over the other anyway). Just sounds like everyone keeps everyone else busy.

Thanks,

are you sure that the whole shopping ctr is unit 123 (including the petsmart, tjmaxx, great clips and liza nail spa)?

Hello,
what's the benefit of detaching the shops from their buildings by making them all separate one-node POIs?
It would seem that there's multiple drawbacks to this approach, especially where there's a 1:1 relationship between bldg and store (duplicate/redundant addresses; loss of information how much of the building is actually being used by that particular store), so I'd be curious to understand what the motivation is for these changes...

Thanks!

Hello,

why did you delete the strip mall buildings and tag each of the shops as a building by itself? None of the shops is a building. They are multiple shops in one building, just like they were mapped.

Also, why are you replacing the more precise zip+4 addr:postcode tagging with just the five digit zip alone? This is a loss of information - where's the benefit of doing that?

Finally, why are you duplicating address points on objects that don't really have addresses themselves (the roofs by the gas stations)?

All in all, this change set looks like it broke more than it fixed.

Hey there - forests in the mall parking lot...interesting choice of tags :)
landuse=grass (and then the trees or natural=tree_row in addition to the grass) would seem more fitting.

The mapping of forests is following different tagging schemes and definitions*, however I'm fairly confident that most mappers will agree that a handful of trees in a parking lot is not enough to constitute a forest...

* osm.wiki/Forest

Hi - I've been working on adding addresses based on data the city publishes over the last couple of days and noticed you added a couple of addresses here. Since you mentioned you're from the area - could you double check if the zip on these birch and empress houses is really 60563? I always thought 60563 is just north of the BNSF railroad tracks - and that is what I'm seeing in the city's dataset too. I'm thinking these should be 60564...

I forgot to mention - if you don't like the tools linked above for the fact that they're experimental, maybe the changeset by comparison visualization [1] is an option for you. Also two clicks away from osmcha if you use the smart menu, with no need to enter the changeset id manually or build the url or whatever.
I believe it also lets you bookmark an area of interest as a rss feed which (if I'm looking at it right) only includes the ones that actually changed something in the bookmarked area but excludes anything that has an overlapping bbox without actual changes in the area of interest. Please don't question my intellect for bringing it up though.

[1]
https://resultmaps.neis-one.org/osm-change-viz?c=110409629#1/49/1

@Lee Carré: Trying to filter these change sets out is kind of trying to tackle the issue when it's already too late (and so is complaining in the comments once these happened). Here's a thought:
Essentially, there's three types of big-bbox-changesets
1. beginners not knowing that unrelated changes far apart should be submitted in separate change sets
2. more experienced users who do know that, but create giant change sets by mistake (I just recently created two of these myself -unintentionally- and didn't notice until it was too late)
3. intentionally big change sets that touch a large number of similar features over a large bbox (this change set specifically would be an example that falls into that category).

In my perception, types #1 and #2 account for the majority of the global bbox changes.

Maybe a better way to deal with the issue would be to have the editors (most importantly id and josm, I guess) display warnings when modifying a feature in the editor (not when committing the changeset, but the moment you touch the feature). The warning could be something like "You are about to modify an object that is more than x miles/kilometers away from all the changes you've made so far. It is generally preferred to only group geographically close changes in one change set. Please consider uploading your prior changes before continuing".
One could probably even do multiple escalations - say 1/10/50/250 (tbd) miles apart.

This would hopefully discourage most users from creating type #1 issues, it would likely solve type #2 issues altogether, but would allow the fewer remaining instances of type #3 to still go through.

It doesn't give you 100% of what you want (no global change sets ever) - but the status quo (=complaining about them when it's too late) clearly isn't super effective either.

"Dismissively directing me to ..." - seriously? The tools may be proofs of concept and may not be perfect or fully feature complete - but I guess they're better than nothing, no?". Interpreting somebody's hint that there are tools that are better than nothing at all as being "dismissive", "disingenuous" and "dishonest" is certainly an _interesting_ point of view. I guess everybody should pay attention not to tell you about solutions/workarounds that work for them.

Finally, please keep in mind that while your time is certainly precious, that doesn't mean that everybody else's is not (and I'm saying this specifically referring to the type #3 changes I described above).
Some changes are simply done much more efficiently through arm chair mapping (we don't need no survey to see that the surface on a street is "asphalt", not "asphaalt").

Hi - this was unintentional - I made hundreds of cleanup changes, most touching a single node (and all being submitted as ridiculously small one-node changesets). Something went wrong in JOSM for two of the them (the other one covers a large portion of south america). I can't fully reproduce the issue at this point, but once I do I'll make sure to report it.

In the meantime, I have a request for you also - please review the documentation of the tools you're using. osmcha's reviewed_bad is intended for changes that "break the map or [are] invalid data"*. Neither is the case here. Being inconvenienced by a changeset's large bbox is _not_ breaking the map at all.

Thanks!

* https://osmcha.org/about#why-to-review-a-changeset-as-goodbad-%F0%9F%91%8D--%F0%9F%91%8E-