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

Where is this import documented? In the future, it would help to link to documentation in the changeset comment or a tag.

Apologies, most of my comment was written before I knew this had been reverted. References not made with this knowledge may be disregarded.

Let me try this again. All you've said has failed to address that this is an import. Regardless of whether or not you believe the rules about imports are justified, you cannot import data without prior proper discussion. There is currently grounds for any user to revert your changeset. It is likely that the Data Working Group will do so. Before I address any of your concerns, I must remind you that you are already in the wrong.

I have specifically chosen not to revert this changeset because there is something you can do to fix it. I can rescind that offer at any time. I would be in the right to do so. It is merely secondary that your data isn't as high quality as it seems. This is not an attack on the dataset. I am suggesting that the way you mapped the other dataset onto OpenStreetMap is incorrect. It does not matter how insignificant the issues are, you should never knowingly introduce incorrect information into the database for any length of time. It is far easier to add new correct information than to notice and fix existing information.

For this reason I can only accept that you either get a proposal approved to import this data as is, or correct the data. Neither the amount of time this takes you nor how efficiently that time is spent is of any concern to anyone else. There is no requirement that you must add this data to OSM.

As another user has already reverted the changeset, I will not press you any further. I would certainly offer my input if you decided to start the process of properly importing the data. Know that I will raise the same concerns I have here, and just stating that you disagree with them and with other opposing comments will result in your import being rejected.