Rather than simply deleting these tags, it would have been better to convert them to better ones where possible. For example, it appears that a lot of these had their ICAO code tagged under the IATA key, so the key just needed to be changed. While they may have been incorrect IATA codes, they were correct codes of some kind, but now you've deleted them entirely. That isn't an improvement.

Hi Teholio,
I'm not completely sure what you were trying to fix here. I'm not aware of there being any issues with either the Colwood boundary or Colwood Creek Park, which were both working correctly in my system using OSM data (building maps for a Garmin GPS). The only change you made to the Colwood boundary through your changesets was incorporating an address interpolation node into it, which I've removed. You also created multiple relations for Colwood Creek Park and you removed a couple of pieces of the park from the east side of VMP, so I've fixed those. Outside of this area, you added multipolygon relations for parks which were only described by a single way, so the relations were unnecessary and redundant and have been removed. I've checked all of these parks just now and there are currently no issues with any of them. If the data is causing issues in some other application that's consuming the OSM data, it's that other application that will need to be fixed.

Please don't use the main OSM database for fictional edits. Any such edits should be made in your own database or one intended for fiction. This changeset will be reverted.

It was on the map... right in this spot. I've removed this duplicate object.

@maraf24: Please don't attack other contributors over relatively minor issues. There's no way we can guarantee that every changeset is perfect.

"Fixing bad edits days later is not expected course of action."
It most definitely is. That's at the heart of how OSM works. The standard process in OSM is that the data is iteratively improved over time. Setting the bar so high that the data must be perfect from the start would prevent most mapping from occurring at all.

Most areas have errors that can sit for years before someone fixes them. While you may consume the data hourly, most consumers of the OSM data don't, so a small, local error being present for a few days is not so big an issue that an entire changeset needs to be reverted or the contributor reported to the DWG.

This changeset duplicated this Staples location that was already mapped as a node (which was also edited in the changeset immediately prior to this one). The area that was added also seemed very messy and wasn't in the location of the actual store. I'm not sure what the goal was, but please make sure you don't duplicate existing features. I've removed the area, so this Staples location is again represented by a single object.

Please stop vandalizing the map. Any of these changes you make will be reverted and continued vandalism will be reported to the Data Working Group.

You're making changes to the main database that don't appear to be legitimate. Please don't use this for testing. I've removed your invalid changes.

You're making changes to the main database that don't appear to be legitimate. Please don't use this for testing. I've removed your invalid changes.

This Tim Hortons was already mapped just 10 metres south of where you added this node. I've merged the tags from this one to the existing node and removed this duplicate node.

I took a quick look at a few of your other changesets because the changeset comments are very similar to some other recent edits by other users in this same mall. It looks like you've duplicated existing objects in several places across North America. Please make sure you check whether a business has already been mapped so it doesn't get duplicated.

It seems like you may be part of a company with staff adding objects across widespread areas, so please pass this feedback to your supervisor and colleagues. Thank you

I just went through this changeset and your other earlier ones to clean up quite a number of issues around southern BC. These included:
-objects that duplicated ones that were already in the database
-name:en that didn't match the name tag
-objects with tags that didn't correctly represent the real-world object (e.g. amenity=bus_station for a bus depot)
-objects that exist, but in a different spot than mapped
-objects that don't exist in reality (e.g. amenity=childcare in the middle of some greenhouses)

I fixed or deleted any objects that I could verify or were obviously wrong. There were some other objects that I wasn't able to verify through other sources, and I'm a bit skeptical about some of those, but I've left them as-is.

Before submitting changes, please try to do the following:
-ensure that the object doesn't already exist in the database
-ensure that the tags you're using best-represent the real-world object
-ensure that the location in which you're adding an object is really where it is
-as has already been mentioned, try to upload groups of changes in smaller geographical areas, rather than a changeset that spans North America or multiple continents

Thank you

I'm curious what your source is for this? It's my understanding that UVic's address is 3800 Finnerty and that covers the entire property. If that's true, then each building doesn't have its own address. You also haven't added a addr:street tag, so it isn't clear what the full address would be even if this building does have a housenumber of 9882.

I haven't been able to see any signs indicating this is exit 5, and it has never been numbered before. What was your source for this?

Try to upload your changes in smaller areas, like one for the changes in California, one for Alaska, etc. This changeset and some of your previous ones have covered massive areas and show up on QA tools for widespread areas when they don't need to.

Something you're doing keeps putting buildings way up in the Arctic Ocean. I would recommend figuring out what's happening to cause this before adding any more.

way/757045771 was created way up in the Arctic Ocean

Please stop doing this. Such a massive change needs to be widely discussed with the global OSM community. The community will not allow you to be the only one to decide on this major topic, so there's no point trying to impose your personal opinion. You're just wasting everyone's time.

Translation:
Bonvolu ĉesi fari tion. Tia amasa ŝanĝo devas esti vaste diskutata kun la tutmonda OSM-komunumo. La komunumo ne permesos al vi esti la sola decidi pri ĉi tiu ĉefa temo, do neniel penas trudi vian personan opinion. Vi nur malŝparas ĉiun tempon.

The hotel/motel has been mapped since 2012. I've merged the relevant address information into the existing object and removed the duplicate node.

The small flares where the road joins the cul-de-sac imply physical separation (ie. an island), but there isn't one visible on aerial imagery. If there isn't any physical separation, the road should just join the cul-de-sac directly. Likewise with the other nearby roads. If islands have been installed since the aerial imagery was taken, you can ignore this comment.

Ah, I understand. For cases like this, building:part is indeed what should work best. The two large pieces of the building would be building:part=yes and building:levels=4. Each balcony would be building:part=balcony. In addition, you would map a single way overlapping the outer limits of all of these, and this is what you would tag with building=apartment and all of the address and name tags (no building:levels, though, because that is already on the relevant parts). This way, you only have a single object with an address, and there's only one building=* object rather than a number of them. This would best represent reality, because it's really just one building. Unfortunately, this still doesn't allow us to tell data consumers that one of the parts is offset vertically compared to the other, but I honestly don't know of a way to indicate that. We may just have to accept that there currently isn't a good way to do that. You could add a note on the building object describing the layout so someone can update the tagging if a good solution is later found.