Proposal talk:Public Transport map all stops as nodes

Even simpler?

I like your general approach but would like to see a simple simplification along the following lines. This might be the same as your proposal; I know it is close. Rather than providing a list of do's and don'ts, it basically drops a lot of the mandatory features.

RELATIONS [THIS IS A SIMPLIFICATION, removing the mandatory use of platforms and stop_positions.]

for each stop, ONE of the following is mandatory:

• platform node OR
• stop_position node OR
• station

PLATFORMS

The mandatory platform node (the one that can form part of the relation) is mapped alongside the route. Optionally, platforms may also be mapped as ways or closed ways, but those should not be included in the relations. If the platform is also mapped as a way, it is recommended to incorporate the platform node as part of the way. If it is a closed way (area), the platform node may be part of the way or inside the closed area. [THIS IS NEW. Current schema mandates ways over nodes.]

Only the following tags are mandatory

• legacy tag, if any (highway=bus_stop, etc.) (for legacy software, with an aim to eventually -- maybe not in our lifetime -- deprecate)
• {mode(s)}=yes [THIS IS NEW but is already a de facto standard]
• public_transport=platform

STOP POSITIONS

The stop_position node (the one that can form part of the relation) is mapped on the way.

Only the following tags are mandatory

• legacy tag, if any (railway=stop, etc.)
• {mode(s)}=yes
• public_transport=stop_position

STATIONS

The purpose of allowing stations in the relations is to cover the case where the exact position of the stop position or platform cannot be determined, usually because there are many such possibilities.

For quality assurance purposes, if the station is mapped as a closed way (area), the route should intersect with it. If the station is a node, the route should be close to it but will normally not intersect.

Mandatory tags:

• legacy tag (subway=station, etc.)
• {mode(s)}=yes
• public_transport=station

STOP AREAS

Since stop areas by definition include at least one of the above for each stop, these should not be included in the relations.

Johnparis (talk) 15:51, 14 April 2018 (UTC)

Do I read correctly that you would still add stop_position nodes to the route relations? It is then not clear on which side of the road the stop is located. This is why people started adding the platform way/area objects to the route relations. And sometimes they even added such platform ways for stops where no actual platform exists, to make sure that the stop/platform/stop/platform role sequence wouldn't be 'broken'. Or did you mean road instead of route in this section: STOP POSITIONS--Polyglot (talk) 16:21, 14 April 2018 (UTC)

I would allow people to add stop_positions if they wanted (sometimes it's just easier to identify than platforms), but one and only one item per stop -- EITHER stop_position OR platform. I think you are right to make it ONE AND ONLY ONE. And yes I meant road (or railway) instead of route. Johnparis (talk) 16:49, 14 April 2018 (UTC)

further thought Upon reflection I think ONE item per stop should be mandatory in the relation, but other items per stop should be optional (that is, neither mandatory nor deprecated). Johnparis (talk) 02:35, 20 April 2018 (UTC)

It may not even be possible to say that 1 object per stop is mandatory. I've been converting a few lines in India and I'm sure there are more stops on them, but if the stops aren't mapped yet, it's impossible to add them to the route relations.

Anyway, I've tried to propose a simpler system to map public transport and it's extremely unlikely that the proposal makes it. So I'm simply going to make sure that the wiki keeps saying that it's ALSO possible to map it this simpler way. But mappers can map it as simple or complex as they want. Unfortunately this means that it's not possible to give a simple description of best practices on the wiki. Although I'm not even sure I'll be able to do that. For a year and a half the wiki was saying that mapped stop_position nodes HAVE to be added to the route relations when mapped. I will simply never agree to that, so I went in and changed it back. But if somebody changes it again, or changes it on another page, I will not always see it.

The intention of this proposal was to bring mapping of public transport within everyone's reach, while still making sure everything can be mapped in as much detail as needed by ADDING more detail instead of TRANSFORMING nodes into ways/areas and having to update the route relations with these new objects. And of course, in my ideal scenario there would be 1 object representing the stop in the route relations, and only that object needs to carry the stop's details in its tags.--Polyglot (talk) 05:56, 20 April 2018 (UTC)

stop_position yes or no

I have problems with this phrase: This does not impede extending these stops with platforms in full geometric detail and stop_position nodes, They were? Are the stop_position mapped or not? In any case, what is the stop_position for? For now I think that only OsmAnd uses it. --AgusQui (talk) 12:44, 19 April 2018 (UTC)

If people feel the need to map stop_position nodes on the highways/railways, I'm not going to try to stop them. I'd prefer they don't add them to the route relations though. There are some cases where I also add stop_position nodes (at the start/end of the lines, as I'm splitting the way there anyway).--Polyglot (talk) 05:56, 20 April 2018 (UTC)

I support this proposal

I would also like to see more simplicity, and making all platforms nodes would definitely do that.