I passed by today and confirmed that these ways don't actually have a name in real life. I suspect these are considered interchange/exit roads as part of the highway. The fact that Google Maps calls this "Swartz Bay Road" is simply another of their countless road name errors. I've removed the name and tagged these ways with noname=yes.

These garden beds are tagged with letter names, which seems unlikely. Do these beds really have these names or were these mistakenly imported?

Are you sure there are two separate buildings here? They've both been tagged with exactly the same tags, so they should probably be joined together into one building.

I'm fairly certain the overpass and approaching ways don't actually have a name. I only now realize that they've always had a name in the database, but I think that's an error. I'll double-check the next time I'm out that way.

Hi mardil10, it looks like a copy of the roads and stops for the 81 got shifted and uploaded (see here: https://overpass-api.de/achavi/?changeset=76021561&relations=true). I've cleaned up the duplicated objects but kept the valid stops you added.

Some of these clearly don't fall under the category of craft=*. I've now reported you to the DWG due to your massive number of mechanical edits and your failure to communicate with other contributors.

This user is performing a massive number of mechanical edits all over the world. They need to be stopped immediately.

I'm sorry that you feel my edits are vandalism. I assure you they aren't, and I make it a point of monitoring the southern part of the island for true vandalism or damaging/misguided edits. To show you that I have the best intentions, I previously agreed to not fix the many duplicated addresses you've been adding in Esquimalt because you didn't like what I was doing, and I've stuck to that plan despite a strong desire to fix the issues.

As for these areas, they are definitely not administrative boundaries in the context of OSM. An OSM administrative boundary is one that defines a geo-political entity, such as a country, province, municipality, or neighbourhood. The areas changed in this changeset - watersheds and arbitrarily-named woodland areas - don't fall in this category. The way they were tagged with boundary=administrative and admin_level=10 indicated these were neighbourhood areas, which is obviously not true. There doesn't seem to be a good way to tag watershed areas documented in the wiki, so the best we can do for now is just leave them as boundary relations. If a good tagging scheme gets devised for watershed areas, by all means add it to these relations.

Feel free to comment on any changesets where you feel I may have made a mistake and we can have a discussion about it, but please try to keep things clean and don't just assume that anyone who makes changes to things you've edited is a vandal.

Google Earth isn't allowed for editing. Please revert this changeset immediately to remove any data that doesn't comply with the ODbL license

From what I understand of the proposal, the result when complete would best be mapped as highway=living_street, so highway=footway wouldn't be used anyway. We can give the original contributor a bit more time to explain, but then I agree that the footway should be removed, especially if there haven't actually been any changes on-the-ground yet.

This is a fairly major change, and one that should be discussed. The BC regional districts have been tagged as admin_level=6 since their creation. Why are these three now being changed to 5 (and none of the others)? That level seems to be generally used for groups of districts or counties, which doesn't fit here. On a lesser level, it breaks the smooth mapping of 2=country, 4=province, 6=regional district, 8=municipality, 10=neighbourhood, which allows for edge-cases to fit in between. There may be a good reason for this change, so I'd just like to know more so I can adjust my mapping if necessary.

The footway you created is overlapping Kings Road. Has this section of road been closed and changed to a footpath? If so, that section of Kings Road should be removed so cars don't still try to drive down it.

It also reuses node IDs from 13 years ago for no apparent reason. This seems like something that wasn't intended to be uploaded and should be reverted.

I'm just curious, but what was bogus about the Lockeport data? Have most of the buildings in Lockeport been demolished? I couldn't see anything fundamentally wrong with the data.

Can you explain what in that wiki article led you to do this? As far as I can see, the documentation indicates that place=country is used on nodes, and we already have such a node in place for each country. In the case of Canada, we now duplicate objects tagged with place=country (see node/424313760), which is something that most agree should be avoided.

Are you sure about these changes? I mapped out the locations of these signs when I was hiking in the area last year, and now they're indicated as being located in the middle of the trails. That doesn't seem to make sense semantically or match the on-the-ground reality.

The tagging you changed this to indicates that nobody is allowed to use this ferry route, which clearly isn't true. I've restored the access tags that indicate this ferry can be used by motor vehicle, foot, and bike users, which reflects the reality. If a planning app is using this ferry route incorrectly, it's the app that should be fixed.

My comment on changeset/68644323 applies here too. Please pick either the node or area to put the address on, and remove the other. Duplicated addresses would be considered an error, and someone else will come along and fix this even if I don't (which I won't for now, because you seem to see me as a "vandal"). See "One feature, one OSM element" for more information: osm.wiki/One_feature,_one_OSM_element

There was no vandalism here. I only removed address nodes that duplicated addresses already tagged on residential areas. An address should only exist once. Now that they've been added again, there are duplicate objects for each address. If you prefer having the address nodes, then the address should be removed from the respective landuse=residential areas.

I've reverted this changeset because the same issues from previous imports are still occurring. Please make sure you put in the necessary effort to ensure:
-The data you're adding fits with the existing data
-You don't mass-delete and replace data unnecessarily
-You clean up any errors created by your edits
-You clean up extraneous foreign tags before uploading
I've advised you on several recent changesets of many issues, but you seem to keep doing the same thing and ignoring all advice. Since the net result of this changeset is basically just the addition of a (duplicate) Galloping Goose park relation, I've reverted the entire thing to clean up the various other issues that were created as a result. Feel free to import this relation again as long as you deal with any issues before uploading.