trail_visibility and sac_scale go on ways, not on relations - you'll need to move them over for most apps to use them. this is shown on the wiki under "Used on these elements", see sac_scale=* for an example.

this also allows you to split up the trail condition, like alpine_hiking=class 2 scrambling, where it actually exists as well as increasing visibility where there are well established use trails.

if it's less of a trail and more of a cairned route then we've been naming it as such.
---

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

like most things on OSM there are some guidelines but no universal standard... ford=* is a reference.

around here I try to follow this: if you need to think about how to cross a stream towards the beginning of backpacking season ford=yes is good. if it's something you can step over, or it is usually dry (once the nearby snow melts) it probably should not be marked. there are thousands (like hundreds of thousands) of streams mapped in the Sierra, mostly due to crappy data from NHD imports, and most of them are benign. lots of real fords are missing though - some major ones are still missing! so try to tag it where it's important, not everywhere a trail crosses a waterway on osm.

(also feel free to delete waterways that don't exist :)

it looks like this change inadvertently moved the wilderness boundary - can you fix it? also the trail should probably be informal=yes
---

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

are all of those ford=yes nodes actually fords? there are a lot of NHD imported streams in here that aren't legit or are way too small to be a ford
---

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

looks good, I added the old trail back with lifecycle tags. this helps prevent it from being added back with regular highway tags - it takes a few years for trails to disappear from satellite/strava/etc imagery.
---

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

I believe the current practice is to add waterway=flowline instead of deleting ways through lakes - this allows the waterway relation to be continuous - relation/12859915 has a gap now
---

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

howdy. stop numbers should be captured in the ref= tag, not name= according to osm.wiki/Buses and (by standard convention) osm.wiki/Names

can you verify and correct these? thanks! :)
---

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

I reverted this change

I moved the general idea over to the name= tag, name is not a place to add arbitrary information about a parking lot

I moved this name to the description tag in 183989838

howdy, welcome to OSM. these updates are welcome but should be tagged as description= instead of osm.wiki/Tag:name=. read take a look at osm.wiki/Names for a bit of discussion around best practices.

I noticed that node/65851931/history is tagged "Tehneta Pass Airport" - is this correct? On the USGS maps it is listed as "Tehneta Pass".

is 峽 the most common translation for a mountain pass or saddle point?
---

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

is 峽 the most common translation for a mountain pass or saddle point?
---

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

is 峽 the most common translation for a mountain pass or saddle point?

my guess is Nalon was a typo of "Nason Creek Game Reserve" https://lawfilesext.leg.wa.gov/law/WSRAgencyFilings/Community,%20Trade%20and%20Economic%20Development,%20Department%20of/2138.pdf - abolished in 1968, replaced with a bow and arrow hunting zone.

I couldn't find anything regarding Chelan County Park. I assume it was incorrectly placed there on some old map that the GNIS team added. since they've rescinded all of the park IDs it's probably not something they'd research now. I'd just retag with a `was:` prefix, otherwise it'll probably show up again in the future due to GeoNames.

this was an automated edit, but from what I can tell this:
* was on a USGS map (https://prd-tnm.s3.amazonaws.com/StagedProducts/Maps/HistoricalTopo/PDF/WA/250000/WA_Wenatchee_244605_1957_250000_geo.pdf as an example)
* made its way into GNIS (though has since been rescinded, all parks have been removed)
* then copied into GeoNames, Wikidata, Wikipedia

so... probably was a real thing of some sort 50-70 years ago, and is now difficult to completely scrub.

as for OSM: prob start with adding a lifecycle prefix to destroyed: or something? I can update OSM and Wikidata if you can't but don't have delete access to Geonames.

the wikidata tag is on relation/12144066 - aside from the sign at the JMT intersection all of the maps I have only call these the "Davis Lakes" and don't specifically name either one as "Davis Lake". do you have a source that does?

otherwise I by convention around here the individual lakes would be known as "Upper" and "Lower"
---

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

the north side has a name on TNM now, I added it here too
---

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

sure, and that's good. we can definitely use one.

couple things to note:
* passes/mountains shouldn't be moved unless there is a reason - we've been trying to get these aligned with the latest 3dep lidar scans, which are unlikely to coincide with administrative boundaries. moving Arc Pass, as an example, puts it quite a ways to the south of the true saddle point
* adding them to the boundary makes importing boundary updates somewhat more tedious/annoying and (tool dependent) can break the somewhat questionable practice of linking these nodes from their wikidata entities
* the Sierra runs much further north and south than is currently modeled
* type=multilinestring isn't a valid outer for the Mojave boundary relation - the Sierra crest is quite a ways away anyways
* and the new Mojave looks like a duplicate (same wikidata/etc) of the existing Mojave relation

mountain range tagging is fairly nacent, and inconsistent. take a look at other examples around the US (and world) https://overpass-turbo.eu/s/2fXO for ideas. there has been a somewhat recent push to revive type=multilinestring.

anyways, hope this didn't come off as too abrasive. it's something that is useful just a bit complicated to complete.