And yeah, things are pretty touch-and-go with Metro's service patterns right now, everything will look quite different in a few years. It'll certainly take many eyes to keep these relations hammered out!

A very minor detail that I just edited on the wiki page: the new K Line does not officially have any parenthetical in its name [like (Pink) or (Crenshaw) or something] like all the other lines. You can see the contrast in e.g. Metro's official schedules: https://www.metro.net/riding/schedules/. The parentheticals are relics of Metro's old line name scheme, but they've been slowly transitioning to the letters. My hunch is that once the Regional Connector opens and dramatically alters the service patterns, they'll drop the old parentheticals entirely, so they didn't want to give the new line a name they were going to drop soon.

No problem! Metro's promotional material definitely minimized the fact that only part of the extension was opening. Your fix to the routes (for posterity, changeset/128229922) look good, I also re-added construction: prefixes to the unfinished stops and platforms in changeset/128231672.

Hi stevea,
The portion of the K Line south of Westchester/Veterans is still under construction, it won't open for another year or two. That is why I left the construction tags on this portion when I removed them from the newly opened segment, between Expo and Westchester. See https://kline.metro.net/. Is there another reason you removed the construction tags here? Otherwise I think this change should be reverted.
Best,
Will

Hi, what's your source for adding the (Crenshaw/LAX) parenthetical to the K Line name in this changeset? All of Metro's current documentation that I can see refers to it as just "the K Line", so I think adding (Crenshaw/LAX) is incorrect. See, for example, https://www.metro.net/riding/schedules/, compare how it's written "Metro K Line" versus the other lines, e.g. "Metro E Line (Expo)". My personal hunch is that they'll drop the parentheticals across the system once the Regional Connector opens and re-routes many of the existing named lines, since they're just remnants of the old naming scheme that predate the K line's operation, so with the new line they didn't even want to start.

I've added construction: prefixes to the route relations you added here for the Aviation-Westchester portion of the K line to indicate they're not operational routes. Since they were otherwise tagged the same except for opening_date, most data consumers wouldn't be able to tell the difference between the operating and not-yet-open portions.

I don't see any indication from Metro that this line is called anything but the K line, so I don't think adding (Crenshaw) would be correct. See https://www.metro.net/riding/schedules/, compare how it's written "Metro K Line" versus the other lines, e.g. "Metro E Line (Expo)". My personal hunch is that they'll drop the parentheticals entirely once the Regional Connector opens and re-routes many of the existing named lines, since they're just remnants of the old naming scheme that predate the K line's operation.

Hi, thanks for adding this shop. Rather than just adding shop=yes, it's helpful to add what type of shop it is. In this case, that would be shop=clothing, or possibly shop=wholesale + wholesale=clothing if this shop only sells things wholesale, i.e. not individually to the public. You can find a whole list of OSM shop values here: shop=*?uselang=en#Shop-specific_information. Also, note that opening_hours in OSM have a precise, somewhat esoteric format they should be in, you can see the documentation here: opening%20hours=*?uselang=en. For example, the hours you tagged here should read Mo-Fr 09:00-17:30.
Best,
Will

Hi, I was the one who changed your previous address entry. In OpenStreetMap, only the street name goes in addr:street. Things like a suite number goes in addr:unit. See osm.wiki/w/index.php?title=Key:addr:*&uselang=en#Detailed_subkeys

Does the "Ranch" property really include the adjacent shopping center? Or should its boundaries go around? Not sure if there's a particular history here, but typically such landuses shouldn't overlap

Hi, it looks like in this change you have modified the official city boundaries of the city of Los Angeles, as well as the official unincorporated area of Universal City. Did you mean to do that? It doesn't look like the boundaries have changed, at least according to the city website: https://controllerdata.lacity.org/dataset/City-Boundaries-for-Los-Angeles-County/sttr-9nxz. Note that Universal City (the admin area: relation/10921166) is not exactly coterminous with property owned by Universal Studios (the film studio: way/313036270).

Agree with impiaaa here on both points. Please use descriptive changesets. I also think that boundary=administrative +admin_level=6 appears inappropriate for these data, as it is reserved for counties in CA.

Hi. This looks like a normal gate from streetside imagery, why did you change it to a wall? Walls are not usually mapped as points, nor are they typically found in the middle of service roads...

Hi. What's the source for this edit? The previous editor had mapped it such that access was conditionally yes between 6am and 6pm, and no at other times. You've now made it yes all the time, making the conditional redundant. Please remove the conditional if you know anyone can go through the gate at all times, or revert it if there's only access at certain times, as was previously mapped.

Another suggestion from a user of the OSMUS Slack channel is using unsigned_name=*, which is undocumented but has a few hundred uses: https://taginfo.openstreetmap.org/keys/unsigned_name, or unsigned_ref=*, which is well used but mostly for highway routes that are on the books but not signposted: osm.wiki/Key%3Aunsigned_ref

I took a look at the ZIMAS system. The code you added here appears to not be the reference code of the actual road per se, but of the parcel of land it sits on. Compare the code number's similarity to adjacent parcel ID numbers. The description of the PIN also explicitly states it's for internal city use only. So I still don't really think it's a good fit for the toplevel name=* tag, though I appreciate that you have a unique use case. As for official_name=*, a value there will still come up if someone searches the number in the search bar.

Yes, but if the name is unsigned and unwieldy like this, normal people probably don't use it. See name=*, where it says not to use name=* if the value is an obscure reference code. As a concrete example, I don't think someone navigating using OSM would want an instruction to "turn left at Frontage Road #139-5A221-258", even if that is the city's internal reference code of this road. For all practical purposes, I think this link is nameless. Also, what is your source for this data?

Hi, I'm not sure this reference code is a a good fit for the name=* tag, as I don't think anyone really calls the road that or is using the code for navigation. I think it would be better if this way were left unnamed, perhaps with the city reference code you've added kept as an official_name=* or even ref=*.

Hi, welcome to OpenStreetMap. The address entered here does not appear to match the location of the node, is this the correct location/address?

Hi Anna,
It looks like you got some buildings tangled up here. In general, buildings should not overlap, with each other or with roads. I've tried to sort it out in this changeset: changeset/125539535. Let me know the info looks OK now, or if there was something else you were trying to do.