Again, thanks. It's good to see a familiar name in it for the long-haul. Happy mapping, fist-bump, see ya on the taggings ahead. I might not always keep things synced, though I offer my best.

Metro is on a tear, especially with what feels like "a sprint to the Olympics." There will be some busy re-tagging around here. I'm already feeling it with Arrow. OC Streetcar is around the corner and so is a great deal more.

Serious infrastructure building going on.

Good to know. They've been playing around with this morphology and it makes sense they'd break away with Pink. I once read Metro considers colors "secondary" route markers.

Whoops, yeah, thanks, the platforms...the platforms.

Good thing we're a team.

This (K and C) are kinda goopy, I'm looking at it still like if it needs a bandage until the next change, as there will be along here.

Also, our wiki (osm.wiki/California/Railroads/Passenger#Los_Angeles_County_Metropolitan_Transportation_Authority_/_LACMTA_/_MTA_/_Metro_(LACM) ) was what I was updating...these should stay synced with reality and what's in the map, too (of course).

Thanks for the assist here; it really was hard to figure out from Metro's web site.

Sorry about that, Will. I saw both the Wikipedia article and the kline.metro.net site that said the K Line was open, but I got it wrong that it was "the whole route" (instead of only the northern half).

I think I got the tags right, but if I didn't, please let me know or you might fix them yourself.

See?

As I said a month ago: the original author/poster (OP) and I had a cordial discussion about this, he agreed to redact his import and "think about it" as he might re-enter these data (or portions of them), and that's where it remains, correctly. It's fine, the OP appears to be doing just that. If other discussion about these data continues here, I think that fine, too. But rock-throwing insults and specious allegations will be (and are) called out.

I hesitate to reiterate his sordid, inflammatory, fight-picking, insulting, well-documented highly negative history in OSM, so I'll simply repeat here that I have as little or nothing to do with Adamant1 as possible. Nearly everything he says about me isn't true and I can't stop him from slandering me and others, so I don't. I will call him out just as publicly as he does, though. Any interaction with him needlessly becomes contentious, and not just with me, but with many (most?) others. My solution is to disengage as much as possible with him: "No Contact" with people who exhibit this behavior. He tries to bait me here, he'll almost certainly try to bait me again: watch.

OSM: how many repeat incidents does it take to recognize and apply a final remedy to this abuse?

Thanks, Minh. Yes, "divisions of a single government agency," CALFire, the California Department of Forestry.

Stations have been known to have less-than-clear signage id-ing them ask CALFire (or however it's styled).

I'm all for "green lights ahead for Wikidata approaches," and I am all for "let's make it clear and easy for people to put these 'in a box' (categorize them sensibly)," too.

An operator tag can work, even if as a temporary crutch before this might get "even more formalized (again)," which does seem to happen. But this iterative process does make our data better, especially over the longer term.

The original poster agreed (with me) to take some time to chin-stroke on this and give it a good think to make good sense going forward.

I mean, you could coin boundary=state_fire or something like that, but it's both messy and a tall hill to climb (in my opinion).

The "trick" is to get the tags right. It may be that "the community" thinks these are a good idea, if you tag them not boundary=administrative (because they are not), they become sort of like a school district boundary (in OSM): these exist (as both boundary=school and boundary=School) but last time I looked there were barely 20 of these (and millions of other boundary tags).

Check taginfo and how these are used, built and understood to convey data to others. Things like census and other boundaries have largely fallen out of favor. Things like COGs and MetroMPO stuff, read our wiki (US admin_level): these are "mostly not" mapped, but you might find some places (in New England) where they are.

I'm "in the space" and I don't see a lot of fire district boundaries. However, I did enter a fire=perimeter tag on the (large) polygon for the CZU Lightning Complex fire. That's likely not a purely "Kosher" way to use that tag, but the polygon has "stuck around" as apparently useful. (Thousands of structures burned and who knows how many trees). It's a "fire" (not its district of fire management professionals), but I can see arguments for how both such things are important enough to tag and enter into a mapping database like OSM.

It's true that these are not admin_level=5, as they are a "special district" (as that has come to be known in these 50 united states). They are a boundary, but they are not administrative.

Our community does have standards for what we map: these include what we can touch and feel in the real world. In the case of boundaries, which are "less of that," but still important data to be in a map, we have all sorts of sub-classes of boundaries. These have emerged over time and with consensus.

If you want to "build a case" for these (fire district boundaries) to be in OSM, you might be able to do that. However, choosing to simply "assert them into the map" wasn't the best way to do so.

Seek others in the map (read wiki, ask others...) about our proposal process. Look at what we've done with boundaries (and the data structures we use) and see if a / your / the community's "scheme" (no judgement there, more of a nickname) for fire district boundaries can be better formalized into something where heads nod and it widely looks like a good idea.

Simply slapping those in (and the community in the face a bit) as you did so was unwelcome. I do thank you for your gracious redact of your data, that's correct.

Contact me off this more-public venue if you like and we might further discuss.

These are essentially "wrong" in OSM: there is no such thing as "place=district" and these are "fire districts," which we (the entire project, not simply "here in California") do not map.

While neither choosing one in particular nor commenting on the specifics of tagging or style, what I DO like is the level of detail here. "A good sketch of more."

Tree cover in residential areas can, does and doesn't change a bunch, that's highly local, but change in trees in "suburbia" is inevitable. Pools, yes, once in, those don't change, and helicopters can use them with buckets for fires; I've added lots of pools.

With another volunteer, I'm discussing decks and patios and those are difficult (presently) to achieve consensus...I think it's happening but it's a longer, chewier convergence of agreement that hasn't happened yet.

Fences, too: yeah, good, especially when gates are present and added to OSM. Benches, picnic_tables, yeah, I'll do those in parks, but backyards, not so much, unless it is say a playground for children at a school, like near me is a daycare with some swings and stuff, not public, but there, benches and a drinking_fountain and kids behind a fence. Where something is included or not is wobbly, but swimming pools (even when fenced and private), fences, obvious or even "landmark" trees, sure, plenty of those. Driveways are well done here, too, yay.

Depending on how everything is surrounded by a landuse=residential (and this one is) and how there might be a boundary=administrative polygon or place=* node, ideas of private property are asserted. But as they are "big and glommy," these are crude. (My city has a small example of where a residential landuse is being turned into smaller one at a block-in-neighborhood level; see Prospect Heights in Santa Cruz, California or read about how that's happening in our wiki). So, yeah, the area of street and sidewalk might be "in" the neighborhood, but they are public, not private, and getting access=* tags on everything can get pedantic, but it helps when things are accurate and detailed rather than vague. A balance is getting struck, but it's not done yet. I mean, a fence is a fence, but you might already be on private property as soon as you depart the sidewalk (and sidewalks are "not even" in yet, here).

Pretty "conversation," you've "drawn" here so far, though.

I appreciate that! It's a labor of love, a wonderful hobby and a great way to "give back to the community." We seem to have a fair bit of "technical overlap" (I'm a former Apple, Adobe, SCO...employee). OSM is a great project to make friends; I've been meeting people "going on hikes" (or rides) for over 13 years.

Happy mapping!

I agree they are "orphan," as they might not connect fully, although I'm not sure why you call them strange.

I'll sometimes add power lines if I can see them (using imagery, as I believe was the case with this edit), but I can't always see where / whether they connect up properly to the rest of the grid (as tree cover obscures much in the Land of Redwoods). So, there will be some isolated "islands" of these, which aren't wrong, but they are incomplete.

I don't see good reasons to remove "somewhat incomplete" data, rather, I tend to keep them as an inspiration to make them more / better complete (from a field survey, and I and many others DO perform these). In my experience, eventually, this happens. If/as it doesn't, at least OSM "has the data it has."

This was quite a while ago (8 years) and data were provided to me by a manager at the ECG Alliance itself.

I do know that default values for width=* are in meters. However, I do not know which segments you refer to which may be in error. If you know or have better data, by all means, correct them to contain better data! And thank you for contacting me via changeset comment, that's very "OSM polite."

I guessed as much; thank you Allison P for sharing your suspicion, allowing me to agree with your (more public) comment (here).

I "entertain" such questions in the spirit of "openness" (OSM's first name), but I also realize that there is some possibility of "baiting" or deception (like sockpuppetry) going on. Let's let this unfold, I have nothing to hide and am happy to share the slog-through-13-years of history of this; I can well-defend my edits.

It's pretty complicated for an OSM beginner such as yourself, as it has a long and complex history:

osm.wiki/Santa_Cruz_County,_California#Landuse

where ongoing updates (after 13 years) continue to this day.

I don't know how much of a wiki editor you are, but if you could update

osm.wiki/California/Railroads/Passenger#California_High_Speed_Rail_(https://wiki.openstreetmap.org/wiki/Tag:passenger=regional)_trains_(CAHSR),_under_construction

with your map edits, that would really "help out" keeping ourselves synced. I can and do notice changes in the map, so this isn't strictly required. But as it is helpful to everybody to keep both map and wiki (tracking CAHSR's status) relatively synchronized, one of us doing that CAN be done, but MORE of us doing that (or even ALL of us doing that!) is even better.

Really, CASHR doesn't change that often or that dramatically (although there has been a big burst of activity in 2022, thanks to both of us and more), so "little incremental changes," whether to the map data or our wiki data (like status updates there) aren't that big of a hill to climb. Thank you in advance.

CAHSR in OSM just keeps getting better! Again, thank you for your edits.