D'oh! You're absolutely right, it should have been. The correct tag slipped my mind at the time. I have fixed these. Thanks!

Thanks for adding the different wings of the school. However, adding a feature with "area=yes" on it is generally not very useful unless it includes other tags. In this case, you could split the school feature and add these wing designations as a ref tag, or else add building_part features inside of the main building feature.

This is a residential area, and is seems very doubtful that JNS Glass is actually operating here. Can you please elaborate on why you think this feature should be here?

US 30 and 34 had a bunch of issues. 30 is fixed now, though, and I'll probably work through 34 today.
Sounds like they were broken before you got to them, then. The curse of being the last modifier, I suppose.

It's possible they were broken before you got to them, too, I didn't do a deep dive on the history. It just seemed similar to something I did in the past.

Nice to see all the lane attributes getting added, but are you by chance loading the features w/ an Overpass query? I ask because a bunch of route relations whose member ways you edited got broken, and I have done that very same thing with lane tagging and sparse editing in JOSM.
There's a way to modify your query to tell it to "recurse up relations" and get any relations that the downloaded features belong to, which would avoid this sort of thing.

What was the conflation process, exactly? Oswego, IL, for example, has 4 existing fire stations, all of them in OSM already, and none in the location imported by this changeset. Aurora, IL also had a duplicated station node, and that's just things within a few miles of me. I have to assume with a 2-changeset country-spanning import like this, there are going to be a lot of similar situations.

I get that, and sometimes that's the case. In my opinion, the business is not the building, it just happens to be using the building. Handling business entities as areas introduces a lot of complexity and arbitrariness.
To pick two examples outs of this changeset: suppose I am out in the Menards lumberyard area, or eating at the Chick-fil-A outdoor seating. Have I left the "place of business"? Not really, no. But how do we map that out? Does it stop at the parking lot, or include that, too? Are we just mapping parcels at that point?
It's worth pointing out that there's no rule that a business area has to correspond to a building. Mapping the "place of business" as an area independent of building features is actually how some mappers are addressing multi-business buildings like malls.
It doesn't help that iD has `building=yes` built into a lot of the business area presets.
It's OSM, so, y'know, do whatever you want! I just feel that maintaining businesses as POIs is clearer, easier to maintain, and sidesteps the entire issue of "how many businesses are in the building" and "does the business operate outside of the building".
Final point: keep in mind that having one POI just means there's one POI *mapped*. The Target near me has an optical store, a Starbucks, and a CVS inside, each operating independently. Or in downtown Yorkville, many of the businesses are just the first floor, with apartments above. To say the building itself is the business is inaccurate. But a point that says "this business is here", that's correct!

Hello, fellow mapper! Thanks for doing some much-needed cleaning in the area.

Is there a particular reason to merge business POIs into the footprint geometry?

Looks great! Thanks for adding this kind of local knowledge to the map!
Just a heads up, though: you (probably unintentionally) edited a boundary feature. In iD, you can go into the settings and turn those features off to avoid accidentally snapping to / moving them.

Hey! Nice to see someone editing around my old school. Do they still have the plaques up for the tree dedications? You could totally add that information.

What is the purpose of moving these buildings? The features were added with known imagery offsets for this area; moving them slightly to the NW actually makes them less accurate.

Oh, I do like that sub-area style. I think combined with an appropriate `indoor` tag could lead that to being very high-quality data, while still being accurate with respect to the building itself.
Looking on Taginfo, there does appear to be a modest overlap in indoor=* and shop=* (often with level=*, too). Well, I'm sold. I may try to replicate the style you've achieved at the Outlets with added indoor tagging around me. Thanks for the inspiration!

For multi-building situations, it's kind of a toss-up for me. A building MP still implies the business == the buildings. I know that in the case of hotels, it's acceptable to tag the hotel's "campus" with the tourism tag. And really, there's no rule that a `shop` or `amenity` feature must correspond strictly to a building. I'd be curious to see how users would react to the idea of a business way that covers the business' area rather than simply the building. But that's not a discussion for a changeset comment. I'll ping you on Discord and see what other users think about that.

Based on the raw numbers in Taginfo, only about 20% of all shop and restaurant features are combined with a `building` tag. In other areas I've edited, I tended to see more businesses as POIs than closed ways, which led me to think (perhaps mistakenly) that there was a "more common" approach. When you filter those features for ways only, though, nearly all (>90%) are combined with a building tag. And that's just globally, so it doesn't catch any regional differences.

Personally, I will probably still default to POIs unless I have the local knowledge to know that a building has no other use, or for strip malls, know where the internal dividing walls are roughly located. But I'll stick to either local knowledge edits or adding what's missing from here on out, so that I'm not just keeping other users like yourself busy.

Thanks for the feedback!

Sorry, I just remembered an additional point: some single businesses encompass multiple buildings, too. Tagging only one of the buildings w/ the business information can't capture that either. Not that a POI would, but it at least wouldn't imply a single building as being "the" business.

D'oh! Bonehead mistake on my part! Sorry about that, that was just sloppy.

Hi there!
In my mind, it's simpler and more consistent to go with business as POI, building as separate way. A building is often only *part* of a business, not unlike a school building is only one part of a school.
Consider basically any food or drink establishment with outdoor seating; the diners outside are not considered to be somewhere other than the business they're patronizing.
With large strip malls, there's often just one actual building, so splitting that up at the interior walls into a series of connected buildings is inaccurate. It's *one* building, it should be *one* feature. POI mapping of businesses is the only way to accurately map multiple businesses/offices/amenities in a single building.
Additionally, businesses can move! If I decide to terminate my lease and move my shop across the street, it's literally the same entity, but in a different location. POI mapping allows for this kind of "entity continuity" in a way that building-based mapping does not.
I'll concede that this can lead to duplication of address information, particularly in cases of 1:1 business and building situations. Perhaps those 1:1 cases can be left as is, but I personally prefer to keep all businesses as POIs for consistency.
As a small-time end-user of OSM data, it's *much* easier to ingest and make use of data that is consistently in a single format (dedicated points vs areas w/ non-business tags). Yes, I can just take the building centroids and get roughly the same thing.
From an editing perspective, I can easily load and edit larger numbers of businesses as POIs than I can as ways, so it makes it easier for me to maintain the business data in my area, something I want to make a greater habit of doing.

I suppose I've gone on long enough. You're free to disagree with any and all of the above. I was just "cruising" up Rt 34 and kept going out of Kendall County and did some mapping there. But I will always defer to what local mappers prefer in their area, so I will not be offended if you choose to revert this changeset (or any of the similar ones in the area).

Nice additions! Just watch out, it looks like one of the sidewalks snapped to a boundary feature. Unless you're actually meaning to edit boundaries, it's usually best to go into iD's settings and uncheck the box so that those features don't display. Other than that, it all looks great!

Hey there! I always appreciate folks trying to work on admin boundaries, especially ones that are straight-up missing from OSM. I was out of town, else I'd have noticed this sooner, but this isn't quite how admin boundaries work.
Forgive my presumption, but I'd guess you probably just didn't know quite what you were doing with JOSM's relation editor?
I'll probably start a thread on the Discord server to walk through this when I get a chance, but some notes for the time being:
1. Admin boundaries should be relations, not ways.
2. The relations are made up of member ways that are often shared with *other* relations. Such as the eastern boundary of Township A is the same way as the western boundary of Township B.
You've already imported the townships as ways, so there's no need to remove that data; we can use it to build the proper relations. I'll ping you on Discord when I do that.

Cleaning up boundary relations is a task too often overlooked. Thanks for doing this kind work!

1. I digitized them from hi-res imagery (~3in. pixels) so I think they were pretty well mapped, but I am doing this from a ways west of here, not in person. If you feel you are improving them, then by all means do so, but just edit the existing feature.
2. I thought I removed the building tag from the fences, my mistake.