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.

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.


Op wo 25 jul. 2018 om 22:56 schreef SelfishSeahorse <>:

> 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',[1] 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.
> [1]:
> 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 <>
> 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
> >
> > 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 mailing list
Tagging mailing list

Reply via email to