Check spelling of "Parker Cemetary"

way/1084830875 Here you added a building that does not exist and never has (at least with a shape anything like that). This was a randomly chosen building from your edit. The error rate is almost certainly higher than 0.015%.

Here is another one. way/1084799272

And another: way/1084896383

It is not hard to find these. I just click on a random way from this changeset, then look at nearby buildings.

Here is a single house represented by three buildings: way/1084884000

Here is a building that no longer exists: way/1084818808

Here is two buildings mapped where only one exists: way/1084879822

Here is a total nonsense building: way/1084771389 (it has a neighbor that is similarly bad)

Here are two buildings mapped as one: way/1084853034

Here is an attached garage mapped as a separate building: way/1084799013

I could go on, but there are two possibilities here: your "manual review" is bad enough that your data quality is harmfully low, or you lied about manual review. You tell me which is the case.

These appear to be Bing footprints. Consider using the MapWithAI plugin (https://josm.openstreetmap.de/wiki/Help/Plugin/MapWithAI) instead. And as archpdx said, unless you are manually reviewing every single building, you need to go through the import approval process first. You can't rely on other mappers to "fix if there is a problem"; there shouldn't be one in the first place.

kepivar is almost certainly a sockpuppet of some experienced user.

Please orthogonalize the buildings before uploading by pressing Q.

As I have figured out a reliable method to catch all of these errors before submitting the changeset, future changesets will just be labeled "conflation". Note that this method does not work in areas with mixed housing (read: older parts of towns).

No errors introduced this time. I didn't end up doing any bulk moves because the vast majority of the address nodes were already inside the homes. One building was accidentally marked as detached that I corrected before uploading. One preexisting error was also corrected. Note that I did not download 54 buildings added by another user that were tagged generically as building=house. I conflated them in iD in changeset/125495369.

This section should be complete. There wasn't much left to begin with. I figured that conflating one-by-one in JOSM isn't actually much harder than in iD. There were so few that couldn't be done automatically that it was sometimes faster to do this than to bulk move the address nodes.

By making sure I do everything in JOSM, I also avoid accidentally marking garages as detached. I purge them when I see them, and I automatically filter out any buildings less than 100 square meters, but I missed three. This time, I caught them before uploading.

I discovered one error while still in JOSM and corrected it there. I found four more errors in my cleanup, done in changeset/125482353. This means the error rate is similar to my previous edit like this. To mitigate it, I may need to manually review the area before even downloading it in JOSM. The problematic areas are streets that meander so significantly that their predirectional is "wrong", and short cul-de-sacs that don't have their own name or predirectional. When bulk moving the address nodes, these are moved in the direction of the wrong house. To avoid this, I will manually conflate buildings on these cul-de-sacs and on sections of streets that run contrary to their predirectionals. This should add minimal time to the process while hopefully avoiding all errors.

Thank you for the addition, but again, please use better changeset comments. They don't need to be complicated; "added driveway" works fine here.

I uncovered two more errors from a thorough check. One of them was a manual mistake, so I would conclude that in these mixed areas that represent much of the remaining conflation the error rate is 0.5% and easily fixable. All things considered, I was able to conflate about 1,500 buildings in an hour and a half. I imagine that with the experience gained I will be much quicker in my next attempt.

After marking all detached houses as such, I downloaded only those that didn't have an address node inside them (which can be conflated automatically), then for each combination of predirectional and address parity, I moved them in bulk in the direction of the houses, hopefully enough for them to fall within the outline. About half of these were able to be conflated after a single move. I then looked at what was remaining, and again moved them towards their respective buildings. Any that I was unable to conflate by this method, I purged to ensure they would not be moved in the dataset.

Unfortunately, four errors were introduced here. However, these can easily be spotted, as there will seem to be both an extra address node and a house with no address. I corrected them and conflated what even this method missed in changeset/125459918.

This method is more effective than conflating by hand. Though it is not massively faster than conflating one-by-one (no more than twice as fast), this method also results in buildings being tagged in more detail. Additionally, the work is far less menial, because many buildings can be selected with a single drag and they can all be marked as detached, and dozens or more buildings can be conflated with a few clicks.

This method only really works in areas with low setbacks; in Eagle, many nodes could not be moved far enough to be conflated without also moving nodes over a far enough distance to be conflated with the wrong house. It is essentially useless in low-density areas where nodes are often placed on the center of properties, particularly farms. It will almost always be necessary to conflate these manually. Fortunately, these represent a small fraction of the homes in Ada County, and I have already done many, if not most of them.

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.