Re: [Talk-transit] different interpretations of v2 PT scheme
2015-07-02 14:21 GMT+02:00 Nounours77 kuessemondtaegl...@gmail.com: I think Jo is right to rise this problem. It is unclear which stop/platform belongs to which direction of the route. Often you can decude it from proximity, or from the side. But I've seen quite some examples, where only the stop_positions are mapped, and if they are quite distant, you have no way to find out to which direction of the route it belongs. I think variant of a route is more appropriate than side. Platforms and stop_positions are present in a PTv2 route relation, so it's easy to find which ones belong to which side/variant of a route. On the other side, the stop_area relation should group stops from different lines, to be able to show the correct communting between lines. That's precisely the goal of the stop_area relation. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] different interpretations of v2 PT scheme
Scenario: I have data from 'upstream'. This data relates to public_transport=platform nodes next to the way What I need now, is to figure out which nearby way 'belongs' to this 'platform'. If there is a stop_area relation, this is easy (as long as there is a stop_area relation which contains a platform and a stop_position pair). (Note that there are also stops where several buses can stop one after another, so it's not impossible to have more than 1 stop_position for a single platform) The opposite is also possible, but less likely to be needed. It is true that there are many cases where the relation between platform and stop_area can be made unambiguously based on proximity. Note that I'm doing this in JOSM not in a geographically enabled database. There are also times that a stop_position is not needed to get from a platform to the candidate way that needs to be added to the route relation. Anyway, I wouldn't try to abolish stop_area relations, but rather make sure that SA relations can be grouped together into stop_area_group relations. This makes sense for bus stations where the separate stop_area relations will have names with numbers or letters after them. Jo 2015-07-02 15:52 GMT+02:00 Janko Mihelić jan...@gmail.com: If you are adding stop_areas, then there certainly have to be two of them, one on each side. One of them is put in the route that goes one way, the other one is put in the other way. I'm also pretty sure that the stop_area_group is not needed. If they are near each other, then it's a group. But to someone near each other means within 400m, to someone in a wheelchair it means ramps, to a blind person it means traffic lights with sound. What else can a group achieve that spatial placement can't? Maybe if a group has a ref. After all this, I'm not sure that stop_area is absolutely necessary. Stop_position and platform are nearby, so there is really not that much chance an algorithm is going to connect the wrong ones. If it was me, I would just add all the refs to the platform, like you did, and ignore all the refs on the stop_position. Job done, no relations needed. čet, 2. srp 2015. u 00:54 Jo winfi...@gmail.com napisao je: I tend to add the waste_basket that clearly 'belongs' to the bus stop, the bench, the shelter, the ticker/departures screen in as well. Most of the time they have a style you don't see elsewhere. Never occurred to me to add toilets or flowers or pubs though. But do we agree a stop_area relation is needed for each side of a street? and a stop_area_group to show that they belong together? Jo 2015-07-02 0:31 GMT+02:00 Janko Mihelić jan...@gmail.com: To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing. But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries. Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt. sri, 1. srp 2015. u 13:55 Jo winfi...@gmail.com napisao je: What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another. I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose. It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (5 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops. What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time. Polyglot 2015-07-01 11:59 GMT+02:00 Jo winfi...@gmail.com: I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme. What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation
Re: [Talk-transit] different interpretations of v2 PT scheme
If you are adding stop_areas, then there certainly have to be two of them, one on each side. One of them is put in the route that goes one way, the other one is put in the other way. I'm also pretty sure that the stop_area_group is not needed. If they are near each other, then it's a group. But to someone near each other means within 400m, to someone in a wheelchair it means ramps, to a blind person it means traffic lights with sound. What else can a group achieve that spatial placement can't? Maybe if a group has a ref. After all this, I'm not sure that stop_area is absolutely necessary. Stop_position and platform are nearby, so there is really not that much chance an algorithm is going to connect the wrong ones. If it was me, I would just add all the refs to the platform, like you did, and ignore all the refs on the stop_position. Job done, no relations needed. čet, 2. srp 2015. u 00:54 Jo winfi...@gmail.com napisao je: I tend to add the waste_basket that clearly 'belongs' to the bus stop, the bench, the shelter, the ticker/departures screen in as well. Most of the time they have a style you don't see elsewhere. Never occurred to me to add toilets or flowers or pubs though. But do we agree a stop_area relation is needed for each side of a street? and a stop_area_group to show that they belong together? Jo 2015-07-02 0:31 GMT+02:00 Janko Mihelić jan...@gmail.com: To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing. But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries. Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt. sri, 1. srp 2015. u 13:55 Jo winfi...@gmail.com napisao je: What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another. I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose. It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (5 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops. What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time. Polyglot 2015-07-01 11:59 GMT+02:00 Jo winfi...@gmail.com: I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme. What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street. Jo 2015-07-01 11:43 GMT+02:00 Richard Mann richard.mann.westoxf...@gmail.com: Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers. Richard On Wed, Jul 1, 2015 at 9:53 AM, Jo winfi...@gmail.com wrote: 2015-07-01 10:00 GMT+02:00 Éric Gillet gill3t.3ric+...@gmail.com: 2015-07-01 7:38 GMT+02:00 Jo winfi...@gmail.com: In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole. A platform can be a pole, or a shelter, or a dock, or a boarding platform for a train... It is meant to abstract differences between different means of transport. That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation. Anyway, the
Re: [Talk-transit] different interpretations of v2 PT scheme
2015-07-02 15:52 GMT+02:00 Janko Mihelić jan...@gmail.com: If you are adding stop_areas, then there certainly have to be two of them, one on each side. One of them is put in the route that goes one way, the other one is put in the other way. I'm also pretty sure that the stop_area_group is not needed. If they are near each other, then it's a group. But to someone near each other means within 400m, to someone in a wheelchair it means ramps, to a blind person it means traffic lights with sound. What else can a group achieve that spatial placement can't? Maybe if a group has a ref. Aggregate data to reduce duplication, and provide strong and explicit links betweens features. After all this, I'm not sure that stop_area is absolutely necessary. Stop_position and platform are nearby, so there is really not that much chance an algorithm is going to connect the wrong ones. If it was me, I would just add all the refs to the platform, like you did, and ignore all the refs on the stop_position. Job done, no relations needed. In a mutlimodal hub (rail,buses, etc.) that could easily be the case. Anyway explicit is most often better than implicit. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] different interpretations of v2 PT scheme
I think Jo is right to rise this problem. It is unclear which stop/platform belongs to which direction of the route. Often you can decude it from proximity, or from the side. But I've seen quite some examples, where only the stop_positions are mapped, and if they are quite distant, you have no way to find out to which direction of the route it belongs. On the other side, the stop_area relation should group stops from different lines, to be able to show the correct communting between lines. So, if two buslines cross perpendicularly, normally there are four stops, each belonging to one line in one direction. On one hand, all four should be in the same stop_area (for communting), but then there might be some disambiguity on which belongs to which. (my personal solution is: map stops and platforms, so 4 each, and put BOTH, stop and platform into the route relation, but this seems not to supported by the JOSM verificator). nounours77 Am 02.07.2015 um 00:53 schrieb Jo winfi...@gmail.com: I tend to add the waste_basket that clearly 'belongs' to the bus stop, the bench, the shelter, the ticker/departures screen in as well. Most of the time they have a style you don't see elsewhere. Never occurred to me to add toilets or flowers or pubs though. But do we agree a stop_area relation is needed for each side of a street? and a stop_area_group to show that they belong together? Jo 2015-07-02 0:31 GMT+02:00 Janko Mihelić jan...@gmail.com mailto:jan...@gmail.com: To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing. But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries. Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt. sri, 1. srp 2015. u 13:55 Jo winfi...@gmail.com mailto:winfi...@gmail.com napisao je: What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another. I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose. It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (5 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops. What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time. Polyglot 2015-07-01 11:59 GMT+02:00 Jo winfi...@gmail.com mailto:winfi...@gmail.com: I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme. What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street. Jo 2015-07-01 11:43 GMT+02:00 Richard Mann richard.mann.westoxf...@gmail.com mailto:richard.mann.westoxf...@gmail.com: Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers. Richard On Wed, Jul 1, 2015 at 9:53 AM, Jo winfi...@gmail.com mailto:winfi...@gmail.com wrote: 2015-07-01 10:00 GMT+02:00 Éric Gillet gill3t.3ric+...@gmail.com mailto:gill3t.3ric+...@gmail.com: 2015-07-01 7:38 GMT+02:00 Jo winfi...@gmail.com mailto:winfi...@gmail.com: In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole. A platform can be a pole, or a shelter, or a dock, or a boarding platform for a train... It is meant
Re: [Talk-transit] different interpretations of v2 PT scheme
In the UK, the NaPTAN standard uses a stop area to group stops together, such that you have one stop in each direction within the same stop area, or a whole bus station within a stop area. Shaun On 2 Jul 2015, at 14:52, Janko Mihelić jan...@gmail.com wrote: If you are adding stop_areas, then there certainly have to be two of them, one on each side. One of them is put in the route that goes one way, the other one is put in the other way. I'm also pretty sure that the stop_area_group is not needed. If they are near each other, then it's a group. But to someone near each other means within 400m, to someone in a wheelchair it means ramps, to a blind person it means traffic lights with sound. What else can a group achieve that spatial placement can't? Maybe if a group has a ref. After all this, I'm not sure that stop_area is absolutely necessary. Stop_position and platform are nearby, so there is really not that much chance an algorithm is going to connect the wrong ones. If it was me, I would just add all the refs to the platform, like you did, and ignore all the refs on the stop_position. Job done, no relations needed. čet, 2. srp 2015. u 00:54 Jo winfi...@gmail.com mailto:winfi...@gmail.com napisao je: I tend to add the waste_basket that clearly 'belongs' to the bus stop, the bench, the shelter, the ticker/departures screen in as well. Most of the time they have a style you don't see elsewhere. Never occurred to me to add toilets or flowers or pubs though. But do we agree a stop_area relation is needed for each side of a street? and a stop_area_group to show that they belong together? Jo 2015-07-02 0:31 GMT+02:00 Janko Mihelić jan...@gmail.com mailto:jan...@gmail.com: To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing. But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries. Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt. sri, 1. srp 2015. u 13:55 Jo winfi...@gmail.com mailto:winfi...@gmail.com napisao je: What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another. I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose. It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (5 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops. What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time. Polyglot 2015-07-01 11:59 GMT+02:00 Jo winfi...@gmail.com mailto:winfi...@gmail.com: I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme. What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street. Jo 2015-07-01 11:43 GMT+02:00 Richard Mann richard.mann.westoxf...@gmail.com mailto:richard.mann.westoxf...@gmail.com: Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers. Richard On Wed, Jul 1, 2015 at 9:53 AM, Jo winfi...@gmail.com mailto:winfi...@gmail.com wrote: 2015-07-01 10:00 GMT+02:00 Éric Gillet gill3t.3ric+...@gmail.com mailto:gill3t.3ric+...@gmail.com: 2015-07-01 7:38 GMT+02:00 Jo
Re: [Talk-transit] different interpretations of v2 PT scheme
Eric I think you are falling into the trap of trying to cover too many things in one relationship. A stoparea to me as a public transport person is (defined functionally) a cluster of stoppoints at which it is possible to interchange between services – and as such it is also a collection of stops for which a single stop name can be shared (in the UK we then have a separate “indicator” to allow you to make the naming of each stoppoint unique within the stoparea. If ramps or other accessibility features are relevant then they should be coded as a separate parameter (attached to the route which can be walked between such stops) – likewise if a light-controlled crossing with audible signals exists, then that too is a separately coded feature. I am not sufficiently familiar with this in the context of mapping to know how best to advise these points are handled in a mapping context. To me it is better that the mapping focuses on the topographic features (including paths and equipment) and then service information can be overlaid from a public transport information system. Best wishes Roger From: Éric Gillet [mailto:gill3t.3ric+...@gmail.com] Sent: 02 July 2015 15:12 To: Public transport/transit/shared taxi related topics Subject: Re: [Talk-transit] different interpretations of v2 PT scheme 2015-07-02 15:52 GMT+02:00 Janko Mihelić jan...@gmail.com: If you are adding stop_areas, then there certainly have to be two of them, one on each side. One of them is put in the route that goes one way, the other one is put in the other way. I'm also pretty sure that the stop_area_group is not needed. If they are near each other, then it's a group. But to someone near each other means within 400m, to someone in a wheelchair it means ramps, to a blind person it means traffic lights with sound. What else can a group achieve that spatial placement can't? Maybe if a group has a ref. Aggregate data to reduce duplication, and provide strong and explicit links betweens features. After all this, I'm not sure that stop_area is absolutely necessary. Stop_position and platform are nearby, so there is really not that much chance an algorithm is going to connect the wrong ones. If it was me, I would just add all the refs to the platform, like you did, and ignore all the refs on the stop_position. Job done, no relations needed. In a mutlimodal hub (rail,buses, etc.) that could easily be the case. Anyway explicit is most often better than implicit. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] different interpretations of v2 PT scheme
2015-07-02 16:31 GMT+02:00 Roger Slevin ro...@slevin.plus.com: Eric I think you are falling into the trap of trying to cover too many things in one relationship. It seems like your email client did not display the quote properly. The only thing I said in the first paragraph is : Aggregate data to reduce duplication, and provide strong and explicit links betweens features. The part about ramps was written by Janko Mihelić jan...@gmail.com ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
