[Talk-transit] different interpretations of v2 PT scheme

Thu Jul 2 12:21:41 UTC 2015

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 <winfixit at 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ć <janjko at gmail.com <mailto:janjko at 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 <winfixit at gmail.com <mailto:winfixit at 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 (50000 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 <winfixit at gmail.com <mailto:winfixit at 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.westoxford at gmail.com <mailto:richard.mann.westoxford at 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 <winfixit at gmail.com <mailto:winfixit at gmail.com>> wrote:
> 2015-07-01 10:00 GMT+02:00 Éric Gillet <gill3t.3ric+osm at gmail.com <mailto:gill3t.3ric+osm at gmail.com>>:
> 2015-07-01 7:38 GMT+02:00 Jo <winfixit at gmail.com <mailto:winfixit at 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 at openstreetmap.org <mailto:Talk-transit at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-transit <https://lists.openstreetmap.org/listinfo/talk-transit>
> 
> 
> 
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org <mailto:Talk-transit at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-transit <https://lists.openstreetmap.org/listinfo/talk-transit>
> 
> 
> 
> 
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org <mailto:Talk-transit at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-transit <https://lists.openstreetmap.org/listinfo/talk-transit>
> 
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20150702/befb3057/attachment.html>