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ć <[email protected]> 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 <[email protected] <mailto:[email protected]>> > 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ć <[email protected] > <mailto:[email protected]>>: > 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 <[email protected] <mailto:[email protected]>> > 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 <[email protected] > <mailto:[email protected]>>: > 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 <[email protected] > <mailto:[email protected]>>: > 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 <[email protected] > <mailto:[email protected]>> wrote: > 2015-07-01 10:00 GMT+02:00 Éric Gillet <[email protected] > <mailto:[email protected]>>: > 2015-07-01 7:38 GMT+02:00 Jo <[email protected] <mailto:[email protected]>>: > 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 > [email protected] <mailto:[email protected]> > https://lists.openstreetmap.org/listinfo/talk-transit > <https://lists.openstreetmap.org/listinfo/talk-transit> > > > > _______________________________________________ > Talk-transit mailing list > [email protected] <mailto:[email protected]> > https://lists.openstreetmap.org/listinfo/talk-transit > <https://lists.openstreetmap.org/listinfo/talk-transit> > > > > > _______________________________________________ > Talk-transit mailing list > [email protected] <mailto:[email protected]> > https://lists.openstreetmap.org/listinfo/talk-transit > <https://lists.openstreetmap.org/listinfo/talk-transit> > > _______________________________________________ > Talk-transit mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-transit
_______________________________________________ Talk-transit mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-transit
