[Talk-bo] Fwd: [Talk-transit] Ideas for a simplified public transportation scheme
marcoantoniofrias en gmail.com
Sab Abr 27 15:23:27 UTC 2019
Estan requiriendo ideas para mejorar el etiquetado de transporte publico
con el esquema version 2...
La conversación está en el hilo de talk-transit.
---------- Forwarded message ---------
From: Markus <selfishseahorse en gmail.com>
Date: Fri, 26 Apr 2019 at 15:11
Subject: [Talk-transit] Ideas for a simplified public transportation scheme
To: Public transport/transit/shared taxi related topics <
talk-transit en openstreetmap.org>
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.
Thanks in advance for your replies.
Talk-transit mailing list
Talk-transit en openstreetmap.org
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
Más información sobre la lista de distribución Talk-bo