Hi Andy. As I was reviewing Metra stations to repair stop positions and get things back to a working state, I noticed details were added in the same changesets where the stop positions were deleted. While some of the information was added in good faith and was useful, much of it was complaints about other mappers' opinions. Many of the stop positions that remained undeleted were given a fixme=* or note=* complaining that it was fake. I had a hard time sifting through the good and the bad, and in the interest of adding stop positions back and keeping tags free of interpersonal drama, I reverted them.

I appreciate attempts to add more detail to train stations, especially as public transit mapping and railway mapping in the United States have been gaining ground lately. I invite the author of the changesets complaining about and deleting my work to respectfully join in on the discussion as we continue to develop a tagging scheme for stop positions. He's clearly interested in improving railway data and I feel he could use some guidance from the community. I just wish he wouldn't be so hostile to everyone who bumps into him.

Manual. I'm using aerial imagery and doing a little internet research to determine whether places tagged as railway=station are actually disused, as well as creating station nodes wherever railway=station is erroneously tagged on a building (should usually be retagged building=train_station).

Feel free to survey the stop positions and add them. This is valuable information and people would definitely appreciate it if you could add it in.

If you don't feel like doing this work, that's fine—just leave the stop_position nodes as they are and move on to mapping something else.

Hi there. I went ahead and reverted this in changeset 87052754. If you have more accurate information on where trains stop, feel free to add more nodes and move the existing nodes to where they should be. Otherwise, it's okay to leave it as it is.

osm.org/changeset/87052754

JOSM crashed during conflict resolution here. Hopefully I got everything straightened out but if anyone comes across anything fishy, let me know.

Thanks for pointing out the subway_entrance discrepancy—it should be fixed now.

Stations lacking free transfer between directions are typically not found at transfer hubs. Bleecker Street (6) used to be an exception, where the southbound platform connected to Broadway–Lafayette Street (B,D,F,M) but the northbound platform was isolated from the rest of the station complex until recent renovations established a connection. Nearly all other split stations are somewhere in between train/subway transfers, so the most probable transfers happening at these places would be to and from buses on the surface.

Which brings me to pedestrian routing, the original reason I split these stations into separate stop_area relations. If you're riding the NYC Subway for the first time (like I was a few years ago), you might enter the station you're looking for and find out that you need to exit and re-enter, paying additional fare. It's improbable, probably nonexistent, that a routing algorithm would actually direct someone to make this sort of opposite-direction transfer. So I think it's sensible to add stop_area_group relations, though personally I'd only add them if there's nearby stop_area relations for buses.

Hi there. I noticed you added stop_area_group relations to encapsulate the subway stations I've split into separate directions due to lack of in-station transfer between the two platforms. These are stations where one must exit, cross the street, and pass through a different entrance (paying additional fare) to change to the opposite direction. So I deliberately left them without stop_area_group relations.

Should these be grouped together if there is no free transfer between them? I sometimes come across relations like this one [1] where someone has explicitly marked that stations without free transfers are not to be grouped. The wiki doesn't have straightforward guidelines on what a stop_area_group relation is intended for, so I guess this is subjective.

Perhaps a relation grouping by itself isn't enough to denote a free transfer and might necessitate a tag on the stop_area_group. I just want to make sure we're mapping things consistently going forward.

[1] osm.org/relation/9813444

Good work! Don't forget to change the from=* and to=* tags on the bus route to reflect what you've changed.

The beginning and end of a roundtrip route should match up with where the driver lays over and takes a break. For the free Peninsula commuter shuttles, typically this happens at the train station rather than the workplaces. If you're sure the layover spot is at that office building, then the relation is good as it is, otherwise I'd recommend changing it to start and end at Mountain View Transit Center.

You're probably right. Feel free to change it back.

Ah, good point. Do what you want with it - I'm gonna be taking a break for about a week to help with family stuff

Not really sure. It was there before I edited it and I didn't want to remove it as I split the route into its constituent parts. All the stations are mapped in detail now, so it can probably be removed.

Different train operators often have different names for the same station. Amtrak refers to the same station as just "Denver, Colorado" with "Union Station" as a subtitle, as is common with other major central stations around the country: https://www.amtrak.com/stations/den.html

Also, the Wikipedia article has it named this way: https://en.wikipedia.org/wiki/Denver_Union_Station

Of course, most other union stations are officially called just "Union Station" as well. But they're typically tagged with name="[city] Union Station" to avoid adding ambiguity in the national network. A train route may pass through multiple union stations, so it'd be frustrating to work on keeping the route relations sorted without having names be nationally unique.

To this end, I typically tag the building itself as close to the official name as possible. So in this case I'd have the historic train hall be named "Union Station". Sometimes I might even add the building's name to the label node (i.e. railway=station) under alt_name to help people find it with Nominatim, like Icicle Station in Leavenworth, WA: osm.org/node/6997575339

But the label node could just as well just be named "Denver"! Of course, there are other railway stations in Denver, so that doesn't help data consumers disambiguate. If you choose to change the name back, please make sure people can still search for it by keeping "Denver Union Station" in another tag, such as alt_name or nat_name.

Best,

Clay

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