I don't think people generally understand the distinction between a station and a halt in North America, unless they're railroad employees or otherwise have sufficient technical knowledge on railroad operations. I think it's inaccurate to say this definition isn't generally used in the U.S., since I have in fact come across other mappers' work where they mapped according to the "no switches" definition. Perhaps we should say there isn't a consensus yet.

Hi Andy,

I'm using the definition of a railway station without switches or crossovers, as in the German examples on the wiki. Unstaffed-ness happened to be a convenient heuristic to find such stations. I visually checked each one to see if there were switches nearby or not.

Best,
Clay

I moved the wikidata tags to the parent route_master relations. I assumed this was the proper way to represent things—I didn't realize that {{maplink}} was dependent on it.

Ideally, {{maplink}} itself should be updated to support route_master relations as well. But in the meantime, feel free to restore the wikidata tags to the routes.

wrong changeset comment - this edit is actually about layer tag and bridge end fixes

reverted here osm.org/changeset/78723287

Should the Atlantic City Line be its own network, separate from the rest of the NJ Transit rail lines? Should the 'A' and 'B' divisions of the NYC Subway be separated into networks?

The issue you're having seems like it could be solved with a spatial query. If you're looking for only the HBLR, why not search for NJ Transit light rail in a bounding box? Or search for the route relations that make up the HBLR?

I think we're talking past each other here. I can see the case for keeping them distinct, and though I may disagree, I'm not gonna be mad if you change them back. I just don't see what the consequences are of this change.

As far as I can tell, both Amtrak and Metro-North variably use hyphens and en-dashes in the name of Croton–Harmon station (among others). The designer in me thinks the en-dash is preferable for hyphenated station names, and the grumpy software engineer in me wants to submit issue tickets to the search engine maintainers that aren't using Unicode's algorithms for word and sentence boundaries. From my perspective, the fact that this "breaks search" is a problem with the search engine itself.

That said, I'm okay with reverting this if it's presenting an issue to enough people. It may be more practical to go back to using hyphens because they play nice with existing tools.

I've been using en-dashes so far on railway stations throughout North America, including stations not in this changeset. Should I go ahead and change all of them to hyphens?

Best,
Clay

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).