Are they truly part of a different network? NJ Transit owns them, NJ Transit operates them, NJ Transit sets fares and sells tickets, and NJ Transit is what's painted on the vehicles. In my opinion, that justifies changing their network tags to match NJ Transit's bus and rail services.

Though I could see the case for either way. What advantage do you see in keeping their network tags as "HBLR" etc.?

-Clay

Thanks for catching that! Fixed in changeset osm.org/changeset/78115624

Searching for "croton-harmon" and "croton harmon" with Nominatim yields the railway station and nearby details. Looks to me like the search engine recognizes it as a word boundary. It's a punctuation character according to Unicode so that's more or less what I'd expect.

Hey there stevea,

This is mostly just a technicality, but what was your reasoning behind changing this back to railway=light_rail? The remainder of the route and infrastructure for the SPRINTER is still mapped with train=yes rather than light_rail=yes, so if you meant to change this to a light rail line, your work is incomplete. From my point of view, changing the underlying railway for a DMU line to railway=light_rail makes it a bit harder to maintain and it doesn't match up with how similar DMU routes are mapped elsewhere.

In good faith, I'm going to go ahead and change this back to railway=rail. If this is something you're confident about, feel free change it to a light rail line—just make sure your changes are reflected in the public_transport elements and route relations as well.

-Clay

Looks alright. Thank you for reaching out.

Reverted. I know you may not have meant to do this, but you deleted all the stops from the 22-Fillmore trolleybus route relations. Be careful and don't undo someone else's work. osm.org/changeset/76076755

I'm honestly sorry for removing shelter=no. I think a JOSM plugin I'm using might be assuming it's equivalent to a missing shelter tag. I'll spend time today undoing that and figuring out what happened.

Sorry as well about moving the bus stop, I'll go ahead and revert that.

I'll go ahead and revert it. Thanks for understanding.

Whoa there. You deleted the new bus plaza at Walnut Creek BART. This construction project has been complete for months. It took a lot of time and effort for me to map it out, and I know it's still in operation right now because I've visited it. If you're using satellite imagery, it may be outdated. Could you please revert?

Oof, you're right. My mistake. I'll change routes 4 and 7 back to a single route=bus with roundtrip=yes

I guess that's fair. I'll go ahead and clean it up

Yeah. We can map wheelchair support with wheelchair=yes or wheelchair=designated. I think what's important is that the non-flag stops are one level up from the flag stops in the railway=station vs. railway=tram_stop hierarchy.

As for distinguishing railway=* for stops on Muni trackage, I think it seems fit to use railway=tram_stop for flag stops and railway=station for the wheelchair-accessible stops where trains always call (in other words, all the labeled stations on the official Muni Metro map).

Thank you for your work! I don't think any of the details you've added to the map conflict with an additional center/label node tagged railway=tram_stop. I'll admit the wiki article on that tag is pretty unhelpful and needs to be updated. It mentions the new schema, as you pointed out, but then goes on to explain how to map it according to the *old* schema.

As I've been going through and updating every passenger railway throughout California, I've been using the area around Karlsruhe, Germany as a reference of best practices. Over there, it seems railway=tram_stop is used in a similar fashion to railway=station, and the nodes on the tracks where the driver stops are tagged railway=stop and tram=yes. This seems like a sensible approach, and neatly organizes the rather complicated mixture of light rail and tram data in the rail network. I'd like to copy that approach here.

So to be clear, each tram stop will still end up having a `railway=tram_stop` once my work is finished. This is just part of a process to add more fine-grained, quasi-standardized details to the public transport systems here. What I've done in this situation before is to retag the nodes on the lines as `railway=stop` rather than suffer the hassle of ungluing the nodes from the lines and maintaining their semantics. Just haven't yet gotten to the step where I add nodes for labels.

See this section in the [OSM Wiki](osm.wiki/Trams#Tram_stops). Following the updated public transport schema, `public_transport=stop_position` with `tram=yes` is semantically the same as `railway=tram_stop`, and it is up to the renderers to begin supporting that. In fact, OpenRailwayMap and ÖPNVKarte seem to support it just fine.

It looks like the new consensus is to use `railway=stop` for a node on the tracks representing where the driver stops, and `railway=tram_stop` for a node off the line denoting where the label should go, similarly to `railway=station` or `railway=halt`. Check out Karlsruhe, Germany for a good, complete example of this.

I wasn't the one who added lcn=15 to these routes.

Looks like you're right. I wasn't the one who originally added that relation, but I'll be sure to clean this one up and others like it as I go along. Thanks!

As for the two nodes, they seem to have information relevant to buses, and I guess I don't know enough about the public transport schema to know if whoever added them intended for them to represent the BART stations themselves or AC Transit's bus plazas.

Thanks for pointing that out! I'll make sure to fix these issues as I continue my work on BART infrastructure.