Hi, is there any reason you reverted this?

Hi Dr Kludge,

I appreciate your work keeping Phoenix's light rail system up-to-date. I've addressed your criticisms of my changeset here. I left a comment on your changeset (osm.org/changeset/82526320), which you have clearly read because you've already fixed one aspect of it (osm.org/changeset/82533802).

Could you please answer the rest of my questions? Is there something specific to Valley Metro that makes stop IDs more fit for the name=* tag rather than the ref=* tag? How come VMLR is mapped with "train" tags rather than "light_rail" tags as used on light rail lines in the rest of the country?

Thanks for changing railway=train back to railway=light_rail. I'd appreciate it if you could address my other questions about your tagging scheme on your previous changeset.

Alright, I reverted the amusement park rides to route=train. The railway infrastructure ("subdivision") relations I reclassified as route=railway remain that way.

Hi, I'm going through the changes here and I'm a bit confused. "railway=train" is not a tag used anywhere else. Other "light_rail" tags seem to have been changed to "train", despite this looking like light rail and being named Light Rail.

Also, I did not remove any stop IDs; I simply moved them to the tag where most data consumers expect stop IDs to be (ref=*). Now the ref=* tags are empty. Is there something specific to Valley Metro that makes the stop IDs more fit for the name=* tag? This doesn't seem to match up with how light rail lines are mapped in the rest of the United States.

I see what you're saying. I would consider the platform level to be the relevant level to assign to the station, the rest being just indoor pedestrian circulation. Either way, I guess it's unclear whether the level tag belongs on the station node in the first place.

I want to think through to alternate ways of mapping stations. Station polygons fulfill the same role as station nodes, and they're drawn as a convex hull around the stops and platforms (and switches if present). If I were to trace the station polygons here, should I assign them a level tag? If so, what?

The most straightforward answer to me would be to have one polygon for each station, and to assign it the same level as the railway infrastructure it surrounds. I'd like to hear your thoughts.

Fair enough—I'll go ahead and re-separate the relations. Looks like there's a lot of route variants and one relation could become unwieldy.

As for the name=* tag, in the context of route relations it functions more like description=* and often duplicates data found in other tags. I find it personally helpful to have relations of the same network show up together in alphabetical order. For this, I may just shorten it to "GO".

Thoughts?

At the time, the information I had available to me indicated that they are branded as Lakeshore West trains. I'm checking now and some online resources brand them as Lakeshore West with a dotted-line extension to Niagara, and some brand them as Niagara. Was this a recent change?

Looks like you're local to Toronto, so I'll defer to your judgment on this. I'm happy to change it back and restructure the relations—I just want to make sure I'm not overlooking anything.

It shows up on Amtrak's schedules as simply "Milwaukee", although the complex is of course called "Milwaukee Intermodal Station". I chose to leave the name of the building as such, which I typically do in cases like this.

I'm assuming you're local to Milwaukee, so I'll defer to your judgment on whether the longer name is necessary for disambiguation. I think it mostly boils down to this question: if a visitor asks "how do I get to the Milwaukee train station," would a local typically assume they meant Intermodal, or would they ask which one they meant?

https://lists.openstreetmap.org/pipermail/talk-us/2020-January/019902.html

I primarily wanted things to be uniform across stations shared by Amtrak and a local operator. I observed that most cases across the country listed Amtrak first, while Caltrain and FrontRunner had it the other way around.

Suburban trains nearly always show up more often than Amtrak regardless of location, so I could see the case for putting Amtrak last. Though at the time, I considered this to be mostly inconsequential, since order doesn't matter in the network tag.

-Clay

Fair enough, I'm convinced. I'll keep that in mind going forward. I should probably mention that I've been mapping commuter rail stations across the Northeast according to the switchless definition. I'll follow up in a private message about what to do going forward.

That said, the presence of switches indicates something meaningful about the station itself—that is, whether trains may terminate or reverse direction there. So if these get changed back to railway=station, I'd hope to retain the information with a tag like terminus=no.

What makes the presence of switches "arcane"? They're quite important in railroad operations and scheduling. The halts are all tagged simultaneously as public_transport=station and train=yes, which I would argue are the tags relevant to passengers.

Cincinnati Union Terminal has a large, ornate station building, for sure. It certainly was at one point a "station". As of today, that station is a freight yard with a single passenger platform on the side. The switches belong to the yard, not the passenger platform. I don't think a large headhouse or a historical status as a station are enough to call it a station today.

As I understand it, the public_transport tag contains the relevant information for passenger operations and the railway tag is for underlying infrastructure of railways. I hope I'm helping by exposing this distinction to the public by tagging halts. To change them back to stations, I'd have to add something like note="missing switches" to avoid losing information, and I'm reluctant to do that.

Best,
Clay

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