<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Now I don't mind using it, just like I wouldn't mind dropping it.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><a href="https://www.youtube.com/watch?v=KVcKredS0kA">https://www.youtube.com/watch?v=KVcKredS0kA</a><br></div><div><br></div><div>PT_Assistant's validator will tell you about this and JOSM will make it easy to correct the situation.</div><div><br></div><div>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.</div><div><br></div><div>Polyglot</div></div><br><div class="gmail_quote"><div dir="ltr">Op wo 25 jul. 2018 om 22:56 schreef SelfishSeahorse <<a href="mailto:selfishseahorse@gmail.com">selfishseahorse@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
It seems that the only problem with PTv2 that remains is the rendering<br>
of public_transport=platform, i.e. whether public_transport=platform<br>
(and maybe public_transport=station too) should get the transport mode<br>
tag(s) (bus=yes/tram=yes/...).<br>
<br>
Note that the PTv2 proposal suggested to map the *stop position* 'as<br>
an icon depending of the vehicle type that is stopping at the<br>
position',[1] which may have led to some people mapping only<br>
stop_position's, others mapping only platform's and still others<br>
mapping stop_position's and platform's which in turn has led to<br>
complication and confusion.<br>
<br>
[1]: <a href="https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3</a><br>
<br>
As this question pops up every now and then, it might make sense to<br>
finish discussing this.<br>
<br>
I'm double posting this message on the transport mailing list, so that<br>
the discussion can continue there.<br>
<br>
Regards<br>
Markus<br>
<br>
On Wed, 25 Jul 2018 at 19:25, Roland Olbricht <<a href="mailto:roland.olbricht@gmx.de" target="_blank">roland.olbricht@gmx.de</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> > What I would like to see is how to map a Public Transport Route in<br>
> > version 3 .. that has the bear minimum of things to have and the rules<br>
> > that make the route valid.<br>
><br>
> This is where the problem sits; the point of view of what a route is<br>
> vary wildly. Few people are even willing to pinpoint and tell their<br>
> personal definition.<br>
><br>
> Things that exist under the notion of route:<br>
><br>
> - Urban bus/tram/subway services (many stops, many departures, route<br>
> taken always or almost always the same, route through the street grid<br>
> practically fixed, often unchanged for years to decades)<br>
><br>
> - Peak services, special routes to depot, school services (few<br>
> departures, many stops, also many route variants, frequently changing,<br>
> making it impractical to route them all)<br>
><br>
> - Hail bus services: the bus is promised to serve a certain street and<br>
> stops on hail (many departures, route taken always or almost always the<br>
> same, route through the street grid practically fixed, often unchanged<br>
> for years to decades)<br>
><br>
> - Urban and regional train lines (many stops, many departures, route and<br>
> platforms fixed). Those routes are often in parts or completely land marks.<br>
><br>
> - Long distance train lines (many stops, many departures, route and<br>
> platforms may or may not vary, can stop at a different platform of the<br>
> same station for operational reasons)<br>
><br>
> - Long distance bus services (few stops, few departures, route between<br>
> stops often changing on the fly)<br>
><br>
> - Ferry lines (often only two stops, completely different<br>
> infrastructure)<br>
><br>
> Further kinds of routes may exist. For example, some communties use<br>
> virtual metro lines that connect station node to station node. This is<br>
> most often because the communties lack the ressources to map the actual<br>
> underground structures.<br>
><br>
> I personally map only urban bus/tram/subway services and urban and<br>
> regional train lines (and do not delete other routes). For these<br>
> services it is sane to have marked the stops and the route on the grid.<br>
><br>
> The route on the grid is straightforward: this is in any PT scheme a<br>
> sequence of way members that together form a continuous trajectory. Hail<br>
> sections get a special role for these members.<br>
><br>
> The stop part is more tricky. I personally add one element for each stop<br>
> where the bus/train is calling, using the role "platform". The member<br>
> element should have the tag "name" set to ensure meaningful usage and<br>
> pain-free editing of the route.<br>
><br>
> The minimum required tags on the relation are "ref=<Line Number>",<br>
> somtimes "name=<Name>", and "type=route" + "route=bus" for buses.<br>
><br>
> Please do not forget that a more detailed explaination fits better on<br>
> the transit list<br>
> <a href="https://lists.openstreetmap.org/listinfo/talk-transit" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-transit</a><br>
> I would suggest to continue the discussion there, but Ilya has for<br>
> unknown reason fear of the talk-transit list. It makes sense to give him<br>
> an easy opportunity to answer.<br>
><br>
> I read Ilya's proposal such that he wants to feature the virtual metro<br>
> lines, at the expense of mandating to map hail services as empty<br>
> relations. But it would be better if he tells us himself.<br>
><br>
> Best regards,<br>
> Roland<br>
><br>
> _______________________________________________<br>
> Tagging mailing list<br>
> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>