Re: [Talk-transit] different interpretations of v2 PT scheme
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. Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time. The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ? My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so. It seems to be more a problem with toxic mappers more than the PT scheme At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes. In theory, redundant details on the same stop should be put in the stop_area relation in order to reduce redundancy. The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position? See above. Éric ___ 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-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 attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time. The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ? I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once. My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so. It seems to be more a problem with toxic mappers more than the PT scheme They moved the details to the stop_position, which I don't consider for processing. At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes. In theory, redundant details on the same stop should be put in the stop_area relation in order to reduce redundancy. That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation. The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position? See above. Éric ___ 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] different interpretations of v2 PT scheme
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 attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time. The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ? I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once. My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so. It seems to be more a problem with toxic mappers more than the PT scheme They moved the details to the stop_position, which I don't consider for processing. At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes. In theory, redundant details on the same stop should be put in the stop_area relation in order to reduce redundancy. That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation. The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position? See above. Éric ___ 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 ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] different interpretations of v2 PT scheme
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 attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time. The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ? I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once. My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so. It seems to be more a problem with toxic mappers more than the PT scheme They moved the details to the stop_position, which I don't consider for processing. At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes. In theory, redundant details on the same stop should be put in the stop_area relation in order to reduce redundancy. That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation. The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position? See above. Éric ___ 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 ___ 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-01 10:53 GMT+02:00 Jo winfi...@gmail.com: That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation. I don't see what attributes of a stop/platform could be dependant on the direction, do you have examples ? Anyway, if there really is different informations on each stop, it is okay to put them in the nodes/way and only put data applicable to all stops in the stop_area in the stop_area relation. This is the usual way of using relations : aggregate common data between multiple features in a relation containing said features, and if there is differences between these features put the tags directly on the nodes/ways. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] different interpretations of v2 PT scheme
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 attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time. The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ? I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once. My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so. It seems to be more a problem with toxic mappers more than the PT scheme They moved the details to the stop_position, which I don't consider for processing. At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes. In theory, redundant details on the same stop should be put in the stop_area relation in order to reduce redundancy. That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for
Re: [Talk-transit] different interpretations of v2 PT scheme
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 attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time. The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ? I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once. My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so. It seems to be more a problem with toxic mappers more than the PT scheme They moved the details to the stop_position, which I don't consider
