Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Richard Mann]

My impression is that this mess arises because bus stops are
uni-directional and independent from the opposite direction. So we're used
to having them as separate entities to the side of the road.

Whereas tram stops are often in a single location for both directions (or
close enough), so we want a single entity on the way, so at low zooms we
can have a single symbol and single name label. Just like railway stations.
These nodes are just labels.

Me: I'd probably use highway=bus_stop for tram stops that are like bus
stops, and add highway=platform for stops that have them, and attach
whichever off-way entity seems most appropriate to the relation and let the
data user figure it out.

Richard
___
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

[Jarek Piórkowski]

As far as I understood it, there are no practical pedestrian routing
concerns with any of the currently used schemes for pedestrian+PT
routing/directions. If this is incorrect can someone provide a
specific example?

On Tue, 7 May 2019 at 16:18, john whelan  wrote:
>
> So if we connect a bus_stop to a highway with a path would that address the 
> routing concerns?  Or is that idea too simple?
>
> Thanks John
>
> On Tue, May 7, 2019, 3:53 PM Jarek Piórkowski,  wrote:
>>
>> Sorry, crossed my wires while editing at one point:
>>
>> > 9a. Because we must retain hw=bus_stop per #3 and #5, any
>> > accommodation of these cases must either be initially of tags, or
>> > guidance on how to place highway=bus_stop tags
>>
>> make that:
>>
>> 9a. Because we must retain hw=bus_stop per #3 and #5, any
>> accommodation of these cases must either be new tags, or guidance on
>> how to place highway=bus_stop tags
>>
>> And just to be clear:
>>
>> > 11b. stop_area is currently mentioned but not recommended in the wiki [2]
>>
>> make that:
>>
>> 11b. stop_area is currently mentioned, but not specified as required,
>> in the wiki [2]
>>
>> ___
>> 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

___
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

[john whelan]

So if we connect a bus_stop to a highway with a path would that address the
routing concerns?  Or is that idea too simple?

Thanks John

On Tue, May 7, 2019, 3:53 PM Jarek Piórkowski,  wrote:

> Sorry, crossed my wires while editing at one point:
>
> > 9a. Because we must retain hw=bus_stop per #3 and #5, any
> > accommodation of these cases must either be initially of tags, or
> > guidance on how to place highway=bus_stop tags
>
> make that:
>
> 9a. Because we must retain hw=bus_stop per #3 and #5, any
> accommodation of these cases must either be new tags, or guidance on
> how to place highway=bus_stop tags
>
> And just to be clear:
>
> > 11b. stop_area is currently mentioned but not recommended in the wiki [2]
>
> make that:
>
> 11b. stop_area is currently mentioned, but not specified as required,
> in the wiki [2]
>
> ___
> 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

[Jarek Piórkowski]

Sorry, crossed my wires while editing at one point:

> 9a. Because we must retain hw=bus_stop per #3 and #5, any
> accommodation of these cases must either be initially of tags, or
> guidance on how to place highway=bus_stop tags

make that:

9a. Because we must retain hw=bus_stop per #3 and #5, any
accommodation of these cases must either be new tags, or guidance on
how to place highway=bus_stop tags

And just to be clear:

> 11b. stop_area is currently mentioned but not recommended in the wiki [2]

make that:

11b. stop_area is currently mentioned, but not specified as required,
in the wiki [2]

___
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

[Jarek Piórkowski]

Hi all,

I wrote some point-form notes of the discussion so far for people to
refer or respond to. I asked questions in 7a, 7c, 8c, 10c, 11c, 13b,
14.

1. Majority of world's public transit is buses
2. Majority of world's bus stops are simple signs (or sometimes no
signs at all) and will never [1] have a designated "platform"
structure
3. Many editors feel that highway=bus_stop is sufficient tagging for these
4. We should also support other transit modes which may more often
have more details
5. Proposals that suggest to change existing widely-used tags such as
highway=bus_stop for semantic reasons are unlikely to succeed
6. I am unaware of any successful proposal which successfully rolled
back a previously accepted proposal. To those disliking PTv2 I suggest
either ignoring it, or adapting it into a PTv3 keeping in mind the
issues it tried to address, some of which are below.

7. For public transit routing, it appears that having highway_bus_stop
nodes ("locations where people wait for buses") arranged in order in a
relation is sufficient, per the comments about OsmAnd in Stockholm
7a. Correct me if I'm wrong but I haven't read a lot of opposition to
this "Stockholm-like" lightweight route/route_master relation scheme
7b. This bus stop node does not have to be placed on the way that
buses travel on
7c. From what I'm understand, this bus stop node does not have to be
connected to a pedestrian highway either, with routers presumably
jumping from the nearest highway?

8. A stop_location (to use ptv2 terminology) on the way that vehicles
travel on could help with things like calculating and showing the
likely route the bus will take, but this can also be calculated
without the stop_location node by projection of other stop objects
onto the way
8a. stop_location is specified as optional in current wiki description
of PTv2 [2]
8b. Stephen initially said "we need stop positions so routers can get
people from stop to stop on the buses/trains"; a subsequent message at
06 May 2019 13:53:10 -0500 (if I understood correctly) said that
stop_position can be optional in cases of simple geometry (which is
presumably vast majority of them)
8c. What changes would people like to make? Clearer guidance as to
when stop_position and stop_area might be needed for buses - in cases
like ambiguous geometry due to multiple parallel highways? Or would
people prefer to ignore routing of buses between stops and advocate
for removal of stop_positions in all cases?

9. There are some cases that do not cleanly fit into hw=bus_stop
"PTv1" tagging, for example a sign-only stop served by both buses and
trams, or a waiting platform served by both buses and trams
9a. Because we must retain hw=bus_stop per #3 and #5, any
accommodation of these cases must either be initially of tags, or
guidance on how to place highway=bus_stop tags

10. Meaning of public_transit=platform tag is dependent on context, it
unifies/duplicates some existing tags, arguably it sometimes describes
imaginary things, and it is disliked by many editors
10a. Some of the dislike is due to disagreements as to what "platform" means
10b. Please remember that OSM's British English naming conventions are
in a foreign language or dialect to vast majority of editors
10c. public_transit=platform does not appear to be needed for walk+PT
routing. It could be replaced with bus_stop, tram_stop,
railway=platform, highway=platform as appropriate. Please correct if
I'm wrong.

11. stop_area is disliked by many editors as being pointless in
majority of cases involving surface transit
11a. stop_area relation was recommended by the OsmAnd blog post
introducing their public transit support, but evidently OsmAnd works
without it in Stockholm
11b. stop_area is currently mentioned but not recommended in the wiki [2]
11c. Would anyone like to see changes here? Should we explicitly
*discourage* stop_area except where needed, and what would be the
criteria for needing it? [3]

12. Many of the currently mapped tram systems have a railway=tram_stop
+ public_transport=stop_position node on the rail, so we should
probably not change this scheme either without good reason

13. There is currently no clear way for tagging stops that also have
physical platforms, except for PTv2
13a. This exists as physical feature in real world and should be
supported, in a manner compatible with platform-less stops
13b. Should we add bus_stop/tram_stop on one of the nodes of the
platform way [4]? Next to the platform? As pointed out by Markus, we
can't do what might be the most intuitive method of the platform
way/area sharing bus_stop tag because the platform is also a highway=
tag.

14. Discussion hasn't really touched much on railways or subways.
Should we take this to mean that people are generally happy with PTv2
tagging on those? If we change the guidance for surface transport,
PTv2 for subways doesn't necessarily have to change.

[1] Or at least not in the timeframe we should concern ourselves with.
As mentioned 

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Mateusz Konieczny]

7 May 2019, 15:09 by emergenc...@outlook.com: 

>  As it stands, the highway=bus_stop tag is a legacy tag for a node. If the 
> platform is a node, it can be put on there (for legacy sake, although the 
> p_t:v2 scheme suggests to sunset that tag)
>
p_t:v2 scheme was bad idea. highway=bus_stop is the optimal mapping method of 
bus stops,
I would consider bus stop not using it as not mapped properly and add it.
___
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

[Dave F via Talk-transit]

That you're discussing so many different iterations of the PT schema 
proves what a cock-up it is.


That you believe all the PT tags are valid proves you've never make the 
schema simpler.

You're even suggesting adding more!

highway=bus_stop is a valid, current well used tag more popular than any 
PT tag. It is here to stay.


>and the single pole on the roadside is being slowly abandoned due to 
security and barrier issues


Security? What doe that even mean? It's a pole with sign on it!

>because any other solution, as long as platforms are mixed nodes and 
ways, would make inconsistencies.


It's the PT tags which are inconsistent & unrepresentative, so require 
rescinding.



On 07/05/2019 14:09, DC Viennablog wrote:

I think someone in this discussion is confusing the idea of a new scheme with 
the current one.

As it stands, the highway=bus_stop tag is a legacy tag for a node. If the 
platform is a node, it can be put on there (for legacy sake, although the 
p_t:v2 scheme suggests to sunset that tag) but if the platform is not just 
conceptual (e.g a pole on the roadside) but has dimensions (and hence is mapped 
as a way/polygon) the tag shall be put on the other thing that is definitely a 
node: The stop_position on the road.

Because more and more platforms in public transport get built as extra 
features, and the single pole on the roadside is being slowly abandoned due to 
security and barrier issues without elevated platforms and so on, I set this, 
planned to be depricated tag, always onto the stop position, because any other 
solution, as long as platforms are mixed nodes and ways, would make 
inconsistencies.

But if we talk about a new scheme, then we could again use one unified tag like 
that, ideally  one that also encapsulates the mode of transport and also says 
“this is the waiting area,point / platform”. Like 
public_transport=bus_stop/tram_stop/train_stop (with railway=stop, statiom or 
halt becoming optional?)
Only problem: what if a bus and a tram stop at the same platform? Just a 
general tag public_transport=stop?

Or would that clutter the tagging to much?

KR
RobinD (emergency99)

Von: Snusmumriken 
Gesendet: Dienstag, 7. Mai 2019 13:19:07
An: Public transport/transit/shared taxi related topics
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme

On Mon, 2019-05-06 at 13:53 -0500, Stephen Sprunk wrote:

On 2019-05-03 12:09, Dave F via Talk-transit wrote:

On 30/04/2019 18:34, Stephen Sprunk wrote:

A platform is where people wait to board; if they stand at a
pole
(typical for buses), then the pole is logically the platform.

This reinforces my point about misappropriation of tags. A platform
is
a physical construction higher than the surrounding ground to allow
easier boarding.

It's a logical platform whether it physically exists or not.  It's
pretty well established that using a platform node for a mere pole
is valid.  People wait there to be picked up, regardless of the
actual surface type (which can change over time anyway).

I think you are mistaken here. The logical entity here is the 'bus
stop', what ever its physical manifestation. English is not my native
language but I don't think one would ever construct a sentence like
"Let's meet at the Main street platform" when you were meaning "Let's
meet at the Main street bus stop".

I don't think a logical platform makes any sense in the context of
public transport.


___
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


___
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

[Dave F via Talk-transit]

On 06/05/2019 19:53, Stephen Sprunk wrote:

On 2019-05-03 12:09, Dave F via Talk-transit wrote:


This reinforces my point about misappropriation of tags. A platform is
a physical construction higher than the surrounding ground to allow
easier boarding.


It's a logical platform whether it physically exists or not.


 A 'logical platform'?

From OSM's main welcome page:
https://www.openstreetmap.org/welcome
"OpenStreetMap is a place for mapping things that are both /real and 
current/"


"What it /doesn't/ include is... hypothetical features,"


  It's pretty well established that using a platform node for a mere 
pole is valid.


But you're mapping them as areas.
As bus stop tags are by far the more established, why not use that to 
map a."mere pole".


From the bus stop wiki page:
"A bus stop is a place where passengers can board or alight from a bus."
Which is what you're claiming platform areas are. As I said it's pure 
duplication.


  People wait there to be picked up, regardless of the actual surface 
type (which can change over time anyway).


Unsure why you believe surface is relevant, but as I said, your examples 
of platforms are imaginary, inaccurate & arbitrary.





A platform:
https://s0.geograph.org.uk/geophotos/04/76/30/4763016_2416f5ee.jpg

Not a platform:
https://i.pinimg.com/originals/38/90/a0/3890a0f451e1a6900d174b29125b3c80.jpg 



If (& I believe it's a big if), a separate tag is required to as you &
Markus suggest, one with a unique, non-confusing value should be used.

Many public_transport=platform are tagged on the same node as
highway=bus_stop. They have no raised construction Therefore they're
redundant - routing can use the bus stop tag for the "stop node beside
the
road" as Markus described it.:
https://www.openstreetmap.org/node/469760546#map=19/51.51026/-0.18630


I'd be fine with saying that highway=bus_stop implies 
public_transport=platform, except that some mappers put bus stops on 
the way instead of beside the way and argue with anyone who tries to 
fix them, so in those areas, separate nodes for the platform had to be 
added.


From the bus stop wiki page:
"The highway=bus_stop tag is widely used on a node off *to one side of 
the highway way* to identify the position where passengers wait for a 
bus beside the carriageway."


However, is it essential that highway=bus_stop is/isn't on a way? 
Routers should be able to adapt to both scenarios.




Ditto for railway=platform implying public_transport=platform


railway=platform implies no such thing. It represents a physical object, 
nothing more, nothing less.


From what I've seen public_transport=platform was conceived as purely a 
duplicating tag to 'collect things together'. I've yet to see a router 
that requires more than a stop position. Don't most just use 
railway=station?


From what I've observed the PT schema went into too much detail which 
will never be used.


, and it doesn't seem to have the same problem.  I'm not sure for 
other modes since I've never dealt with them.


If we could all agree on this, we'd just need to change the 
documentation--and go fix thousands of bus stops that are in the wrong 
place.


Great! That's much simpler than adding tens (hundreds?) of thousands of 
duplicating multi-noded polygons.




That's easily distinguished from large platforms because it's a node 
rather than a way/area.


Not really. To save time, contributors occasionally combine tags onto
a single object: litter_bins, shelters, benches *&* raised platforms
in the case of bus stops. I'm not saying it's the correct/best way to
map, but it happens.


It doesn't make a difference for routing.

If a platform is large enough that it matters for rendering, then 
someone needs to go back and draw the platform as an area.


If it's a physical object, then yes.

  Same as any other structure 


But your examples aren't structures. They're imaginary.




So, to be absolutely sure we're singing from the same hymn sheet, are
we agreed that 'public_transport=platform' tag to represent a place
where vehicles stop to allow passengers to alight, is redundant in PT
as another, existing, more prevalent tag - 'highway=bus_stop' can be
used instead?


Notice what you did there: the platform tag "represent[s] a place 
where vehicles stop".  That's the entire argument over bus stops in a 
nutshell, which led to the redundant tagging.




I refer you back to the bus stop wiki page.
___
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

[DC Viennablog]

I think someone in this discussion is confusing the idea of a new scheme with 
the current one.

As it stands, the highway=bus_stop tag is a legacy tag for a node. If the 
platform is a node, it can be put on there (for legacy sake, although the 
p_t:v2 scheme suggests to sunset that tag) but if the platform is not just 
conceptual (e.g a pole on the roadside) but has dimensions (and hence is mapped 
as a way/polygon) the tag shall be put on the other thing that is definitely a 
node: The stop_position on the road.

Because more and more platforms in public transport get built as extra 
features, and the single pole on the roadside is being slowly abandoned due to 
security and barrier issues without elevated platforms and so on, I set this, 
planned to be depricated tag, always onto the stop position, because any other 
solution, as long as platforms are mixed nodes and ways, would make 
inconsistencies.

But if we talk about a new scheme, then we could again use one unified tag like 
that, ideally  one that also encapsulates the mode of transport and also says 
“this is the waiting area,point / platform”. Like 
public_transport=bus_stop/tram_stop/train_stop (with railway=stop, statiom or 
halt becoming optional?)
Only problem: what if a bus and a tram stop at the same platform? Just a 
general tag public_transport=stop?

Or would that clutter the tagging to much?

KR
RobinD (emergency99)

Von: Snusmumriken 
Gesendet: Dienstag, 7. Mai 2019 13:19:07
An: Public transport/transit/shared taxi related topics
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme

On Mon, 2019-05-06 at 13:53 -0500, Stephen Sprunk wrote:
> On 2019-05-03 12:09, Dave F via Talk-transit wrote:
> > On 30/04/2019 18:34, Stephen Sprunk wrote:
> > > A platform is where people wait to board; if they stand at a
> > > pole
> > > (typical for buses), then the pole is logically the platform.
> >
> > This reinforces my point about misappropriation of tags. A platform
> > is
> > a physical construction higher than the surrounding ground to allow
> > easier boarding.
>
> It's a logical platform whether it physically exists or not.  It's
> pretty well established that using a platform node for a mere pole
> is valid.  People wait there to be picked up, regardless of the
> actual surface type (which can change over time anyway).

I think you are mistaken here. The logical entity here is the 'bus
stop', what ever its physical manifestation. English is not my native
language but I don't think one would ever construct a sentence like
"Let's meet at the Main street platform" when you were meaning "Let's
meet at the Main street bus stop".

I don't think a logical platform makes any sense in the context of
public transport.


___
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

[Snusmumriken]

On Mon, 2019-05-06 at 13:53 -0500, Stephen Sprunk wrote:
> On 2019-05-03 12:09, Dave F via Talk-transit wrote:
> > On 30/04/2019 18:34, Stephen Sprunk wrote:
> > > A platform is where people wait to board; if they stand at a
> > > pole 
> > > (typical for buses), then the pole is logically the platform.
> > 
> > This reinforces my point about misappropriation of tags. A platform
> > is
> > a physical construction higher than the surrounding ground to allow
> > easier boarding.
> 
> It's a logical platform whether it physically exists or not.  It's 
> pretty well established that using a platform node for a mere pole
> is valid.  People wait there to be picked up, regardless of the
> actual surface type (which can change over time anyway).

I think you are mistaken here. The logical entity here is the 'bus
stop', what ever its physical manifestation. English is not my native
language but I don't think one would ever construct a sentence like
"Let's meet at the Main street platform" when you were meaning "Let's
meet at the Main street bus stop". 

I don't think a logical platform makes any sense in the context of
public transport.


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Line colour, text colour and background colour

[Héctor Ochoa]

Ok, thanks to everyone for your response.
Kindly, Héctor.

El lun., 6 may. 2019 a las 22:15, Tijmen Stam ()
escribió:

> On 29-04-19 16:58, Stephen Sprunk wrote:
> > The route and route_master relations have a documented "colour" key that
> > can be used.  However, that seems to be intended for the line itself,
> > and I'm not aware of any renderer that uses it.  If they did, they'd
> > probably use it for the label background too.
> >
> > Relation:destination_sign has attributes colour:back and colour:text, so
> > it makes sense to reuse those here, but if renderers aren't even using
> > colour for the line/label today, I wouldn't count on them doing anything
> > special with the text either.
>
> OSMand (openstreetmap for Android) does render colour for subway lines,
> and it renders de coulours in line labels for bus lines.
>
> For e.g. https://www.openstreetmap.org/relation/297293I have used
> colour=#ff (both in the route and route_master) and it renders good
> on OSMand.
>
> Keeping in line with other tagging schemes I would use "Colour" for the
> colour of the line (on maps etc), ref:colour for the colour of the text,
> and if necessary: ref:colour_tx for reference text colour and
> ref_colour_bg for reference background colour as per
> 
>
> (In your example I can see e.g. the 22/34/40 being Lime/Blue/Bordeaux as
> "colour", having white as colour:ref, but N1, N2, N7 would have green,
> pink, yellow as colour, having those as colour:ref as well, but black as
> colour_bg.
>
> I have no idea what the line colour of the TR line will be though.
> Black? White? :-)
>
>
>
> ___
> 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