Re: [Talk-transit] Ideas for a simplified public transportation scheme
On Sat, 27 Apr 2019 at 10:35, Jarek Piórkowski wrote: > ... 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? Responding to myself, I remembered that of course Maps.me also does offline routing on subway/LRT/city rail. As I understand the supported systems are those in http://osmz.ru/subways/ I would guess those systems are a little better mapped than bus routes, but would be good to hear what the Maps.me router requires: stop_positions? platforms? Going by the YAML files and validator messages on the site above, perhaps it is only railway=station and their entrances. --Jarek ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Ideas for a simplified public transportation scheme
Hi all,
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
crucial.
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 [1] proposal that Zverik isn't a
fan.
- 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
hw=bus_stop tagging.
Thanks,
--Jarek
On Fri, 26 Apr 2019 at 11:11, 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. [1] or [2]), 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
Re: [Talk-transit] Line colour, text colour and background colour
have to say I like the design choices! on topic though, I understand colour=* to be the generally accepted use for background/line colour. I was going to say I imagine the best way for the text might be something namespaced like colour:text=*... but after thinking about it, I guess this text is the ref, so I see no problem with ref:colour, the challenge though might be finding an renderer with support for that, I don't think it's too common On 4/27/19 12:03 PM, Héctor Ochoa wrote: Hi, Yesterday Zaragoza City Council unveiled its new bus network design. It gives each line a distinct text and background colour, as seen here: https://i2.wp.com/detalier.com/wp-content/uploads/2019/04/autobuses-urbanos-zaragoza-detalier-9.jpg https://i2.wp.com/detalier.com/wp-content/uploads/2019/04/autobuses-urbanos-zaragoza-detalier-8.jpg I am asking if https://wiki.openstreetmap.org/wiki/Key:ref:colour could be adapted to use it in public transport routes, or something similar that complements https://wiki.openstreetmap.org/wiki/Key:colour Thanks in advance! Héctor ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Ideas for a simplified public transportation scheme
On Fri, 2019-04-26 at 17:10 +0200, 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. [1] or [2]), 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. Somehow I think that it is too late to define one schema that would rule the world. Too much has already been mapped for it to be redone. But I might be wrong. I also share your observation that PTv2 is way too complex. For what it is worth I might point you to have a look at how things are mapped in Stockholm metropolitan region. It is our version of a simplified PTv2. Unfortunately there isn't any English language definition of it. But I hope an example is self explanatory enough https://www.openstreetmap.org/relation/2376126 Stockholm Public Transport Agency also uses OSM https://sl.se/en ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Line colour, text colour and background colour
Hi, Yesterday Zaragoza City Council unveiled its new bus network design. It gives each line a distinct text and background colour, as seen here: https://i2.wp.com/detalier.com/wp-content/uploads/2019/04/autobuses-urbanos-zaragoza-detalier-9.jpg https://i2.wp.com/detalier.com/wp-content/uploads/2019/04/autobuses-urbanos-zaragoza-detalier-8.jpg I am asking if https://wiki.openstreetmap.org/wiki/Key:ref:colour could be adapted to use it in public transport routes, or something similar that complements https://wiki.openstreetmap.org/wiki/Key:colour Thanks in advance! Héctor ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Ideas for a simplified public transportation scheme
26 Apr 2019, 17:10 by selfishseaho...@gmail.com: > 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). > As mapper not interested in mapping transit routes I like this solution as it is the simplest for people not interested in mapping of public transit routes but interested in mapping bus/tram stops. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
