Duck Pass was already on the map node/762008590
---

Published using OSMCha: https://osmcha.org/changesets/107861987

most or all of these campsites do not appear to be legal, they're very close to the trail or the river. did you confirm that they are at least 33m/100f from both?

I use a few sources: USGS topos, USGS 3DEP files/layers, and a file proceed by the owner of peakbagger.com to use for OSM updates. I mostly use the latter to programatically identify misplaced peaks and use the USGS sources as the primary, it's a very manual process. There are some cases where the highest point does not match the topos for a variety of reasons. My hope is in a few years we will have LIDAR coverage everywhere and can derive most of this from the data when quality surveys are not available.

maybe, maybe not. I haven't looked into the accuracy of the elevations there but the lat/lon aren't very accurate. they're usually in the general area but that's about it. I only add elevations when there is a trusted reference (surveyed elevations/benchmarks) since I don't know a better reference. the 3DEP lidar data will presumably become this once it's available for the high Sierra. I understand that many changes have been made to the geoid since the 80s (when many of the GNIS entries were last updated) so I wouldn't be surprised if they were based off an old ellipsoid. https://eos-gnss.com/elevation-for-beginners has a quick overview of the challenges around this.

as for moving individual nodes... I haven't seen a way of doing it other than dragging them to the correct position in iD or JOSM. it's possible to do it by creating a .osm.xml file though, just not as user friendly.

I've found many peaks to be off, sometimes by more than a mile. check the change history for each peak and fix up any older ones to the 1990s era USGS quads (pretty accurate), as you see fit. if you question a more recent update just send a message to the author to get more details before making a change that may revert work they have done. in particular areas I may be able to help with getting better quality summit coordinates, just no guarantees.
---

Published using OSMCha: https://osmcha.org/changesets/103873832

This is done in changeset/103853052
---

Published using OSMCha: https://osmcha.org/changesets/103849349

no problem, I sent them an email and I'll update the name here.
---

Published using OSMCha: https://osmcha.org/changesets/103849349

it was previously slightly off too, I updated this using the current 2018 US Topo in https://osmcha.org/changesets/103849283
---

Published using OSMCha: https://osmcha.org/changesets/103804905

while the gnis id and current map show this as Eve Lake, it is clearly Ewe Lake on the older USGS quads. it seems likely that Ram and Ewe Lakes should be next to each other, I'm inclined to say this is a data error in gnis that should be fixed- perhaps send them an email to have it corrected? https://www.usgs.gov/faqs/how-do-i-report-error-geographic-names-information-system-database
---

Published using OSMCha: https://osmcha.org/changesets/103849349

it was previously slightly off too, I've fixed it up in changeset/103849283
---

Published using OSMCha: https://osmcha.org/changesets/103593979

thanks for fixing up some of these, this area was neglected for some time.

in general it's best to follow whatever tagging scheme is being used in the area. most of the lakes around here are tagged with `salt=yes` if they are salt lakes, other lakes are assumed to be freshwater without `salt=no`. same for `tidal`. it doesn't hurt anything but it's redundant.

as for the group relation... it appears to be slowly growing in popularity (see type=group and type=cluster). the idea is to capture related lakes into a named relation and to name individuals only if they have a name (whether or not it's present on the topo). I try to add group relations when I can but there are plenty remaining to fix.

this is already part of the Stanford Lakes group relation, it doesn't look like this individual lake is named on the topo. I'm also wondering if salt/tidal tags are useful here? they're typically not set.
---

Published using OSMCha: https://osmcha.org/changesets/103599842

not sure about this area but in the sierra highway=footway indicates it is a paved path; highway=path is a regular trail or route (not so intuitive)
---

Published using OSMCha: https://osmcha.org/changesets/101895645

doh, it is incorrectly labeled in the current US Topo maps. the older quads are correct.
---

Published using OSMCha: https://osmcha.org/changesets/102364701

what sort of a bench is here?

thanks for the help :-)

thanks for catching this
---

Published using OSMCha: https://osmcha.org/changesets/102138052

instead of using alt_name2 for the bridges, have you looked at using bridge:name instead? I believe it is more standard
---

Published using OSMCha: https://osmcha.org/changesets/102150149

cool, just didn't know if you were missing riverbank relations by accident or if you'd come back on a second pass. thx

I'm not sure what the right tagging is but now this is inconsistent, relation/1167181 is still using waterway=riverbank
---

Published using OSMCha: https://osmcha.org/changesets/101945534