Hi, please consider more useful descriptions in the changesets... Thanks for the contributions though!

Nice one, precisely what I was planning to edit.

Hi JKobbero, you flagged this changeset for review. Looks pretty good to me, just a couple comments: 1) The way ends just short of the intersection with the rail trail - best practice is to end ways at intersections, or where the attributes change. This will help avoid unexpected consequences when routing.
2) While "FSR" can be common usage in some circles, names should always be spelled out in full. osm.wiki/Abbreviations

Thanks, happy mapping!

Hearing no reply, I am proceeding with reverting this changeset.

Hi Dave, I couldn't help notice that a big part of this changeset was to change all the bicycle=yes tags to bicycle=mtb. This is not a correct use of the tag ... bicycle=* tag is meant for legal restrictions to bicycles, not what type of bicycle to use on the trail. Please see the wiki bicycle=*

Why did you decide to do this change?

Hi, This edit is pretty clearly in error - there are no nordic trails here. I was about to revert this changeset, but wanted to reach out and find out what you were trying to accomplish with this edit?

Yeah it's exactly at the start of the washout.
New edit here: changeset/157680352 Might take a while for the map tiles to update.

Oh interesting! Ok good on ya for using GPS tracks, sorry I jumped to conclusions. Let me pull up my tracks from last week and see. It's likely that GPS reception is weak/inaccurate in that tight valley, could just be bad GPS jitter on either/both our tracks.

Hello, I see you're new to openstreetmap - welcome! Unfortunately this edit doesn't really meet the standards for OpenStreetMap, so I've reverted it. Please make sure you are mapping features that are actually on the ground and that you are familiar with. If you had visited this location, you would be confident that the road connection you mapped really doesn't exist. Also please note that satellite imagery can be very out of date in places, and misleading. Especially with complicated areas like this, with many old logging/mine trails, boots on the ground with a GPS is the best way to ensure your edits are correct and good quality.

Correction: That was from 082F15

The fact remains that you imported the polygon without it matching the adjacent one.
You imported stream fragments that don't connect to anything, instead of importing a complete watershed.

Looking around a little more, your edits to existing polygons may even created invalid multipolygons in adjacent tiles. (See relation/16665336)

It could be argued your mechanical edits are making the map worse in this area. I'm trying to give you the benefit of the doubt, as you have a very high edit count ... but this means you should know better. If this were any newer an account, I would honestly be reverting your changesets.

I'm hoping you'll come back and fix these issues, but it looks like you have moved on and are importing in several other areas now.

Hi, I did include a link to show a specific example. Do you not see how the tiles you are importing do not line up / merge with the adjacent tiles that you have also imported?

Hi, this is not a great import. You have woods that do not merge with adjacent tiles, and streams that are just fragments all on their own. For example see: changeset/149460128#map=14/50.2462/-118.4783&layers=D

If you are going to be importing Canvec data, these are the sorts of things that need to be checked and corrected to ensure quality. (You have imported some 200,000+ nodes in the last couple days which some people would question).

There is obviously a potential to go down a huge rabbit hole here with the various sources of introduced error (horizontal accuracy of imported NRCAN peaks, vertical accuracy of queried elevation data). I would suggest that consumer grade handheld GPS on a mountain summit will probably produce vertical errors within the same order of magnitude as the queried dataset. Don't even get me started on measured peak elevations vs what's written on the signpost or local guidebook!
But DENelson83's work here stands not as an authoritative source, but as a good starting point for otherwise unmapped information. Much like the NRCAN imports in general, which has been discussed at great length.

Fantastic, thank you

Awesome! Does NRCAN publish exact elevations for these peaks, and if so where? Thanks for this.

Hi, Welcome to Openstreetmap! Please note that the name=* tag is generally used for official, registered, or commonly used names. In this instance, you would put the business name of the store, instead of generic "market". Adding shop=supermarket seems appropriate for this one, too. And "Electrical Yard" is not a name for this feature. I have changed this to power=substation. building=church was a great choice for that way, no need to duplicate it in the name= tag.
It looks like you are using the iD editor, know that it has a little widget in the bottom right that will give you warnings and errors, to help out with any tagging issues like these.
Thanks and again, welcome!

Hi, welcome to Openstreetmap! Residential houses, sheds, and garages don't normally get a name=* tag. (The exception would be if it has an official name, eg. "Rideau Hall" or "Casa Loma"). I have already removed the name=* tags on your buildings.
Great job on the addressing tags though. Happy mapping!

Hi, welcome to Openstreetmap! Residential houses normally don't get a name=* tag (The exception would be if it has an official name, eg. "Rideau Hall" or "Casa Loma"), so I have removed the name=* tags on your buildings.

Hi, welcome to Openstreetmap! Residential houses, sheds, and garages don't normally get a name=* tag. (The exception would be if it has an official name, eg. "Rideau Hall" or "Casa Loma"). I have already removed the name=* tags on your buildings.
Great job on the addressing tags though. Happy mapping!