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.

This is another changeset that required quite a bit of cleanup. This included more foreign tags that should have been removed, untagged nodes and ways, duplicated objects, and incorrectly deleted link ways. Please reply to this comment to acknowledge that you're reading these comments, because I'm seeing the same issues continuing to occur. Also, please try not to mass-delete and replace objects, and instead modify existing objects when possible.

The Salt Spring Saturday Market doesn't have a permanent building, so I removed the building tag and fixed the opening_hours

Hi Robert. Sorry, I missed seeing this comment earlier. A number of the multipolygon relations in this area had small no-man's-land gaps between separated outer ways with a natural=ridge way running in between, rather than sharing ways. I modified these to use the ridge ways where applicable as the outer ways, shared by adjacent relations. This eliminates the small gaps where nothing was tagged. I believe there were also a number of small untagged ways inside these gaps, which I couldn't see a reason for and removed.

Hi Robert. Until the trees grow up to a reasonable height, the land in those areas best fits a "scrub" description (ie. low bushes and trees). While maybe not perfect, this is the best fit within the current set of typical OSM landuse tags. These were previously tagged as industrial, which certainly isn't correct for a remote logged area of land with no industrial activity after the relatively brief initial harvesting period. If it's a relatively short time until the area looks like forest again, then it might be best to just not exclude them from natural=wood multipolygons so they're mapped as natural=wood. I may think about doing this for some other logged areas on the south island.

I cleaned up after this changeset and your other previous ones in the area. This included removing foreign keys that were left on imported objects, removing untagged objects, and fixing tagging on various objects. Please make sure you use the JOSM validator to fix these issues before uploading. I'll be going for a walk today to verify the existence (or lack of) of the supposed fences in this area.

This has left the area in a bit of a mess with overlapping and untagged relations and fences where there definitely aren't fences. The Mary Hill military area also now extends much farther than it does on the ground. I've looked at the parcels in the past, and they simply don't match up with what's happening on the ground with regard to Pearson College and the Mary Hill area. The previous state in OSM was the best ballpark I could come up with to reflect the on-the-ground reality. I think the long "finger" of Mary Hill that now extends to the north of the college and across the Goose at least needs to be removed, because that definitely isn't part of the military area, nor are there fences there. The various "parcel" relations in the area also need to be cleaned up and merged with the coastline where applicable.

What source did you use for this? Both BC provincial park data and CRD data shows the Gowlland Tod boundary meeting the Cal Revelle boundary at a right angle like it did before, not at an angle like this.

Whoops, never mind. I see you reverted the name back a little while later. Sorry. :)

I'm curious why you swapped these names. The source stated on the changeset is GeoBC, but they use Saltspring, not Salt Spring. The BC Geographical Names database (http://apps.gov.bc.ca/pub/bcgnws/names/13666.html) also uses the 1-word form. Since local usage is fairly evenly split between the two forms, it makes the most sense to use the name considered official and used by the government.

Please don't create fictional data in the OSM database. You should use the sandbox database or set up your own database for testing. I've removed the fictional data around 0,0

Can you please explain what the source of your changes was? It seems like you changed some populations based on some unknown source, and incorrectly changed the place type of a few places.

...and I agree that meaningful changeset comments would be greatly appreciated.
#a #big #mess #of #hashtags #doesn't #tell #us #anything #especially #ones #that #are #seemingly #random #8532 #jhdks899

This is a sports field, not just a grassy area, so I've changed this back to leisure=pitch

The general rule is that the name used "on-the-ground" and/or the one most commonly known by locals should be the one used in the "name" tag. This would be Mount Newton, so I've restored that name to the "name" tag and tagged ȽÁU,WELṈEW̱ under "name:sal" (the closest related language code to SENĆOŦEN)