Thanks for cleaning up after me. The explanation for that situation is that I tend to not have land use shapes enabled while doing that kind of editing, so the existing polygons were effectively hidden from me due to the building tags being removed at some point... in case you were wondering. :-)

In the process of trying to figure out why that larger area was a multipolygon in the first place, I was getting ominous timeout errors trying to view the history on this site, so I looked it up on PeWu... and instantly regretted it: https://pewu.github.io/osm-history/#/way/227263491

Seems nobody's really sure if it's supposed to describe the foliage (forest or scrub?!) or some topo region or what... might need to come back to this one with a fresh brain. In any case, since I'm not sure even the first relation was actually needed, we can probably nuke the new one from orbit before it adds to the can of worms (unless you need it for what you're doing down there).

My thought would be to eventually expand the old one to include the area north of La Tuna canyon, to compose "Verdugo Mountains"? It's just kind of painful (if not impossible) to work with big relations in iD; I don't even like dealing with building-sized multipolygons if I can help it. :/

Hey, nice weather for historical research, huh? I noticed that there are now two identical relations for the Verdugo Mountains - the old one:
relation/13772828
and the one you created in this changeset:
relation/17245430

Should these be merged back to the original (to preserve history), or did you have plans to differentiate them somehow?

Hello there! For future reference, if you create a building in such a way that it slightly intersects an adjacent one, and iD complains about it, tagging it as layer=-1 is NOT the fix. Doing that implies the first building is *underneath* the other one. :-)

I fixed the outline, removed the layer tag, and restored the building data tags that were lost when you (accidentally?) deleted the original outline. Cheers.

Hello ebbebb!
Please note that descriptive information about OSM features (such as a driveway) is provided by various tags that are understood by software using the data. The "name" field is not used for this, and in general driveways shouldn't be named. For more information, you can see:
name=*

Cheers!

Hi! I've reverted this edit, it was correct before your change. Please be careful, odd street relationships like that one are not uncommon in this area. Cheers!

Haha, you're deep down the rabbit hole now, my friend. Your guess looks a lot better than the previous location, for sure. Turns out that NID has a pretty decent website, and they mark it within the park, but a little further north: https://nid.sec.usace.army.mil/#/dams/system/CA01079/description

BTW, nice work on that Beverly Johnson "park" along Whitnall - I ride past it fairly often and never knew it had a dedication/name.

It looks like at least some of the buildings are LAUSD administrative stuff, so I went ahead and updated the tag. Might even give the buildings some love later - looks like not the cleanest of imports.

Yeah, focus is hard! Definitely not the worst way to spend "extra" time, anyway. Good luck with the employment situation!

Interesting spot, probably needs more looking into. If it *is* all part of a large educational complex, it might be better to use a landuse tag, i.e. landuse=education

Huh, doesn't seem to be showing up as an issue, so I guess that works, at least for drains. I don't recall noticing anything tagged as "drain" before, but I suspect maybe some of the things tagged as "streams" that I have seen should really be drains, so I'll keep it in mind.

I was actually kind of surprised how many showed up around the valley in general, but Griffith Park, not so much (yet).

I'm not suggesting going nuts on street gutters or anything... it's just that OSM wants *some* descriptive tag at any crossing of those ways, or it will complain. In this case, the "ford" tag just means the (intermittent, shallow) water and the highway are on the same layer, no culvert or bridge. The wiki page even suggests using a depth=0 tag for particularly insignificant cases. Again, it's just a kind of mental gymnastics of decoupling the meaning a word has in your mind for purposes of tag names, I struggled a little with "driveway", myself.

Anyway, that's my best attempt at an understanding of the situation. If you find a more elegant solution, let me know! You could always ask here:

https://community.openstreetmap.org/c/communities/us/78

This is the most relevant thing I found in the older Q&A forums:

https://help.openstreetmap.org/questions/72108/stream-running-along-and-over-a-road

If you *really* don't want to add the ford tags, you could add an explanatory "note" tag and ignore the warnings that come up, I suppose.

Griffith Park is West Valley now? ;-)

BTW, if you ever want to get a better idea of how a tag is currently being used in a given region, you can use an Overpass Turbo query:

http://overpass-turbo.eu/s/1FMS

After the page loads, click the green "Run" button in the upper left corner, and the map should populate with circles where "ford=yes" is used.

It looks like "ford=yes" is the right tag for those crossings, with an estimated "depth" tag, if possible. It's just one of those cases where the intended purpose of the tag may well be broader (or sometimes narrower) than what the word itself suggests to you. Happens with me all the time.

Another tag that might be useful in some areas of the park:

flood_prone=*

Based on experience, my working assumption is that with the current well-defined, solidly gated termination of the bikeway, they consider everything beyond that point a no-bike zone. If you actually talk to some horse people and they say otherwise, well... it's your call. Being something of a realist about human behavior, I personally feel like it makes sense to align the tagging with the big, obvious physical obstacle rather than a more nebulous "I don't see any signs yet" approach. :P

But yeah, I doubt there's any danger of construction starting any time soon.

Yeah, I didn't mean to suggest the path tag shouldn't be used, just be aware that changing the feature type of an existing way to Path without adding other tags is potentially a downgrade of data. If adding "bicycle=yes" to a footpath works for your purposes, it might be a better description of ground truth in some cases.

> Especially considering the default tags for "path" include bicycle=yes and for footpath they include bicycle=not specified.

But either way it requires additional action to actually include all desired tags, so I wouldn't base *too* much on that. Ideally the goal is to get the best match between reality and the most commonly agreed upon usage of the (sometimes confusingly named) tags.

The importance of a surface tag obviously depends on the situation, but it's a good thing to add to generic paths. The discussion I linked (it happened to be cited on the path wiki page) was about rendering, but nowadays it's probably more important to keep routing algorithms in mind, because they can't really infer things from context the way somebody looking at a map can. Another case where I might make the extra effort to add a surface tag would be where the situation is not what somebody might reasonably assume, like a "connection" from the Chandler path to a street over a loose dirt incline. There's generally no need to get fancy with surface types, in most cases just distinguishing between paved vs dirt is enough to clarify what "path" means.

I'm assuming you already know about bikes being strictly banned on the trails at Griffith Park... same thing applies here. You absolutely do not want to route people on bikes onto that stretch of access road beyond where the newest section of bike path ends; drama will ensue:

https://www.latimes.com/socal/burbank-leader/tn-gnp-me-mariposabridge-20160130-story.html

Last year there were signs of renewed interest in doing *something* to continue the bikeway, but the ideas presented seemed pretty unlikely to work out IMHO:

https://ladotlivablestreets.org/projects/LA-Riverway-Phase-IV

I'd love to see something happen with that, but I'm not holding my breath. Meanwhile, that section should be access tagged as horses and pedestrians only. Seriously, people have been traumatized by those equestrians.

Oh, and specifically regarding this:

> Seems strange to have the different types of paths with their default tags if the default tags aren't applied!

You'll notice that selecting "Footpath" as the feature type, for example, DOES apply some extra tags, and those will be shown in black rather than grayed out. Selecting "Path" just sets "highway=path", and you need to "roll your own" additional tags.

If you want to see the "red pill" list of tags actually being applied, you can expand the Tags section near the bottom of the sidebar. There's also a button to switch the list to a plain text field, which is useful if you ever need to copy'n'paste everything from one feature to another (be careful with that, though!)

Obligatory admonishment: It's important to be cautious about editing to get a certain result from a specific data consumer's product. That said, I suspect most of them do make those default assumptions about "highway=path" when they have to... it's just better if they have more specific information to work with. Historically there was a lot of debate due to all the different things any given person thinks is or isn't implied by "path" (e.g. https://github.com/gravitystorm/openstreetmap-carto/issues/1698#issuecomment-134905532), so the less ambiguity, the more useful the data. In particular, "surface" is pretty hard to make valid assumptions about outside of extreme urban or rural areas... I mean, just look at the spectrum of what passes for a sidewalk around here! :D

Anyway, it's perfectly common to encounter "highway=footpath" with a "bicycle=yes" tag, so if a product isn't handling that case correctly, it's something they need to fix on their end... here's a random example if you want to check: way/734114198

For places where you're not really supposed to ride a bike, but which might still reasonably be part of a bike route (narrow pedestrian bridges, etc) there's the "bicycle=dismount" tag, as used here: way/222837353

Incidentally, the recent legalization of sidewalk riding was for unincorporated L.A. County, but it was already generally legal in City of L.A. (and other cities in the county all have their own laws about it - quite a can of worms: https://ehlinelaw.com/blog/bicycles-and-sidewalks).

Also incidentally, if you haven't yet, take a look at Achavi, it's a neat (but probably not mobile-friendly) way to get a visual overview of a given changeset's edits, you can hover over the features to see a diff of the tags: https://nrenner.github.io/achavi/?changeset=145978856

Interesting area for exploring! Just a reminder that when changing something like that bridge to (the extremely generic) "highway=path", it's nice to explicitly add appropriate access tags (foot=yes, bicycle=yes, etc). The iD interface is slightly confusing in that it shows a default list of (grayed out) assumed values, but unless you click to set them, they aren't actually added, and routing engines have to guess whether it's suitable for any given mode. Surface info is nice, too... bonus points for indicating stuff like wheelchair access or specific barrier types!