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-

Hello - a couple notes on some of your changes around Georgetown Elementary:
- Please do not delete features just to redraw them (like the school building or the baseball field). Deleting + redrawing results in the object's history being lost. If you find a feature to be misplaced, move it, if it's shape isn't represented correctly, add or remove nodes as appropriate but keep the feature itself.
- Please note that some imagery is terribly misaligned. This is particularly true when you're working with bing and one of the high-zoomlevel tiles is missing and a lower res level gets pulled in instead (like around the school). The perfect solution to this issue would be to realign your imagery to a gps track before moving objects around. Since a gps track isn't always available, aligning the imagery to something that is known to be right (like a nearby street that has been mapped already) is usually a feasible workaround. You can find more details in the wiki*.
- some buildings with "holes" in them (like the school). These "holes" are typically cut out of the building shape by creating something that's called a multipolygon. These are a little trickier to create than "normal" buildings. Essentially, you draw the outer shape; you draw a separate polygon for the piece that needs to be cut out; and then you create a relation that tells osm how these two polygons belong together. The wiki ** has a detailed example of how this is done in the iD editor you're using.

If you need any help, please let me know.

Thanks,

* osm.wiki/Using_Imagery#ID

** osm.wiki/Relation:multipolygon#iD

Mh, so it's not a lack of proper tools but a lack of willingness to use a tool that's actually fit for the purpose (finding out whether a change set affects your area of interest or not) then?

One could turn that productivity argument around very easily - thousands of volunteers work on improving the map around the world during their limited free time. They do not have the time to create a separate change set for every node they touch, writing a half page essay for a change set comment every time.
I get the "it's disrespectful" argument to a degree - but, that one as well can be seen differently: Forcing thousands of editors around the world to trade their productivity because a smaller number of individuals isn't willing to use the proper tools can certainly be seen as being disrespectful too (think: "I can't be bothered to use a better workflow, so everyone should do everything they can to make my personal life easier").
What one person considers an appropriate change set size (country? state? county? city?) may still be unacceptably big for others (say, someone who focuses on a particular neighborhood only).
On the other hand, cutting change sets like this one (which do one thing only, just spread over a large bbox) into potentially hundreds of individual change sets is not exactly fun to review either. IMO there is no sweet spot - you'll always find somebody who will be offended.

Finally, the "if you have plenty of time then go fix it" argument isn't fully consistent either. Some individuals clearly have the time to comment on almost _every_ big change set. It would have taken a second or two to copy/paste the change set id into one of the tools linked above - much less than this whole discussion. Also the logic seems a little off. It would stand to reason that the individuals feeling they need better tools should have the highest interest in driving the improvement of the tools. Delegating that seems completely backwards (think: "Until I get the tool I want, I'm gonna enforce an arbitrary set of rules that I myself consider appropriate and if somebody doesn't like them they're free to give me said tool").

All of that being said - I'm not saying big change sets are good per se (in all honesty I'm not exactly a fan of them either, especially when all they touch is one park bench in california and one turn restriction in china); I'm just saying that there's other perspectives as well and this whole "all big change sets are inherently evil" attitude feels a little over the top sometimes; and grouping changes of the same type in one (potentially large) change set can make sense.

If anyone is interested in an actual solution to navigate to achavi from osmcha without having to copy/paste the changeset id: you may be interested in the osm smart menu browser extension*. It adds a little toolbar button that lets you jump between all sorts of osm related websites and services. That way, the achavi site with the correct changeset selected is literally two clicks away from osmcha.

* osm.wiki/OSM_Smart_Menu

Could anyone explain what's wrong with using overpassapi +changesetmap or achavi for reviewing whether a changeset affects your particular local area as suggested above?
Since it's the same group of individuals complaining about large changesets regularly, I'd be curious to hear their perspective.

Hi - thanks for getting back on this.
Per the wiki linked above, the official name is to be tagged separately (using the official_name=* tag) while the "normal" name is supposed to follow a standard pattern that does not necessarily match the official name.

Hello - could you explain your thought process behind renaming the bus relations using a nonstandard pattern? The documentation in the wiki* says to use "Bus <ref>: <from> => <to>", not "<from> - <to>" for the route; and "Bus <ref>" for the route master (that's exactly how it was tagged before your change).

Also, both, the northbound AND the southbound relation are called "Ashbury - Naperville Metra" now while one of them actually travels opposite direction - this looks bizarre, wouldn't you agree?

Finally, per the same documentation, role=stop appears to be discouraged for adding the stops to the relation; so I was wondering why you changed the role=platform to role=stop?

Thanks,

* osm.wiki/Buses

Hello - please note that there's a difference between highway=turning_circle and highway=turning_loop. While a node tagged with highway=turning_loop can be replaced by a circular highway=* without changing the meaning, the same is not true for highway=turning_circle. If there isn't something (non-traversable) in the middle of the thing then please don't draw it as a circular way but tag the endpoint accordingly instead.

Documentation can be found here:
highway=turning_circle
and here:
highway=turning_loop

Thanks!
---

Published using OSMCha: https://osmcha.org/changesets/110302043

:). This is a never-ending project...

Hi - the buildings you added back in on the ogden mall lot (between Iroquis and Naperville/Wheaton Rd) had been deleted because thez have been razed to make room for a new CostCo that just opened. I'm going to redelete them, they don't exist anymore. The bing imagery is outdated.
Thanks,

Cześć - budynki, które dodałeś w centrum handlowym "Ogden Mall" (pomiędzy Iroquis Ave i Naperville/Wheaton Rd) zostały usunięte z mapy, ponieważ zostały one zburzone ok. rok temu. Jest tam teraz nowy budynek (sklep CostCo).
Prosze nie dodaj tych budynków ponownie, one już nie istnieją. Zdjęcie lotnicze bing jest nieaktualne. Dzięki.

This is great, thank you!

Hi - thanks for getting back on this - that makes sense.
Yeah, if you don't mind closing the gaps in Ashwood park based on the imagery you have, that would be fantastic. There's a bunch of gaps a little north of the one you closed already; some on Carpenter Rd and Laceback Lane; and two or three just south of 111th (Little Leaf Rd / Christa Dr).
Thanks for your help, it's much appreciated!

Hi - I saw you closed a gap in the sidewalk on Shumard Ln (between nodes 8911835667 and 8911835666) is there a publicly available image source that's based on? Asking because all the imagery I could find shows either brownfield or construction, but nothing that actually has that stretch of sidewalk (yet).
If you found better/more up to date imagery somewhere, I'd be thrilled if you could share where to find it...I've been mapping tons of houses and sidewalks in this general area and left quite a couple of gaps where stuff wasn't there yet at the time the bing/mapbox/esri aerials were taken.

Thanks!

Yeah, I get that the app alone isn't enough, but you also have to link a credit/debit card or other payment form to apple/google pay.
The reason I'm struggling is something I read about Walmart not too long ago - I don't regularly shop there myself, so this is just hearsay: Apparently they have something called Walmart Pay - However: Their system appears to be incompatible with google pay and apple pay. In other words: You can pay with WalmartPay in their stores, but not with ApplePay or GooglePay. Now this may not be a perfect example since I believe it is based on QR codes (technically still contactless, I guess; but in a different way for sure).
I believe that SamsungPay is special too since they use MST in addition to NFC.
Are you saying that a merchant accepting any form of contactless payments is guaranteed to definitely accept both google pay and apple pay? If a place supports MST transactions only (no NFC), payment:contactless=yes would seem appropriate (bc of Samsung), but neither applepay nor googlepay would work. What am I missing?
And, in addition, doesn't the payment provider decide what they process vs what they don't? Similar to both Visa and Discover using EMV, but some places only accepting the one or the other, depending on the agreements they have with their payment providers?
Sorry for asking so many questions, this is super interesting.

One more thing on the brand tags in ID - I found this comment dating back to January, stating that the list just appears to be shipped as part of a new ID release (that would explain why you don't see the updated tags right away):
osm.wiki/Talk:Name_Suggestion_Index#How_soon_will_iD_receive_data_updates.3F

Tagging the generic "payment:contactless" in addition certainly won't hurt; I'll do that going forward (and, looking this up on the wiki, at least the apple entry explicitly says to also tag payment:contactless).
Are you 100% sure that a place accepting contactless payments (the generic) necessarily implies that they accept both, google pay and apple pay though (and any custom wallet app somebody may have thrown out there)? That seems counterintuitive - the payment provider clearing the transactions on the merchant's behalf could accept the one but not the other, no?

Mmmh, before I change it, do you have an example of what you mean by "cargo docking bay" and/or how you see that as being different from a ramp? I'm not sure if we're talking about two different things or just using different verbiage for the same thing.
The way I interprete the Esri (Standard) imagery is that this is concrete, slightly sloped towards the building (that is, the southern end touching the asphalt of the service road is the highest point; the northern end touching the building is the lowest point (below ground level, actually). See the shadows on the right side little (diagonal) retention wall. The darker asphalt to the left of that doesn't appear to be a shadow cast by the building, but maybe patched asphalt (see the direction of all other shadows in the area).