Re: [Talk-transit] Proposal for simplification of mapping public transport
stop_position is even worse for trains, which might be hundreds of meters long with dozens of doors. The wiki says to map it as the "center" of the train, but I'm not sure that's useful other than to explicitly indicate which track the train uses, which could probably be deduced from the route relation anyway. It's also not necessarily a fixed point; at stations here where all passengers enter/exit a platform at one end, trains always stop with their front/rear at that end of the platform, so the center depends on the train's length. Heck, even the platform a route uses is not necessarily fixed; at many large stations, different trains on the same route can show up on different platforms or tracks, and that case doesn't seem to be mappable at all today. It seems a bit simpler for buses, where the front generally stops in the same place every time and folks generally enter the front door, though there are always exceptions. The location of exit-only doors doesn't seem like something that needs mapping. S On 2018-04-16 13:26, Jo wrote: > Here in Belgium, we have normal buses and longer ones, either can have 2 > doors or 3 doors. There is no way of knowing which of those buses is going to > serve which stops at a given time. The only thing we do know for sure, is > that we are supposed to get on in front, except for wheelchairs and parents > with strollers. I fail to understand why stop_positions are considered to be > that important. Especially for buses. For trains I might understand, but even > there it's impossible to predict where exactly the doors will be when the > train stops. And it's not important, what matters is when there are zones on > the platforms, those we can map by splitting those platforms. > > Jo > > 2018-04-16 20:17 GMT+02:00 Ed Loach : > >> Stephen wrote: >>> If a consumer doesn't care about stop_position members, it's trivial >>> to >>> ignore them. If the current spec says they're mandatory, then >>> propose >>> making them optional; I would support that. I don't support >>> prohibiting >>> or removing them. >> >> They are optional in the current spec. I don't bother with them in bus route >> relations as physically a bus has to stop on a relation member way close >> enough to the bus stop (platform) node for passengers to get on (with the >> exact stop position depending whether the particular bus has doors at front, >> middle or rear). >> >> Ed >> >> ___ >> Talk-transit mailing list >> Talk-transit@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-transit [1] > > ___ > Talk-transit mailing list > Talk-transit@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-transit -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov Links: -- [1] https://lists.openstreetmap.org/listinfo/talk-transit___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
The node doesn't describe the platform. The naming is unfortunate, but I think we're stuck with it. The node represents the stop. What stop platform way and stop_position node belongs together can be expressed using a stop_area relation. Then it's needed only once. There is no need to do it over and over again in the route relations. If it's such a problem that mapped stop_positions are not in the route relations, my next step (for Belgium at least) is to remove the ones that I added from the OSM. The route relations I'm maintaining will continue to have 1 object per stop. Unfortunately, my colleague in Brussels read the wiki and he is adding stop_position nodes everywhere and adding them to the route relations of the STIB/MIVB operator. The consequence is that I won't be maintaining those (not really a problem, as I wasn't doing that anyway), but those stops are being used by the other 2 operators too, of course. And I won't be able to remove those stop_position nodes AND I won't be adding them to the route relations, so it becomes impossible to comply with what the wiki 'dictates' at present (it didn't just a few months ago). What I mean by stability of the data is the following: A mapper comes along and maps a bus stop on a node. Another mapper adds it to some route relations. Then a mapper passes by and adds a way for the platform, transferring all the tags and adding the way to the route relations. Then somebody read the wiki and adds a stop_position node as well and adds this to all the route relations as well. Lots of changes to the relations, no real change to the itineraries. If the second mapper had simply added a highway=platform and maybe a stop_area relation, the route relations would have remained stable. Anyway, I'll keep going the way I like mapping PT and the rest of the world can do it in more complex ways, each slightly different from the other, depending on when they read the wiki. It's all fine. I'd like to see it become simpler, more inclusive for everyone. Now most mappers simply say: public transport I don't touch it. Tried to read the wiki, gave up. Let the 'specialists' handle it. I'll continue working on PT_Assistant and of course I'll try to make it work for simple and complex ways of mapping alike. Polyglot 2018-04-16 20:51 GMT+02:00 Stephen Sprunk : > Jo, > > IMHO, if a stop_position exists but isn't in a relation, consumers can't > be sure which routes/platforms it applies to, and that means it's just > clutter rather than useful data. Given how many of them seem to be > flat-out wrong, though, we definitely need to document it better--and make > maybe it optional so mappers aren't forced to add something that they don't > really understand. > > If there's a way/area for the platform, then IMHO one should not add a > separate node for the platform; that is redundant. If you need a single > point for some purpose, you can just compute the centroid. I don't see > what "stability" has to do with it; once it's mapped, it's not going to > change much over time unless the physical platform itself is changed, and > one shouldn't expect stability in that case. One can tag either just as > easily too, so I don't understand that argument at all. > > When I map a building, I can make a node and put all the tags there, or I > can make an area and put all the tags there. Nobody expects a a way for > the outline and a separate node inside it with all the tags--or more > likely, a conflicting set of tags because some mappers didn't notice the > redundancy. Why should a platform be any different? > > S > > > On 2018-04-16 13:20, Jo wrote: > > I knew this was going to be hard. Anyway, I made sure that it's definitely > allowed to tag bus stops as platform nodes. Every few months I look at the > wiki and each time it changes. At present it says that if a stop_position > node is present for a bus stop, it has to be added to the route relations. > I definitely don't agree with that and I won't do that. The route relations > I'm creating only contain 1 object per stop. Having said that, I won't be > removing stop_position nodes or platform ways from route relations, if they > are already present. Unless this proposal passes somehow, then I will help > with the conversion. > > My proposal does not say that it's not allowed or possible to map > platforms as ways or areas. > > It only says that for stability of the data, it would be better to map all > the detail tags on 1 node and only add that node to the route relations. > > If a platform is present, it's perfectly possible to tag it with > > highway=platform or railway=platform > and optionally > tactile_paving=yes > wheelchair=yes/limited/no > > Jo > > 2018-04-16 19:17 GMT+02:00 Stephen Sprunk : > >> On 2018-04-16 08:11, Philip Barnes wrote: >> >>> On 16 April 2018 07:46:13 BST, Jo wrote: >>> 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. >
Re: [Talk-transit] Proposal for simplification of mapping public transport
Jo, IMHO, if a stop_position exists but isn't in a relation, consumers can't be sure which routes/platforms it applies to, and that means it's just clutter rather than useful data. Given how many of them seem to be flat-out wrong, though, we definitely need to document it better--and make maybe it optional so mappers aren't forced to add something that they don't really understand. If there's a way/area for the platform, then IMHO one should not add a separate node for the platform; that is redundant. If you need a single point for some purpose, you can just compute the centroid. I don't see what "stability" has to do with it; once it's mapped, it's not going to change much over time unless the physical platform itself is changed, and one shouldn't expect stability in that case. One can tag either just as easily too, so I don't understand that argument at all. When I map a building, I can make a node and put all the tags there, or I can make an area and put all the tags there. Nobody expects a a way for the outline and a separate node inside it with all the tags--or more likely, a conflicting set of tags because some mappers didn't notice the redundancy. Why should a platform be any different? S On 2018-04-16 13:20, Jo wrote: > I knew this was going to be hard. Anyway, I made sure that it's definitely > allowed to tag bus stops as platform nodes. Every few months I look at the > wiki and each time it changes. At present it says that if a stop_position > node is present for a bus stop, it has to be added to the route relations. I > definitely don't agree with that and I won't do that. The route relations I'm > creating only contain 1 object per stop. Having said that, I won't be > removing stop_position nodes or platform ways from route relations, if they > are already present. Unless this proposal passes somehow, then I will help > with the conversion. > > My proposal does not say that it's not allowed or possible to map platforms > as ways or areas. > > It only says that for stability of the data, it would be better to map all > the detail tags on 1 node and only add that node to the route relations. > > If a platform is present, it's perfectly possible to tag it with > > highway=platform or railway=platform > and optionally > tactile_paving=yes > wheelchair=yes/limited/no > > Jo > > 2018-04-16 19:17 GMT+02:00 Stephen Sprunk : > On 2018-04-16 08:11, Philip Barnes wrote: > On 16 April 2018 07:46:13 BST, Jo wrote: > 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. > I think this is a good idea for bus routes as they are quite simple. > There is a sign, the passengers wait thereabouts, the bus stops so the > door is at this point and the passengers can then board, pay or show > their pass to the driver. Making this too complicated will deter > mappers from adding public transport. > > If mappers want to add additional information then they should be free > to do so but it should not be compulsory. To me, this is the crux of the debate. If mappers have put in additional data or detail that you don't care about, then you should ignore it rather than remove it (or demand that they do so), because some other consumer may want that additional data. Ignoring data that is present but not needed is always easier and more reliable than trying to deduce data that is needed but not present. If a consumer doesn't care about stop_position members, it's trivial to ignore them. If the current spec says they're mandatory, then propose making them optional; I would support that. I don't support prohibiting or removing them. If a consumer only wants a node for the platform but it's mapped as a way/area, then it's trivial to detect that and compute the centroid. I don't support replacing existing ways/areas with nodes or prohibiting new ways/areas in the future. If the current spec says they must be ways/areas, then propose making nodes allowed too; I thought that was already the case, but if not, I would support fixing that. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
Here in Belgium, we have normal buses and longer ones, either can have 2 doors or 3 doors. There is no way of knowing which of those buses is going to serve which stops at a given time. The only thing we do know for sure, is that we are supposed to get on in front, except for wheelchairs and parents with strollers. I fail to understand why stop_positions are considered to be that important. Especially for buses. For trains I might understand, but even there it's impossible to predict where exactly the doors will be when the train stops. And it's not important, what matters is when there are zones on the platforms, those we can map by splitting those platforms. Jo 2018-04-16 20:17 GMT+02:00 Ed Loach : > Stephen wrote: > > If a consumer doesn't care about stop_position members, it's trivial > > to > > ignore them. If the current spec says they're mandatory, then > > propose > > making them optional; I would support that. I don't support > > prohibiting > > or removing them. > > They are optional in the current spec. I don't bother with them in bus > route relations as physically a bus has to stop on a relation member way > close enough to the bus stop (platform) node for passengers to get on (with > the exact stop position depending whether the particular bus has doors at > front, middle or rear). > > Ed > > > ___ > Talk-transit mailing list > Talk-transit@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-transit > ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
I knew this was going to be hard. Anyway, I made sure that it's definitely allowed to tag bus stops as platform nodes. Every few months I look at the wiki and each time it changes. At present it says that if a stop_position node is present for a bus stop, it has to be added to the route relations. I definitely don't agree with that and I won't do that. The route relations I'm creating only contain 1 object per stop. Having said that, I won't be removing stop_position nodes or platform ways from route relations, if they are already present. Unless this proposal passes somehow, then I will help with the conversion. My proposal does not say that it's not allowed or possible to map platforms as ways or areas. It only says that for stability of the data, it would be better to map all the detail tags on 1 node and only add that node to the route relations. If a platform is present, it's perfectly possible to tag it with highway=platform or railway=platform and optionally tactile_paving=yes wheelchair=yes/limited/no Jo 2018-04-16 19:17 GMT+02:00 Stephen Sprunk : > On 2018-04-16 08:11, Philip Barnes wrote: > >> On 16 April 2018 07:46:13 BST, Jo wrote: >> >>> 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. >>> >> >> I think this is a good idea for bus routes as they are quite simple. >> There is a sign, the passengers wait thereabouts, the bus stops so the >> door is at this point and the passengers can then board, pay or show >> their pass to the driver. Making this too complicated will deter >> mappers from adding public transport. >> >> If mappers want to add additional information then they should be free >> to do so but it should not be compulsory. >> > > To me, this is the crux of the debate. If mappers have put in additional > data or detail that you don't care about, then you should ignore it rather > than remove it (or demand that they do so), because some other consumer may > want that additional data. Ignoring data that is present but not needed is > always easier and more reliable than trying to deduce data that is needed > but not present. > > If a consumer doesn't care about stop_position members, it's trivial to > ignore them. If the current spec says they're mandatory, then propose > making them optional; I would support that. I don't support prohibiting or > removing them. > > If a consumer only wants a node for the platform but it's mapped as a > way/area, then it's trivial to detect that and compute the centroid. I > don't support replacing existing ways/areas with nodes or prohibiting new > ways/areas in the future. If the current spec says they must be > ways/areas, then propose making nodes allowed too; I thought that was > already the case, but if not, I would support fixing that. > > S > > > -- > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
Stephen wrote: > If a consumer doesn't care about stop_position members, it's trivial > to > ignore them. If the current spec says they're mandatory, then > propose > making them optional; I would support that. I don't support > prohibiting > or removing them. They are optional in the current spec. I don't bother with them in bus route relations as physically a bus has to stop on a relation member way close enough to the bus stop (platform) node for passengers to get on (with the exact stop position depending whether the particular bus has doors at front, middle or rear). Ed ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
On 2018-04-16 08:11, Philip Barnes wrote: On 16 April 2018 07:46:13 BST, Jo wrote: 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. I think this is a good idea for bus routes as they are quite simple. There is a sign, the passengers wait thereabouts, the bus stops so the door is at this point and the passengers can then board, pay or show their pass to the driver. Making this too complicated will deter mappers from adding public transport. If mappers want to add additional information then they should be free to do so but it should not be compulsory. To me, this is the crux of the debate. If mappers have put in additional data or detail that you don't care about, then you should ignore it rather than remove it (or demand that they do so), because some other consumer may want that additional data. Ignoring data that is present but not needed is always easier and more reliable than trying to deduce data that is needed but not present. If a consumer doesn't care about stop_position members, it's trivial to ignore them. If the current spec says they're mandatory, then propose making them optional; I would support that. I don't support prohibiting or removing them. If a consumer only wants a node for the platform but it's mapped as a way/area, then it's trivial to detect that and compute the centroid. I don't support replacing existing ways/areas with nodes or prohibiting new ways/areas in the future. If the current spec says they must be ways/areas, then propose making nodes allowed too; I thought that was already the case, but if not, I would support fixing that. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
On 16 April 2018 07:46:13 BST, Jo wrote: > >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. Virgin West Coast use this system, there are a series of yellow numbers painted along the platform so that you will be in the right place for your carriage. > >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. I think this is a good idea for bus routes as they are quite simple. There is a sign, the passengers wait thereabouts, the bus stops so the door is at this point and the passengers can then board, pay or show their pass to the driver. Making this too complicated will deter mappers from adding public transport. If mappers want to add additional information then they should be free to do so but it should not be compulsory. I understand in big cities, such as that there London and in those places a more complex tagging is needed if for example a bus has multiple doors that are not at the front. Railway or tram platforms are large, dedicated areas and should be mapped as ways. Phil (trigpoint) -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
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 : > 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 fo
Re: [Talk-transit] Proposal for simplification of mapping public transport
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 Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
A few years ago it was meant as a way to comply with the PT v2 scheme. For me a nice side effect is/was that JOSM assigns a platform role automatically when adding them to route and stop_area relations. But it wouldn't be hard to reprogram it to do that for simply highway=bus_stop/railway=tram_stop. Dropping the public_transport tags on stops is covered by Ilya's proposal though. I'm somewhat indifferent to whether we do or don't drop those tags. My proposal is mostly about not adding 2 objects to the route relations for each stop and to keep all the stop's details together on that one object that is added to the route relations, preferably a node. Polyglot 2018-04-13 19:48 GMT+02:00 Selfish Seahorse : > On 11 April 2018 at 19:38, Roland Hieber wrote: > > However, a main reason why the Public Transport schema was adopted [1] > > was exactly this differentiation between stop position on the route and > > platform position/waiting area for the passengers. This was done to > > increase the expressiveness of OpenStreeMap data, and to make > > information more easier obtainable for routing software. After all, the > > two things are at different positions, and you cannot generally infer > > the one from the other. Reverting to the old schema would therefore > > take away that expressiveness. > > > > [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/ > Public_Transport#Goal_of_this_public_transport_proposal > > If the waiting area is mapped as a node, it can be projected on the > road or rail, thus making a separate stop position node on the road or > rail unnecessary. > > However, I think it is not very straightforward that this node is > proposed to be tagged public_transport=platform and a possible > physical platform highway=platform. In my opinion, tagging the waiting > area node only highway=bus_stop or railway=tram_stop would be much > less confusing. Besides these tags are self-explanatory. (And, as you > wrote, these tags will probably remain needed for rendering purposes > for a long time to come. Why double tagging then?) > > ___ > Talk-transit mailing list > Talk-transit@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-transit > ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
On 11 April 2018 at 19:38, Roland Hieber wrote: > However, a main reason why the Public Transport schema was adopted [1] > was exactly this differentiation between stop position on the route and > platform position/waiting area for the passengers. This was done to > increase the expressiveness of OpenStreeMap data, and to make > information more easier obtainable for routing software. After all, the > two things are at different positions, and you cannot generally infer > the one from the other. Reverting to the old schema would therefore > take away that expressiveness. > > [1]: > https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Goal_of_this_public_transport_proposal If the waiting area is mapped as a node, it can be projected on the road or rail, thus making a separate stop position node on the road or rail unnecessary. However, I think it is not very straightforward that this node is proposed to be tagged public_transport=platform and a possible physical platform highway=platform. In my opinion, tagging the waiting area node only highway=bus_stop or railway=tram_stop would be much less confusing. Besides these tags are self-explanatory. (And, as you wrote, these tags will probably remain needed for rendering purposes for a long time to come. Why double tagging then?) ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
Mapping stop_position nodes is just fine. I would simply not add them to the route relations. Mapping platforms as ways or areas adds enhances detail. But no need to add them to the route relations. The proposal is about having 1 object to represent the stops for its whole lifetime and nodes happen to be the most suitable kind of object for this. Add all the pertinent details to this object and only add this object to the route relations, once each time the vehicle serves it for that particular itinerary variation. (route relation) I've been using this scheme in Belgium, a country with 3-4 PT operators for several years now and it works really well. I knew it was going to be hard to propose a change, that for some is somewhat radical. It does not mean that we're reverting back to PT "v1" though. Everything can still be expressed in as much detail as needed or wanted. But to enhance the detail during the lifetime of the stop, it won't be needed to transfer tags from one object to another, or to replace objects in the route relations. We need a scheme that is easy to maintain by anybody and what I see happening in Germany mostly, but also elsewhere around Europe, based on what is described in the wiki is overly complex, thus making it only for "experts", and we don't have enough of those. Polyglot 2018-04-11 19:38 GMT+02:00 Roland Hieber : > On Mon, Apr 09, 2018 at 07:19:32PM +0200, Jo wrote: > > Here goes my proposal for a reform in mapping public transport: > > > > https://wiki.openstreetmap.org/wiki/Proposed_features/ > Public_Transport_map_all_stops_as_nodes > [...] > > As I understand it, in Public Transport schema speech, this proposal > comes down to removing all public_transport=stop_position nodes (i.e. > the position where a train/bus/… stops on the street) from the route > relations, and retaining the public_transport=platform information > (i.e. where the passengers wait or where the station pole is located). > This would be effectively reverting part of the Public Transport schema, > and going back to the way platforms were mapped previously. > > However, a main reason why the Public Transport schema was adopted [1] > was exactly this differentiation between stop position on the route and > platform position/waiting area for the passengers. This was done to > increase the expressiveness of OpenStreeMap data, and to make > information more easier obtainable for routing software. After all, the > two things are at different positions, and you cannot generally infer > the one from the other. Reverting to the old schema would therefore > take away that expressiveness. > > [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/ > Public_Transport#Goal_of_this_public_transport_proposal > > Furthermore, quoting from the proposal: > > > Rationale > > > > - nodes are convenient to work with and move, if needed, also using > > mobile apps > > This is true, but per the Public Transport schema you can already map > both public_transport=stop_position and public_transport=platform as > single nodes. Your additional argument that both a node and a way could > be added for the platform would not lead to more expressiveness, but > only to more duplication of data. (As simple as possible, as complex as > necessary.) > > > - nodes have coordinates directly, no extra calculation required > > - nodes are easy to work with using MapCSS, [...] > > See above. Also, every way consists of nodes, which have a coordinates. > Just take any. > > > - making comparison of location and tags with external sources is > > straightforward > > I don't know how this is meant, but the complexity of tag extraction > from objects will be the same whether they are mapped on a node or > mapped on a way. Also the main work here is probably to match the > external database schema to the OpenStreetMap data schema, as they will > most probably not be very similar. > > That's all I can think of for now. > > - Roland > ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
On Mon, Apr 09, 2018 at 07:19:32PM +0200, Jo wrote: > Here goes my proposal for a reform in mapping public transport: > > https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_map_all_stops_as_nodes [...] As I understand it, in Public Transport schema speech, this proposal comes down to removing all public_transport=stop_position nodes (i.e. the position where a train/bus/… stops on the street) from the route relations, and retaining the public_transport=platform information (i.e. where the passengers wait or where the station pole is located). This would be effectively reverting part of the Public Transport schema, and going back to the way platforms were mapped previously. However, a main reason why the Public Transport schema was adopted [1] was exactly this differentiation between stop position on the route and platform position/waiting area for the passengers. This was done to increase the expressiveness of OpenStreeMap data, and to make information more easier obtainable for routing software. After all, the two things are at different positions, and you cannot generally infer the one from the other. Reverting to the old schema would therefore take away that expressiveness. [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Goal_of_this_public_transport_proposal Furthermore, quoting from the proposal: > Rationale > > - nodes are convenient to work with and move, if needed, also using > mobile apps This is true, but per the Public Transport schema you can already map both public_transport=stop_position and public_transport=platform as single nodes. Your additional argument that both a node and a way could be added for the platform would not lead to more expressiveness, but only to more duplication of data. (As simple as possible, as complex as necessary.) > - nodes have coordinates directly, no extra calculation required > - nodes are easy to work with using MapCSS, [...] See above. Also, every way consists of nodes, which have a coordinates. Just take any. > - making comparison of location and tags with external sources is > straightforward I don't know how this is meant, but the complexity of tag extraction from objects will be the same whether they are mapped on a node or mapped on a way. Also the main work here is probably to match the external database schema to the OpenStreetMap data schema, as they will most probably not be very similar. That's all I can think of for now. - Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
2018-04-10 16:23 GMT+02:00 Stephen Sprunk : > But for the thousands of platform ways/areas that do already exist, you're > proposing that someone has to go back and add nodes, move all the tags > over, change which is the relation member, etc.? That's not very friendly. > You can rest assured that if the proposal happens to make it, I'll make sure there are tools to help with that conversion. Compared to the thousands upon thousands of stops and route relations that still need to be mapped, their number is relatively small. Polyglot ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
But for the thousands of platform ways/areas that do already exist, you're proposing that someone has to go back and add nodes, move all the tags over, change which is the relation member, etc.? That's not very friendly. S On 2018-04-10 00:41, Jo wrote: > The proposal doesn't say that it's not possible to map the actual platforms > as ways or areas in ADDITION to that node, if they are actually present. > > What it says is that it's not necessary to transfer all the details from the > node to the way/area and replace the node in the route relations. > > The node REPRESENTING the stop keeps fulfilling this function for the > lifetime of the stop's 'existence'. > > Jo > > 2018-04-10 2:43 GMT+02:00 Bill Ricker : > >> On Mon, Apr 9, 2018 at 1:19 PM, Jo wrote: >>> Here goes my proposal for a reform in mapping public transport: >> >> [nodes not platforms] >> >> If this applies to Heavy Rail and Light Rail rapid transit and not >> just Bus Stops, I object. >> >> The Transport layer on OpenStreetMap is much more useful at high zoom >> levels with Platform entities in the DB than it would be without them. >> >> From >> https://www.openstreetmap.org/query?lat=42.34752&lon=-71.09989#map=18/42.34678/-71.09936&layers=T >> [1] >> one can see that the two lines do NOT share a platform so that one can >> not change directions with a wheelchair without taking two elevators, >> either of which may be out of service; but if there was only one >> platform between two lines, one could. >> THIS IS USEFUL TO MAP. >> >> I support simplicity, but agree with Einstein: Things should be as >> simple as possible, but not simpler. This proposal goes too far. >> >> -- >> Bill Ricker >> bill.n1...@gmail.com >> https://www.linkedin.com/in/n1vux [2] > > ___ > Talk-transit mailing list > Talk-transit@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-transit -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov Links: -- [1] https://www.openstreetmap.org/query?lat=42.34752&lon=-71.09989#map=18/42.34678/-71.09936&layers=T [2] https://www.linkedin.com/in/n1vux___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
The proposal doesn't say that it's not possible to map the actual platforms as ways or areas in ADDITION to that node, if they are actually present. What it says is that it's not necessary to transfer all the details from the node to the way/area and replace the node in the route relations. The node REPRESENTING the stop keeps fulfilling this function for the lifetime of the stop's 'existence'. Jo 2018-04-10 2:43 GMT+02:00 Bill Ricker : > On Mon, Apr 9, 2018 at 1:19 PM, Jo wrote: > > Here goes my proposal for a reform in mapping public transport: > > [nodes not platforms] > > If this applies to Heavy Rail and Light Rail rapid transit and not > just Bus Stops, I object. > > The Transport layer on OpenStreetMap is much more useful at high zoom > levels with Platform entities in the DB than it would be without them. > > From > https://www.openstreetmap.org/query?lat=42.34752&lon=-71. > 09989#map=18/42.34678/-71.09936&layers=T > one can see that the two lines do NOT share a platform so that one can > not change directions with a wheelchair without taking two elevators, > either of which may be out of service; but if there was only one > platform between two lines, one could. > THIS IS USEFUL TO MAP. > > I support simplicity, but agree with Einstein: Things should be as > simple as possible, but not simpler. This proposal goes too far. > > > -- > Bill Ricker > bill.n1...@gmail.com > https://www.linkedin.com/in/n1vux > ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
On Mon, Apr 9, 2018 at 1:19 PM, Jo wrote: > Here goes my proposal for a reform in mapping public transport: [nodes not platforms] If this applies to Heavy Rail and Light Rail rapid transit and not just Bus Stops, I object. The Transport layer on OpenStreetMap is much more useful at high zoom levels with Platform entities in the DB than it would be without them. From https://www.openstreetmap.org/query?lat=42.34752&lon=-71.09989#map=18/42.34678/-71.09936&layers=T one can see that the two lines do NOT share a platform so that one can not change directions with a wheelchair without taking two elevators, either of which may be out of service; but if there was only one platform between two lines, one could. THIS IS USEFUL TO MAP. I support simplicity, but agree with Einstein: Things should be as simple as possible, but not simpler. This proposal goes too far. -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Proposal for simplification of mapping public transport
Here goes my proposal for a reform in mapping public transport: https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_map_all_stops_as_nodes This is how I would change the main topic: https://wiki.openstreetmap.org/wiki/User:Polyglot/Public_transport Polyglot ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit