Hi Roland, For long trains like you describe, the platform is usually split up in zones. I think it would make sense to have platform ways/areas that are split to describe them in full detail. In practice these zones on the platforms usually described by letters are not used individually, but rather grouped together. I think I would create a node for each such group and then use that one, but I admit, I'm mostly busy mapping bus/tram and sometimes metro routes.
What I hear quite often in railway stations is: don't use the last three 'cars' if you want to get off in minor station such and so. I almost never hear them say, get on the train in zone A-E, but I think it is written on the tickets sometimes, in case people have made reservations for specific seats. Anyway, you're right in that the main point of my proposal is to get people to add 1 object per stop to the route relations. The reason I wanted to also specify platform nodes, is because I think it would be beneficial if we have 1 way to do it. Otherwise when another mapper comes by, he/she may want to change it to how they prefer mapping and I would like to see stability in the data. I think what most people crave is one clear and specific way of how to map public transport that is easy to describe and easy to map for the simple cases, without impeding the possibility to add the necessary detail for the more complex cases. I'm also for having name/name:xx on the objects that are added to the route relations. But I don't want to duplicate those names to stop_position nodes - platform ways/areas. At present somebody changed to wiki to say that if a stop_position is present it HAS to be added to the route relations. I can go and change the wiki page back to how it was a few months ago, but it will probably be changed again, when I'm not looking. I'm only adding stop_position nodes occasionally in the middle of the itineraries. And I'm always adding them at the start and end of the lines, as I need a node there anyway to split the way on. I don't want to add these stop_position nodes to the route relations and I definitely don't want to duplicate details like name/ref/etc. to them. Anyway, requiring to only add 1 object per stop to the route relations is definitely a step in the right direction, but if we don't specify which object to use, we will still have groups of mappers using different styles of mapping. That's why I went one step further and also proposed to use nodes not on the highway/railway for this purpose. I started calling them platform nodes, because the answer I got on the mailing lists was to use public_transport=platform for them. They rather represent the pole, or the waiting area/zone for the passengers, but it doesn't make much sense to use another tag for them, even when they are not really platforms. They are not really highways either, but we still add highway=bus_stop to them. It seems really hard to come up with a British English tag for them, so we can just as well stick with public_transport=platform/[mode_of_transport]=yes/highway=bus_stop//railway=tram_stop. Polyglot 2018-04-16 7:21 GMT+02:00 Roland Olbricht <roland.olbri...@gmx.de>: > Hi Polyglot, > > https://wiki.openstreetmap.org/wiki/Proposed_features/Public >> _Transport_map_all_stops_as_nodes >> > I do agree that it would be easier for everyone to have one and only one > member on the line relation per actual stop. > > However, trains and sometimes also trams can have a significant length. > Walking the full length of a train can take as long as 7 or 8 minutes. > There are applications that send people before stepping on the train to the > right section to have a shortest possible walk after getting off (search > for e.g. "london tube exit routing", no link here to not advertise a > specific one). > > We render OSM useless for such applications if we force people towards > adding fictitious nodes for trains. Please note that an easy approach like > adding a node at the front position of the train does not bail out us > because there are platforms that are called at in both directions of > travel. In such cases, also the middle position of a train may vary. > > Therefore I suggest to drop the node requirement and keep up the > requirement to have only one object per stop. > > A second thing for simplication: I suggest to require always a "name" tag > on the member object or multiple "name:XX" tags if there is no preferred > name in a multilingual setting. This way we could safely ignore relations > for stop related objects. > > When writing both a plugin for JOSM and the display tool > https://overpass-api.de/public_transport.html > it was the most frustrating part to go on a quest to find the appplicable > name if people had hidden it in some special relation, including scores of > new possible kinds of error if one has no or multiple names from multiple > stop_area relations and so on. This was the main reason to discontinue the > development. > > I consider to write a proposal for the "name" requirement. Would it make > more sense for you to instead include that in your proposal, i.e. add the > requirement for the member object to have a "name" or multiple "name:XX" > tags? > > Best regards, > Roland > >
_______________________________________________ Talk-transit mailing list Talkemail@example.com https://lists.openstreetmap.org/listinfo/talk-transit