You're clearly copying information from Google, complete with typos like a street of "Trans-Canada Highway A". I've reverted this change because you've used a source that isn't allowed. Please stop doing this. If you continue to make changes using Google data, you will be reported to the Data Working Group.

The name of this house is "Shirlea". That wasn't any kind of personalization. Also, "335" isn't a name, it's the address. I've reverted this back to the way it was.

Can you clarify why you removed the island tag from Banks Island in northern Canada and replaced it with the "area=yes" tag? The island is now no longer tagged as an island.

Since this change could cause a number of issues for data consumers, I reverted the changes myself in order to minimize the chance of any negative impact. I also found that the osm.wiki/Canada_admin_level article didn't accurately reflect the situation in BC, so I updated it accordingly.

One example that I saw still hasn't been fixed:
node/1042023589
In that case, a valid ICAO code had been incorrectly tagged in the IATA field, and then subsequently deleted entirely by you. This hasn't been fixed by your latest changeset. This is the kind of thing that needs to be restored, as well as any others in a similar situation. If you aren't sure whether the code is a valid ICAO code or not, I would suggest that restoring the IATA tag as it originally was would be preferred, since the data would then at least be present and someone else can later fix it as necessary. At the very least, some placeholder tag like airport_code=* could be used in order to retain the data.

It's up to you. You can either revert all of the changes and then make the necessary corrections, or keep the data as-is and add back any data that had been removed but can be made correct.

This is a type of change that needs to be discussed more widely. The regional districts have been admin_level=6 since they were created, so changing them all to 5 will likely cause issues for data consumers. The regional districts are the equivalent of US counties or UK counties/council areas, which are also admin_level=6. If you have a good case for our regional districts to be changed to a higher admin level, it should be made in the Talk-CA mailing list so others can discuss the merits. Until there's general agreement, these should be changed back to admin_level=6.

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?