Appreciated! It doesn't matter much, since it's not being displayed, but technically that name is still being used as a description. See the wiki for more info: osm.wiki/Names#Names_are_not_for_descriptions

Hope this helps.

I would suggest removing any buildings from the relation where an outer way is drawn around them, then changing other buildings where only the building itself is part of the campus to have an outer role. Data consumers don't understand any other multipolygon roles besides inner and outer. Hope this helps!

Thank you for the data, but proposed=yes is an example of a trolltag. Data consumers may not recognize the tag and think there is a real park there. The name is being used as a description, which is also incorrect. The feature should be tagged proposed:leisure=park and the current name should be changed to description.

There are unique tags (and presets) for many of the features here. It isn't correct to tag them as things like grassland.

Ditto for trees, which should not be tagged as woods unto themselves. natural=tree does what you're after.

Not sure what is meant by natural=golf. And there is a tag for golf cartpaths. Bare rock is for natural features only. Try to map as just a line. You can map the area if you like but that requires a more advanced tagging scheme

If you are not sure of the proper way to enter data, leave a note. Better to have missing data than misleading data.

Thank you for your edit! Please square the buildings by selecting them and hitting 'Q'. Also, the garage should not have an address tag. Only one feature should have a particular address on it.

"South Highway 170" is the correct name. Mail is addressed on that street name. It does not matter if your software is malfunctioning. Also, Google Maps is full of errors, sometimes even more than OSM.

Canby-Marquam Highway should be alt_name, and South Highway 170 the name. Hope this helps.

The zip code is 83642, not 83716. The address was already in the database, just not the business info. It is better to add the info to the point that already exists. This time I fixed it for you. Thank you for the addition.

It looks good to me. Thanks for conflating these.

If the house is not connected to any others (as most are here) it is preferable to use building=detached. Notice that there are tens of thousands of building=detached in Ada County. Still, building=house isn't wrong, it's just not as informative.

It's Grosbeak, according to the county assessor.

Please expand the road suffixes fully. It is standard practice on OpenStreetMap because it is easier to shorten them than to lengthen them, like when they are ambiguous.

That should not happen. Red errors usually only appear for untagged features (not just no name, but nothing to indicate what it is). If it happens again, it would be great if you could screenshot the issue and submit a bug report here: https://github.com/openstreetmap/iD/issues

There is no bridge here. If you look at aerial imagery you can see a culvert. It seems like this edit was just an attempt to suppress an error rather than correct the data.

Places on military bases are usually tagged access=no, not access=private. Essentially indicates the difference between "sued by private citizen/corporation for trespassing" vs "arrested/shot by government for trespassing".

I don't support adding Bing buildings without prior proper editing or a commitment to systematically reviewing the buildings to improve their accuracy, or intent to conflate them with another dataset. Unmodified Bing footprints in the dataset don't really benefit people that much. If someone really needed them, they could just download the Bing data and the OSM data and combine them in their own database. I am dubious that the footprints are so accurate that you can evaluate so many so quickly and make accurate judgments. I am familiar with Bing footprint quality and it is very much a shot in the dark. Still, my opinion doesn't matter until a discussion is had on the import, but this never occurred. And there's the issue.

"Bldg #" does not belong in the name tag. You should add the tag ref=* and set it to the building number, and delete the name entirely, because it is not a name but just a numerical referrer. Hope this helps.

There is no sense in giving feedback to these mappers. They always have just one changeset adding their business with unrecognized tags. It is likely an SEO service that is abusing OSM but remaining undetected by using different accounts for every edit. That is my only explanation for why all of the edits look exactly like this.

That is not an import documentation page. You did not use RapiD for this changeset, but furthermore the very top of the page states: "
Adding buildings or roads or any other objects through RapiD without properly reviewing every single one is considered an import and therefore must follow the import guidelines." The fact that that entire group of buildings is inaccurate suggests that they were not manually reviewed. No one accused you of not reviewing *anything*. That is a strawman.

And if you reviewed over 130,000 buildings in two hours, that's twenty per second. That is literally impossible. This must therefore be an import, and an undocumented one at that. It'll need to be reverted.

I presume you are already aware, but just in case: this is entirely unacceptable conduct for an OpenStreetMap user. These comments are seen by anyone for as long as OpenStreetMap exists. It seems you are projecting your own lack of sincerity onto another user and lashing out at them for it. You are making no attempt to reach a resolution to this dispute and therefore believe that others are doing the same, and commenting only to antagonize. There is more to being a good member of the OpenStreetMap community than high quality edits. If you can't respect that, you shouldn't edit. Thank you.

Reverted in changeset/125243471