Looks like the only changes I've made to it were splitting up ways to add a bus route (hence the changeset comment). I pretty much ignored the bike routes relation and worked around it.

I have no idea. I didn't add it.

To be clear, I'm not embarrassed about being an armchair mapper. I actually enjoy doing it from time to time, so your criticisms ring hollow to me. It's helped me forge relationships with lots of mappers around the country. And it doesn't get in the way of my survey mapping either.

I'm happy to revisit this issue when things have calmed down. This clearly matters a lot to you, but I can't seem to get anything through to you without you assuming I have some nefarious ulterior motive. The edit war you're talking about is fictional. I haven't touched the Phoenix light rail system for two weeks, and I don't plan to, so why not thank me for stopping instead of begging me to stop?

But now I know—it's because you don't consider my work to be work. I've been talking to a brick wall this whole time. I'm bowing out.

-Clay

Dr Kludge,

When I raise questions about someone else's work that I believe needs to be reverted, I _offer for them to revert it first_ before taking it upon myself to revert it. People are usually humble enough to understand what went wrong and take responsibility for it. I appreciate when others reciprocate that favor and give me a chance to revert my own work.

In changeset 82472573, I've acknowledged and resolved all the issues with everyone involved, except for the dispute between me and you. I'm disheartened that it's taken you nearly two weeks since then to reveal the reasons you unilaterally reverted my edits. Everything I've said to you in private messages I've laid out in public as well. I'm not even saying your tagging scheme is wrong—this isn't a contest to see who's right.

So I'd appreciate it if you'd quit characterizing me as a demanding bully and devaluing my work as "armchair mapping". We are both clearly interested in improving the map, and there's no room for that kind of hostility when you're taking responsibility for part of a collaborative project.

-Clay

Dr Kludge is being selectively responsive. He seems very proud of his work, but refuses to document or discuss the tagging scheme he's invented. What finally got him to respond here was me sending him an empty threat to edit war.

I sent a message to the DWG a couple days ago; still waiting on a response. In the meantime, I'll copy and paste the questions I previously sent him in the edit war threat:

1. Is there anywhere (OSM wiki, mailing list discussion, etc.) where you’ve documented the tagging scheme you are using for rail in Phoenix?

2. Was this tagging scheme developed through discussion with multiple collaborators, or just you?

3. Are there any data consumers (Mapbox, Wikimedia Maps, government agencies, transport agencies, etc.) that depend on Phoenix light rail being tagged as `train` rather than `light_rail`?

4. Are there any data consumers that depend on Phoenix light rail station IDs tagged as `name` rather than `ref`?

I think it's fair to say that this warrants a response beyond simply describing Phoenix's live vehical arrival texting system. This is not a feature unique to Phoenix.

I retagged the Valley Metro Light Rail with "light_rail" tags a few days ago, which Dr Kludge reverted back to "train" tags. I'm not sure what tagging schema they are using here because they haven't responded to any of my questions on those changesets.

Since Dr Kludge has moved on to editing other things without providing any explanation, I'm going to assume they aren't actively maintaining rail in Phoenix and it's okay to go ahead and retag this.

It looks like you were reverting many of your own changesets and you mistakenly reverted this one too. In good faith, I've reverted this revert. If I have it wrong, let me know. osm.org/changeset/82592296

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