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