Very soon after PTv2 was 'accepted' I understood that if we would ever replace hw=bus_stop NODES with pt=platform, the mode of transport would need to be added on these nodes.
Ever since it's a back and forth pulling between yes the mode of transport can be added on them and NO the platforms don't need a mode of transport. In the mean time, I'm not so sure that there is willingness to 'deprecate' highway=bus_stop, not even sure if there ever was, and I guess there is no real need for it etiher. The problem with that kind of thinking is that it can lead to the conclusion the whole public_transport scheme is not needed for the stops. Now I don't mind using it, just like I wouldn't mind dropping it. What I do mind is the use of multiple objects in the route relations to represent the same stop and the perceived need to 'upgrade' stops from nodes to ways/areas during their lifecycle if there are actual platforms for passengers to wait on. I created a 10 minute screencast showing some new functionality in PT_Assistant, but more importantly it also shows the public_transport tags are a bit confusing to some. In this case the stops mapped nicely as nodes alongside the way got stop_position instead of platform as the value. https://www.youtube.com/watch?v=KVcKredS0kA PT_Assistant's validator will tell you about this and JOSM will make it easy to correct the situation. After stopping the recording I went on to fix the from/to tags and adding a route_master relation before uploading. But I wanted to keep the screencast concise and to the point. Polyglot Op wo 25 jul. 2018 om 22:56 schreef SelfishSeahorse < selfishseaho...@gmail.com>: > Hi > > It seems that the only problem with PTv2 that remains is the rendering > of public_transport=platform, i.e. whether public_transport=platform > (and maybe public_transport=station too) should get the transport mode > tag(s) (bus=yes/tram=yes/...). > > Note that the PTv2 proposal suggested to map the *stop position* 'as > an icon depending of the vehicle type that is stopping at the > position', which may have led to some people mapping only > stop_position's, others mapping only platform's and still others > mapping stop_position's and platform's which in turn has led to > complication and confusion. > > : > https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3 > > As this question pops up every now and then, it might make sense to > finish discussing this. > > I'm double posting this message on the transport mailing list, so that > the discussion can continue there. > > Regards > Markus > > On Wed, 25 Jul 2018 at 19:25, Roland Olbricht <roland.olbri...@gmx.de> > wrote: > > > > Hi, > > > > > What I would like to see is how to map a Public Transport Route in > > > version 3 .. that has the bear minimum of things to have and the rules > > > that make the route valid. > > > > This is where the problem sits; the point of view of what a route is > > vary wildly. Few people are even willing to pinpoint and tell their > > personal definition. > > > > Things that exist under the notion of route: > > > > - Urban bus/tram/subway services (many stops, many departures, route > > taken always or almost always the same, route through the street grid > > practically fixed, often unchanged for years to decades) > > > > - Peak services, special routes to depot, school services (few > > departures, many stops, also many route variants, frequently changing, > > making it impractical to route them all) > > > > - Hail bus services: the bus is promised to serve a certain street and > > stops on hail (many departures, route taken always or almost always the > > same, route through the street grid practically fixed, often unchanged > > for years to decades) > > > > - Urban and regional train lines (many stops, many departures, route and > > platforms fixed). Those routes are often in parts or completely land > marks. > > > > - Long distance train lines (many stops, many departures, route and > > platforms may or may not vary, can stop at a different platform of the > > same station for operational reasons) > > > > - Long distance bus services (few stops, few departures, route between > > stops often changing on the fly) > > > > - Ferry lines (often only two stops, completely different > > infrastructure) > > > > Further kinds of routes may exist. For example, some communties use > > virtual metro lines that connect station node to station node. This is > > most often because the communties lack the ressources to map the actual > > underground structures. > > > > I personally map only urban bus/tram/subway services and urban and > > regional train lines (and do not delete other routes). For these > > services it is sane to have marked the stops and the route on the grid. > > > > The route on the grid is straightforward: this is in any PT scheme a > > sequence of way members that together form a continuous trajectory. Hail > > sections get a special role for these members. > > > > The stop part is more tricky. I personally add one element for each stop > > where the bus/train is calling, using the role "platform". The member > > element should have the tag "name" set to ensure meaningful usage and > > pain-free editing of the route. > > > > The minimum required tags on the relation are "ref=<Line Number>", > > somtimes "name=<Name>", and "type=route" + "route=bus" for buses. > > > > Please do not forget that a more detailed explaination fits better on > > the transit list > > https://lists.openstreetmap.org/listinfo/talk-transit > > I would suggest to continue the discussion there, but Ilya has for > > unknown reason fear of the talk-transit list. It makes sense to give him > > an easy opportunity to answer. > > > > I read Ilya's proposal such that he wants to feature the virtual metro > > lines, at the expense of mandating to map hail services as empty > > relations. But it would be better if he tells us himself. > > > > Best regards, > > Roland > > > > _______________________________________________ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging