[Tagging] Documentation issues of PT tagging schemes
roland.olbricht at gmx.de
Wed Jul 25 17:24:10 UTC 2018
> 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
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
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
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.
More information about the Tagging