[Talk-transit] Ideas for a simplified public transportation scheme
jwhelan0112 at gmail.com
Sun Apr 28 12:45:20 UTC 2019
I'm a little unclear about the advantage of using something other than
highway=bus_stop. Ottawa has a fairly large number of bus stops currently
tagged and mapped. They get reported from an open data source every few
years. There are people who hold the view that they should all be mapped
individually but the import does give us all the stops together with their
In theory just dropping in the reference numbers should give us the
relationship for a route.
On Sun, Apr 28, 2019, 7:47 AM Dave F via Talk-transit, <
talk-transit at openstreetmap.org> wrote:
> General points:
> Are Stop_Areas required?
> What are they for?
> Are they in use?/Who uses them?/Will they ever be used?*
> If there is a purpose for them, what should they consist of? I've seen
> shops, bike racks, litter bins included. Surely they're irrelevant?
> Remove public_transport=station/train=yes &
> public_transport=platform/train=yes from railways.
> They are purely duplication of the existing, much used
> railway=station/railway=platform respectively. They provide no
> additional information. Duplication is wasted effort. It leads to
> confusion & errors.
> The use of 'platform' seems to have been hi-jacked by PT to represent a
> stopping place instead of it's original true meaning of a physical
> raised area above road level to aid vehicle boarding. Is
> public_transport=platform required at all on bus stops? As with
> railways, use existing tags.
> * I think these questions need to be asked of all PT tags. From what I
> can ascertain the various schemas were developed in great detail to look
> good on paper, but appear to have little relevance to real world usage.
> I think this is further borne out by PT tags not being widely implemented.
> On 26/04/2019 16:10, Markus 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
> > time-consuming.
> > 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
> > schemes:
> > 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
> > combined).
> > 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.
> > :
> > :
> > Thanks in advance for your replies.
> > Best regards
> > Markus
> > _______________________________________________
> > Talk-transit mailing list
> > Talk-transit at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-transit
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-transit