[Talk-transit] Ideas for a simplified public transportation scheme
sophietheopossum at yandex.com
Sun Apr 28 16:14:58 UTC 2019
I gave it a shot, but I can't really think of a way to justify it. does
the original discussion explain it? some stops can have a large variety
of shops that technically are only accessible with a train ticket; and I
guess it could be slow for the renderer to calculate and some railway
stops are islands only accessible to travellers, so I guess any bins and
such are part of the stop area. the way I see it, if you need a ticket
to access it, then sure, it's part of the relation. otherwise? sure it
may have been made for it (most of my bus stops here have bins) but you
don't need a bus ticket to use it.
in terms of the duplicate station/platform tags, I imagine the idea is
that it 'simplifies' it. but... I feel in favour of railway, it's
shorter so I guess it takes up less storage, and it's more specific, so
you're less likely to run into some sort of difficult to define edge
where I live, the bus stops often have noticeably raised kerbs and a
distinguishable rectangle of asphalt that could be considered to be a
platform area; the buses lower their suspension to match that raised
On 4/28/19 12:46 PM, Dave F via Talk-transit 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
> 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
>> 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.
>> Best regards
>> Talk-transit mailing list
>> Talk-transit at openstreetmap.org
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
More information about the Talk-transit