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
