[Talk-transit] Ideas for a simplified public transportation scheme
jarek at piorkowski.ca
Sat Apr 27 14:35:55 UTC 2019
I noticed that OsmAnd has recently introduced support for some public
transit routing: https://osmand.net/blog/guideline-pt . Has anyone
used it or is familiar with the implementation? I would guess it would
make them one of the bigger consumers of public transit relations in
OSM and it might make sense to check what they absolutely need and
what is a nice to have. Do we know of any other major consumers of
public transit relations?
For example, do consumers need the ways to always connect for
routing/time calculation, or is it only for display on map? If it is
the latter, it makes relations breaking due to way splits less
Here's my point of view as a mapper who is interested in adding
transit and having the information suitable for basic offline transit
routing. Note that I've mostly done surface routes so far, and don't
have a good sense of how PTv1/PTv2 works for underground.
- Standard PTv1 not supporting directions makes it not very useful
except for visual inspection by a human and as a way of keeping track
of stops as base for upgrade to machine-readable PTv2
- My understanding of
https://wiki.openstreetmap.org/wiki/Public_transport is that
stop_position is optional ("If you choose to add a stop position
node..."). If it is in fact optional for data consumers as well
(OsmAnd?), it could be skipped when it would be too much effort.
- I am personally not that bothered by "platform" for PTv2 - as a
speaker of non-British English I am used to some terms in OSM not
meaning what I use them to mean. I am a;sp not bothered by bus=yes on
platform (IMO pretty clear from context and comparable to "emergency"
tag) but I see from talk page for the  proposal that Zverik isn't a
- Regarding Markus's suggestion #3 for introducing
public_transport=stop, wouldn't it be simpler to redefine
highway=bus_stop / railway=tram_stop to mean the same thing? It might
be simpler to redefine public transport relations to allow use of
hw=bus_stop / rw=tram_stop for waiting area at stops that don't have a
defined platform - and that many data consumers already use them is a
plus. As far as I can tell this is basically what the Stockholm
example linked does, isn't it? I don't know the history of
introduction of PTv2 so perhaps I'm missing some disadvantages of
On Fri, 26 Apr 2019 at 11:11, Markus <selfishseahorse at gmail.com> wrote:
> Hi all,
> I've added, updated and corrected several dozen public transportation
> routes in the past few years using the PTv2 scheme. As is the case
> with most route relations, they often break (e.g., because the course
> of a road or rails is modified, a new roundabout is built, a stop is
> displaced or simply by accident). However, with all the stop_positions
> and stop_areas, maintaining these routes and stops is very much
> There have been several ideas to simplify and improve public
> transportation mapping (e.g.  or ), however they either faced
> too much opposition or are inactive. Therefore I've worked out three
> different drafts for an improved public transportation scheme and
> would like your opinion. After that, i plan to write a full proposal
> for the option that got the most support.
> In order to better understand how I came up with the ideas below, I
> have first listed the deficiencies of the current public transport
> Deficiencies of PTv1:
> * No separate route relation per direction and route variant.
> * Platforms at stations cannot be added to route relations, which
> prevents a better routing.
> * Stops (highway=bus_stop/railway=tram_stop) are often placed on the
> road or rail, which is not optimal for routing.
> Deficiencies of PTv2:
> * public_transport=stop_position and public_transport=stop_area make
> mapping and maintaining complicated and time-consuming. Besides,
> public_transport=stop_position is unnecessary, as it can be calculated
> from public_transport=platform (which provide a more exact routing).
> * Counter-intuitive public_transport=platform: its meaning depends
> on whether used on way/area (where it means a platform) or on node
> (where it means a waiting area w/o platform).
> * Not possible to add transport mode tags (e.g. bus=yes) on
> public_transport=platform because they are also used to set access.
> Now for the possible solutions:
> 1. Sticking to PTv1 tags, but with separate route relations per
> direction/variant and by placing stops at the point where passengers
> wait. A stop with a platform get a railway/highway=platform way/area
> and a railway=tram_stop/highway=bus_stop node. (Except at stations, a
> stop_area relation is not required because the stop node is placed on
> the platform.) -- Advantage: Widely used tags, least retagging
> required. Disadvantage: A stop with a platform needs two elements (as
> railway/highway=platform + railway=tram_stop/highway=bus_stop can't be
> 2. Sticking to PTv2 tags, but abandoning
> public_transport=stop_position and introducing a new transport_mode=*
> tag. -- Advantage: Only one element per stop. Disadvantage: The rather
> counter-intuitive public_transport=platform remains.
> 3. Abolishing public_transport=stop_position and
> public_transport=platform and introducing a new public_transport=stop
> tag (node/way/area) for the waiting area at stops, which can be
> combined with railway/highway=platform if the stop consists of a
> platform. Besides, introducing a new transport_mode=* tag. --
> Advantage: Only one element per stop, very flexible and clear.
> Disadvantage: Much retagging required.
> : https://wiki.openstreetmap.org/wiki/Proposed_features/Transport_modes_on_platforms_and_stations
> : https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport
> Thanks in advance for your replies.
> Best regards
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
More information about the Talk-transit