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

[Jo]

Nodes can change, the tags can change, the position can change.

They are easy to work with, both for the mappers, the users and the
software.

Going from a node to a (closed)way and then having to update all the route
relations, that is cumbersome.

Having to maintain the same data across multiple objects, that is
cumbersome.

The node 'represents' the stop, both on the map and in the itineraries, its
coordinates are the stop's general whereabouts. It could be the exact
location of the pole, but if there are 2 operators that serve the stop and
each has a pole, it would still be a single node (Unless that other pole is
1,5 bus length away in a bus station situation and they have different
platform numbers or letters).

Polyglot

On Tue, May 14, 2019 at 3:50 PM DC Viennablog 
wrote:

> @Polyglot:
> I do think you are thinking to much of software that uses the date rather
> than of the mappers and the database. For both of those, it is better to
> habe less objects to contend with (mapper) and less objects with
> potentially redundant values/positions (database). The fact that maybe a
> router or the api has to calculate a possible middle of a platform polygon
> should, in that context, be the least of our worries.
>
> And the thing with a stop being a node for it‘s lifetime, that does then
> not truly stand with it being a real thing. Because real things tend to
> change over time...
>
> And if it doesn‘t and is just a pole in the field, than it would stay a
> „platform“-node for it‘s lifetime. Objective achieved.
>
> KR
> RobinD (emergency99)
> --
> *Von:* Jo 
> *Gesendet:* Dienstag, 14. Mai 2019 14:37:39
> *An:* Public transport/transit/shared taxi related topics
> *Betreff:* Re: [Talk-transit] Ideas for a simplified public
> transportation scheme
>
> For maintenance and for the stability of the data it is, however, better
> to keep the object that represents the stop, the same during its lifetime,
> instead of migrating it from node to way objects.
>
> We are perfectly well capable of having a node to represent the stop with
> highway=bus_stop and another object to represent the platform with
> highway=platform or railway=platform or both.
>
> For working with the data, it's enough to have the highway=bus_stop/
> railway=tram_stop in the route relations and given that they are nodes,
> their geometry doesn't need to be calculated over and over.
>
> The thread is about simplifying the scheme. That is about as simple as it
> can get.
>
> Polyglot
>
> On Tue, May 14, 2019 at 1:29 PM Markus  wrote:
>
> On Tue, 14 May 2019 at 12:31, Dave F via Talk-transit
>  wrote:
> >
> > 1) highway=bus_stop is a physical object. In OSM we map physical
> > objects. To clarify - What do you mean by 'logical'?
>
> While stops (and stations, too) can be observed (PT vehicles stop
> there), they aren't physical objects. Physical objects are platforms,
> poles, shelters or road markings. They can usually be found at a stop
> or station, but don't have to.
>
> > 2) Why to they need to be "mapped on the same area"? They are separate
> > entities. Objects close to each other can be easily found as OSM is
> > geospatially aware.
>
> They don't need to be mapped on the same area, but it were easier
> (just one object). And if there is a real platform, it is the waiting
> area of the stop.
>
> Regards
>
> Markus
>
> ___
> 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

[DC Viennablog]

@Polyglot:
I do think you are thinking to much of software that uses the date rather than 
of the mappers and the database. For both of those, it is better to habe less 
objects to contend with (mapper) and less objects with potentially redundant 
values/positions (database). The fact that maybe a router or the api has to 
calculate a possible middle of a platform polygon should, in that context, be 
the least of our worries.

And the thing with a stop being a node for it‘s lifetime, that does then not 
truly stand with it being a real thing. Because real things tend to change over 
time...

And if it doesn‘t and is just a pole in the field, than it would stay a 
„platform“-node for it‘s lifetime. Objective achieved.

KR
RobinD (emergency99)

Von: Jo 
Gesendet: Dienstag, 14. Mai 2019 14:37:39
An: Public transport/transit/shared taxi related topics
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme

For maintenance and for the stability of the data it is, however, better to 
keep the object that represents the stop, the same during its lifetime, instead 
of migrating it from node to way objects.

We are perfectly well capable of having a node to represent the stop with 
highway=bus_stop and another object to represent the platform with 
highway=platform or railway=platform or both.

For working with the data, it's enough to have the highway=bus_stop/ 
railway=tram_stop in the route relations and given that they are nodes, their 
geometry doesn't need to be calculated over and over.

The thread is about simplifying the scheme. That is about as simple as it can 
get.

Polyglot

On Tue, May 14, 2019 at 1:29 PM Markus 
mailto:selfishseaho...@gmail.com>> wrote:
On Tue, 14 May 2019 at 12:31, Dave F via Talk-transit
mailto:talk-transit@openstreetmap.org>> wrote:
>
> 1) highway=bus_stop is a physical object. In OSM we map physical
> objects. To clarify - What do you mean by 'logical'?

While stops (and stations, too) can be observed (PT vehicles stop
there), they aren't physical objects. Physical objects are platforms,
poles, shelters or road markings. They can usually be found at a stop
or station, but don't have to.

> 2) Why to they need to be "mapped on the same area"? They are separate
> entities. Objects close to each other can be easily found as OSM is
> geospatially aware.

They don't need to be mapped on the same area, but it were easier
(just one object). And if there is a real platform, it is the waiting
area of the stop.

Regards

Markus

___
Talk-transit mailing list
Talk-transit@openstreetmap.org<mailto: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

[Jo]

For maintenance and for the stability of the data it is, however, better to
keep the object that represents the stop, the same during its lifetime,
instead of migrating it from node to way objects.

We are perfectly well capable of having a node to represent the stop with
highway=bus_stop and another object to represent the platform with
highway=platform or railway=platform or both.

For working with the data, it's enough to have the highway=bus_stop/
railway=tram_stop in the route relations and given that they are nodes,
their geometry doesn't need to be calculated over and over.

The thread is about simplifying the scheme. That is about as simple as it
can get.

Polyglot

On Tue, May 14, 2019 at 1:29 PM Markus  wrote:

> On Tue, 14 May 2019 at 12:31, Dave F via Talk-transit
>  wrote:
> >
> > 1) highway=bus_stop is a physical object. In OSM we map physical
> > objects. To clarify - What do you mean by 'logical'?
>
> While stops (and stations, too) can be observed (PT vehicles stop
> there), they aren't physical objects. Physical objects are platforms,
> poles, shelters or road markings. They can usually be found at a stop
> or station, but don't have to.
>
> > 2) Why to they need to be "mapped on the same area"? They are separate
> > entities. Objects close to each other can be easily found as OSM is
> > geospatially aware.
>
> They don't need to be mapped on the same area, but it were easier
> (just one object). And if there is a real platform, it is the waiting
> area of the stop.
>
> Regards
>
> Markus
>
> ___
> 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

[Markus]

On Tue, 14 May 2019 at 12:31, Dave F via Talk-transit
 wrote:
>
> 1) highway=bus_stop is a physical object. In OSM we map physical
> objects. To clarify - What do you mean by 'logical'?

While stops (and stations, too) can be observed (PT vehicles stop
there), they aren't physical objects. Physical objects are platforms,
poles, shelters or road markings. They can usually be found at a stop
or station, but don't have to.

> 2) Why to they need to be "mapped on the same area"? They are separate
> entities. Objects close to each other can be easily found as OSM is
> geospatially aware.

They don't need to be mapped on the same area, but it were easier
(just one object). And if there is a real platform, it is the waiting
area of the stop.

Regards

Markus

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

The target of OSM is to map physical objects, however, a node that is 
„highway=bus_stop“ is not really a physical object. You could say it is the 
station pole, but what if there is no station pole, as the schedule is mounted 
on the wall of a house or inside a shelter, or just doesn‘t exist to begin 
with? Then this node is purely imaginary!

This is why I think only mapping a „platform“ (or rename it stop, 
waiting_point, whatever will you) is and should be the sole requirement. Any 
„stop“ node with all info would not be real! Some people would try to find some 
peace of mind by telling themselves „it is the pole/schedule cabinet“, but that 
is only lying to oneself.

Like this, it is even more made up than p_t=stop_position...

KR
RobinD. (emergency99)

Von: Dave F via Talk-transit 
Gesendet: Dienstag, 14. Mai 2019 12:29:44
An: talk-transit@openstreetmap.org
Cc: Dave F
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme


> ...the logical object highway=bus_stop/railway=tram_stop cannot be
> mapped on the same area as the physical object
> highway=platform/railway=platform (as they use the same key).
1) highway=bus_stop is a physical object. In OSM we map physical
objects. To clarify - What do you mean by 'logical'?

2) Why to they need to be "mapped on the same area"? They are separate
entities. Objects close to each other can be easily found as OSM is
geospatially aware.

DaveF

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

...the logical object highway=bus_stop/railway=tram_stop cannot be
mapped on the same area as the physical object
highway=platform/railway=platform (as they use the same key).
1) highway=bus_stop is a physical object. In OSM we map physical 
objects. To clarify - What do you mean by 'logical'?


2) Why to they need to be "mapped on the same area"? They are separate 
entities. Objects close to each other can be easily found as OSM is 
geospatially aware.


DaveF

___
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 13/05/2019 19:01, Jarek Piórkowski wrote:

On Mon, 13 May 2019 at 11:49, Dave F via Talk-transit
 wrote:

If Philip really wants a router to tell him where the nearest
shelter (surely you can just look around you),

You're joking?!
No, I'm not. Another reason PT has got itself into such a mess is the 
mission-creep that's occurred since its inception: The desperation to 
collect ever increasingly extraneous items into the schema, such as 
Phillips.


There needs to be a 'back to basics' cull of tags & relation collections 
of tags. Ask what's required to transport a person from A (via C) to B.



exact locations of shelters,in particular of bus stop shelters, could be very 
useful for those with visual disability (e.g. severe shortsightedness).


And if they're mapped they can be found, but there's no reason to bind 
them into a PT relation.


DaveF

___
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

[Markus]

On Mon, 13 May 2019 at 17:39, Johnparis  wrote:
>
> I agree that platforms should be mapped as ways only if they physically 
> exist. What I'm saying is that I don't object if someone does map such an 
> object, but the information from the transit agency should always be 
> contained in a node, not a way, as Jo mentioned.

Why? I don't see a necessity for this. By the way, copying tags from
areas to nodes and can be done very quickly with JOSM.

Regards

Markus

___
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

[Markus]

On Sun, 12 May 2019 at 20:55, Tijmen Stam  wrote:
>
> a "public_transport=platform" is not defined as being "platform" (raised
> good concrete flooring) but as "the place where people wait to board a
> bus/tram/train". Whatever form that is.

That's a contradiction of the PTv2 scheme: it says that
public_transport=platform is the waiting area, but also says that
highway=platform/railway=platform (which mean a physical object) is
equivalent to public_transport=platform.

How to tag the physical object (raised structure) in PTv2 then? And
how to tag extra platforms that are usually not operated, but only in
case of special events or diversions?

This is why i think we need two tags: one for the virtual object
"waiting area of a stop" and one for the physical object "platform"
(raised structure). In PTv1 we already have that, the only drawback is
that the logical object highway=bus_stop/railway=tram_stop cannot be
mapped on the same area as the physical object
highway=platform/railway=platform (as they use the same key).
Therefore my idea with a new public_transport=stop tag that can be
combined with highway=platform/railway=platform.

> > railway=platform implies no such thing. It represents a physical object,
> > nothing more, nothing less.
>
> What physical object?
> What if there is a railway station that has no raised platform but where
> one just alights into the trackbed? What physical object is there?
> e.g. https://en.wikipedia.org/wiki/Padag_Road_railway_station
> The sand there is the "place where people wait to board", which could be
> mapped as railway=platform or public_transport is platform, but not in
> YOUR view, as there is no physical "platform", no raised object.

It should definitely not be mapped as railway=platform, as this tag
means a real platform, that is, a raised structure. Besides, it's not
possible to draw a verifiable waiting area in case there is no raised
or in any other way bordered area.

Regards

Markus

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

On Mon, 13 May 2019 at 11:49, Dave F via Talk-transit
 wrote:
> If Philip really wants a router to tell him where the nearest
> shelter (surely you can just look around you),

You're joking?!

The entire OpenStreetMap could be waved away with the phrase "surely
you can just look around you". Why tag speed limits, just look as
you're driving. Why map shorelines, just walk around til your feet get
wet. Why map bus stops, just look around you.

To give just one obvious counter-example: exact locations of shelters,
in particular of bus stop shelters, could be very useful for those
with visual disability (e.g. severe shortsightedness).

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

[Dave F via Talk-transit]

If separate signs.poles - double nodes
if single sign/poles - two tags on one node

DaveF


On 13/05/2019 16:02, Johnparis wrote:

If a platform is multimodal, highway=bus_stop fails, because the same node
requires (for example) railway=tram_stop



___
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 13/05/2019 16:36, Johnparis wrote:

the bus stop (platform) node allows for shelter=yes/no and bench=yes/no, so
it's not really necessary to separately map them and/or group them into the
stop area.


If you've the time, map them separately  - it makes the database more 
accurate, but I still fail to see why these items need to be collected 
together. If Philip really wants a router to tell him where the nearest 
shelter (surely you can just look around you), it is possible without 
relations as OSM has *always* been geospatially aware.


DaveF

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

Why does all the info need to be in one node and not on a way? Also, if there 
is a platform, it should be a polygon, not just a line. That should not be to 
micro to be mapped in true dimensions. If that object is the true only thing 
that defines the stop, it should be able to have the tags in every form (except 
multi-polygon relations)

The additional nodes make the confusing clutter!

KR
RobinD (emergency99)

Von: Johnparis 
Gesendet: Montag, 13. Mai 2019 17:38:36
An: Public transport/transit/shared taxi related topics
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme

I agree that platforms should be mapped as ways only if they physically exist. 
What I'm saying is that I don't object if someone does map such an object, but 
the information from the transit agency should always be contained in a node, 
not a way, as Jo mentioned.

I usually place the node inside the closed way if it exists, but another 
possibility (and necessary if it's an unclosed way) is to make the node a part 
of the way.



On Mon, May 13, 2019 at 5:36 PM Dave F via Talk-transit 
mailto:talk-transit@openstreetmap.org>> wrote:
On 13/05/2019 16:14, Johnparis wrote:
> I don't have any particular problem with mapping an area (closed way) or a
> way (line segment) as a platform,

Please, please only map a platform /if/ it's a physical structure.
Imaginary meta-objects  don't work in OSM

DaveF

___
Talk-transit mailing list
Talk-transit@openstreetmap.org<mailto: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]

I think this highlights another PT schema problem - expecting too much 
from a routing engine.


On 13/05/2019 16:29, Philip Barnes wrote:


I do, but there tend to be lots of bus stops and sometimes I want it to choose 
the one with the shelter if its only a short extra walk.

Phil (trigpoint)




___
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

[Johnparis]

I agree that platforms should be mapped as ways only if they physically
exist. What I'm saying is that I don't object if someone does map such an
object, but the information from the transit agency should always be
contained in a node, not a way, as Jo mentioned.

I usually place the node inside the closed way if it exists, but another
possibility (and necessary if it's an unclosed way) is to make the node a
part of the way.



On Mon, May 13, 2019 at 5:36 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> On 13/05/2019 16:14, Johnparis wrote:
> > I don't have any particular problem with mapping an area (closed way) or
> a
> > way (line segment) as a platform,
>
> Please, please only map a platform /if/ it's a physical structure.
> Imaginary meta-objects  don't work in OSM
>
> DaveF
>
> ___
> 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

[DC Viennablog]

When the platform is a really existing built thing, you would need 
highway=platform on it, and an additional highway=bus_stop at the stop pole or 
wherever. That is more clutter and worse state of the database, than if we 
would finally move to the more versatile public_transport=platform. As it is 
the only thing that the p_t:v2 scheme actually needs anyway, we could save so 
much node clutter if we would use only that.

The stop (bus, tram, whatever) is only a pin in a field? Ok, let‘s have a 
node(p_t=platform;name=*) and put only that in the route relations.

The stop has a piece of sidewalk that is built forward slightly or a true 
platform: Have a polygon with the same tags.

As usually, any mode of transport is longer and and have multiple doors, you 
can still have the polygon as saying „anywhere here, the passengers can wait“.

Why is it so bad to adapt to a scheme that got voted in favour of long ago?

Ok, some additional confusing clutter exists in this scheme, but if I 
understand the explanations here, most, if not all of that is not required.

If the render would finally render public_transport=platform nodes exactly like 
highway=bus_stop / any tram/train stop equivalent, and 
public_transport=platform polygons exactly like highway=platform, and we would 
use only that, the state of the database would be far better than the simply 
not versatile enough bus stop node.

Maybe we could at some point get to just usefully rewrite the v2 scheme 
definition to make it easier to understand. Most dislike against it seems to 
come from not understanding it correctly, as it is described to complex in some 
cases.

If we were to say, that only p_t=platform is to be used in most cases, on nodes 
or ways beside the road, and nothing else is actually required, it be more 
accessible than hw=bus_stop=platform, the relations would be almost the same 
as now, and the only thing that needs to be slightly corrected be the renders 
to finally also accept this.

Except for being older, what makes hw=bus_stop better?
You still might have to then use hw=platform and maybe p_t=platform 
additionally, it needs to be an extra node, it does not necessarily mean what 
it says (bus stop is conceptually a combination of platform and stop 
position[s]) and it is a stiff node, that only works for buses then.

What will it take for the haters to accept this (potentially) simpler, newer 
scheme?

KR
RobinD (emergency99)

Von: Dave F via Talk-transit 
Gesendet: Montag, 13. Mai 2019 17:10:21
An: talk-transit@openstreetmap.org
Cc: Dave F
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme

On 13/05/2019 07:36, Tijmen Stam wrote:
> On 13-05-19 00:14, Jo wrote:
>> I like to keep things simple, the best way to accomplish that, is by
>> having a single object for each stop that holds all the details for
>> its "lifetime". That's why I don't like the idea of 'upgrading from a
>> node to a way/area or a relation.
>
> I don't agree with you on that point. With that view we can't change
> things in OSM anymore to a more precise mapping.

A bus stop as a node to represent the sign/pole is /far/ more accurate
than an arbitrary invisible mutli-noded polygon.

DaveF

___
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

[Johnparis]

the bus stop (platform) node allows for shelter=yes/no and bench=yes/no, so
it's not really necessary to separately map them and/or group them into the
stop area.


On Mon, May 13, 2019 at 5:30 PM Philip Barnes  wrote:

> On Monday, 13 May 2019, Dave F via Talk-transit wrote:
> >
> >
> > On 13/05/2019 16:14, Philip Barnes wrote:
> > >
> > > I can see that when its raining I may want the router to direct me to
> a stop with a shelter rather than stand in the rain.
> > Surely you need to be given the bus stop which will take you to your
> > destination? That /is/ the point of a router.
> >
> I do, but there tend to be lots of bus stops and sometimes I want it to
> choose the one with the shelter if its only a short extra walk.
>
> Phil (trigpoint)
>
> --
> Sent from my Sailfish device
> ___
> 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 13/05/2019 16:14, Johnparis wrote:

I don't have any particular problem with mapping an area (closed way) or a
way (line segment) as a platform,


Please, please only map a platform /if/ it's a physical structure. 
Imaginary meta-objects  don't work in OSM


DaveF

___
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

[Philip Barnes]

On Monday, 13 May 2019, Dave F via Talk-transit wrote:
> 
> 
> On 13/05/2019 16:14, Philip Barnes wrote:
> >
> > I can see that when its raining I may want the router to direct me to a 
> > stop with a shelter rather than stand in the rain.
> Surely you need to be given the bus stop which will take you to your 
> destination? That /is/ the point of a router.
> 
I do, but there tend to be lots of bus stops and sometimes I want it to choose 
the one with the shelter if its only a short extra walk.

Phil (trigpoint)

-- 
Sent from my Sailfish device
___
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 13/05/2019 16:14, Philip Barnes wrote:


I can see that when its raining I may want the router to direct me to a stop 
with a shelter rather than stand in the rain.
Surely you need to be given the bus stop which will take you to your 
destination? That /is/ the point of a router.


DaveF

___
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

[Philip Barnes]

On Monday, 13 May 2019, Dave F via Talk-transit wrote:
> 
> 
> On 12/05/2019 23:14, Jo wrote:
> > About the stop_area relations, they're not needed everywhere, but they
> > could be used to show what belongs together. Of course, that would mean all
> > the objects related to the stop at one side of the street, not both sides.
> 
> Why items "belong together"?
> Does a router need to know there's a shelter, benches, litter bind etc?
> 
I can see that when its raining I may want the router to direct me to a stop 
with a shelter rather than stand in the rain. Shelters tend to have lean on 
seating.

Otherwise benches and bins may be nearby but they are not exclusively 
associated with buses. A bin is not provided by a bus company and is not fir 
the exclusive use of bus passengers.

Phil (trigpoint)

-- 
Sent from my Sailfish device
___
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

[Johnparis]

I don't have any particular problem with mapping an area (closed way) or a
way (line segment) as a platform, but I agree with Jo that the information
should be contained in a node. That node can be part of the way. From
experience, it complicates things quite a bit when you transfer the
information from the node to the way.


On Mon, May 13, 2019 at 5:10 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> On 13/05/2019 07:36, Tijmen Stam wrote:
> > On 13-05-19 00:14, Jo wrote:
> >> I like to keep things simple, the best way to accomplish that, is by
> >> having a single object for each stop that holds all the details for
> >> its "lifetime". That's why I don't like the idea of 'upgrading from a
> >> node to a way/area or a relation.
> >
> > I don't agree with you on that point. With that view we can't change
> > things in OSM anymore to a more precise mapping.
>
> A bus stop as a node to represent the sign/pole is /far/ more accurate
> than an arbitrary invisible mutli-noded polygon.
>
> DaveF
>
> ___
> 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

[Johnparis]

Definitely not non-transit items.

GTFS defines the equivalent of a stop area. The Paris regional transit
agency largely reflects these as transfer points between lines of different
bus companies. It can also be useful to link a stop position to a platform,
which can be very useful when it's not clear which street the platform is
facing.

A stop area in Paris, for example, might be Gare Saint-Lazare, which would
group (a) the many bus stops (platforms) named "Gare Saint-Lazare" in the
neighborhood, (b) possibly any associated stop positions for those bus
platforms, (c) the metro lines with Gare Saint-Lazare stations, the
platforms of which differ, (d) the regional train lines that terminate at
Gare Saint-Lazare, (e) any intercity trains that go there.

In general I don't use them.

On Mon, May 13, 2019 at 5:03 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

>
>
> On 12/05/2019 23:14, Jo wrote:
> > About the stop_area relations, they're not needed everywhere, but they
> > could be used to show what belongs together. Of course, that would mean
> all
> > the objects related to the stop at one side of the street, not both
> sides.
>
> Why items "belong together"?
> Does a router need to know there's a shelter, benches, litter bind etc?
>
>
> DaveF
>
> ___
> 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 13/05/2019 07:36, Tijmen Stam wrote:

On 13-05-19 00:14, Jo wrote:
I like to keep things simple, the best way to accomplish that, is by 
having a single object for each stop that holds all the details for 
its "lifetime". That's why I don't like the idea of 'upgrading from a 
node to a way/area or a relation.


I don't agree with you on that point. With that view we can't change 
things in OSM anymore to a more precise mapping.


A bus stop as a node to represent the sign/pole is /far/ more accurate 
than an arbitrary invisible mutli-noded polygon.


DaveF

___
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 12/05/2019 23:14, Jo wrote:

About the stop_area relations, they're not needed everywhere, but they
could be used to show what belongs together. Of course, that would mean all
the objects related to the stop at one side of the street, not both sides.


Why items "belong together"?
Does a router need to know there's a shelter, benches, litter bind etc?


DaveF

___
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

[Johnparis]

If a platform is multimodal, highway=bus_stop fails, because the same node
requires (for example) railway=tram_stop



On Mon, May 13, 2019 at 4:56 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> On 12/05/2019 19:55, Tijmen Stam wrote:
> .
> >
> > No, changing of tagging, not replication.
> > There is no need to map with highway=bus_stop anymore (save for
> > rendering on osm_carto)
>
> No. highway=bus_stop is fully relevant as the day it was first used.
> It's simple, clear, comprehensible meaning far out ways the supposedly
> "overwhelming" PT tagging which few mappers have adopted. This thread
> wouldn't have happened it is was popular. It appears dead in the water.
>
> Show me how p_t=platform adds anything to the quality of the OSM
> database over highway=bus_stop.
>
> DaveF
>
> ___
> 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 12/05/2019 19:55, Tijmen Stam wrote:
.


No, changing of tagging, not replication.
There is no need to map with highway=bus_stop anymore (save for 
rendering on osm_carto)


No. highway=bus_stop is fully relevant as the day it was first used. 
It's simple, clear, comprehensible meaning far out ways the supposedly 
"overwhelming" PT tagging which few mappers have adopted. This thread 
wouldn't have happened it is was popular. It appears dead in the water.


Show me how p_t=platform adds anything to the quality of the OSM 
database over highway=bus_stop.


DaveF

___
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-13 at 08:47 -0400, Jarek Piórkowski wrote:
> On Mon, 13 May 2019 at 03:50, Snusmumriken
>  wrote:
> > On Sun, 2019-05-12 at 20:55 +0200, Tijmen Stam wrote:
> > > It is not uncommon for key/values to be misnomers in OSM.
> > > Clearest
> > > example is private-access ways being tagged as highway=* (plus
> > > access=no) which is a misnomer in British English (which we use)
> > 
> > Misnomers should clearly be avoided if at all possible. And here it
> > is
> > quite possible, by calling a bus stop a bus stop.
> 
> Calling a bus stop a bus stop is fine, but if we want to avoid
> misnomers, why is it under the "highway" category, along with
> expressways and speed bumps and toll gantries, and not a "public
> transport" category?

Good point. If we would start from scratch them perhaps
public_transport=bus_stop would be the logical tag. But in OSM we
usually don't do renaming of established tags. And at least the value
part is correct in the key-value pair, at that is the one most
important to get right. And the highway-key isn't really that much off.


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

On Mon, 13 May 2019 at 03:50, Snusmumriken
 wrote:
> On Sun, 2019-05-12 at 20:55 +0200, Tijmen Stam wrote:
> > It is not uncommon for key/values to be misnomers in OSM. Clearest
> > example is private-access ways being tagged as highway=* (plus
> > access=no) which is a misnomer in British English (which we use)
>
> Misnomers should clearly be avoided if at all possible. And here it is
> quite possible, by calling a bus stop a bus stop.

Calling a bus stop a bus stop is fine, but if we want to avoid
misnomers, why is it under the "highway" category, along with
expressways and speed bumps and toll gantries, and not a "public
transport" category?

___
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

[Jo]

Indeed, that's were we don't seem to be able to agree.

Let's say all bus stops are mapped on nodes to get started.

Then a mapper notices there is a platform near to some of them. Those
platforms can simply be drawn, in addition, to the nodes that represent
such stops. No need to transfer from a node to a way and update all the
route relations where that stop is used.

If I'm not mistaken, in the Netherlands, all house numbers are mapped on
nodes, which are contained within building outlines. I don't really like
that a spatial query is needed to connect buildings to addresses, but as
far as 'tranquility' in the data goes, it's a nice solution.

Back to PT. What most data consumers need is to know where can I
board/alight from the vehicles. A set of coordinates near to where the bus
passes + an indication on which side of the street the doors will open.

For drawing maps we need that + an overview of the itineraries, i.e. the
ways the bus passes on.

For routing we basically only need the stops in the right order +
timetables that come from elsewhere. But it's nice to have the coordinates
of the stops directly available.

Polyglot

Polyglot



On Mon, May 13, 2019 at 8:36 AM Tijmen Stam  wrote:

> On 13-05-19 00:14, Jo wrote:
> > I like to keep things simple, the best way to accomplish that, is by
> > having a single object for each stop that holds all the details for its
> > "lifetime". That's why I don't like the idea of 'upgrading from a node
> > to a way/area or a relation.
>
> I don't agree with you on that point. With that view we can't change
> things in OSM anymore to a more precise mapping.
>
> IMHO it shouldn't be the internal OSM database ID that makes something a
> "logical object", but the ref on that object.
> Say you're transitioning from a node to a way for a bus stop, simply
> copy the relevant tags from that node to the way.
>
>
___
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 Sun, 2019-05-12 at 20:55 +0200, Tijmen Stam wrote:
> a "public_transport=platform" is not defined as being "platform"
> (raised good concrete flooring) but as "the place where people wait
> to board a bus/tram/train". Whatever form that is.
> 
> It is not uncommon for key/values to be misnomers in OSM. Clearest 
> example is private-access ways being tagged as highway=* (plus 
> access=no) which is a misnomer in British English (which we use)

Misnomers should clearly be avoided if at all possible. And here it is
quite possible, by calling a bus stop a bus stop.




___
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

[Tijmen Stam]

On 13-05-19 00:14, Jo wrote:
I like to keep things simple, the best way to accomplish that, is by 
having a single object for each stop that holds all the details for its 
"lifetime". That's why I don't like the idea of 'upgrading from a node 
to a way/area or a relation.


I don't agree with you on that point. With that view we can't change 
things in OSM anymore to a more precise mapping.


IMHO it shouldn't be the internal OSM database ID that makes something a 
"logical object", but the ref on that object.
Say you're transitioning from a node to a way for a bus stop, simply 
copy the relevant tags from that node to the way.



___
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

[Jo]

I like to keep things simple, the best way to accomplish that, is by having
a single object for each stop that holds all the details for its
"lifetime". That's why I don't like the idea of 'upgrading from a node to a
way/area or a relation.

So a node next to the highway per stop.

I started adding public_transport=platform/bus=yes to these nodes, but to
be honest, I am not sure why. anymore What matters to get them rendered is
to add highway=bus_stop to them. And that's not going to change anytime
soon.

Think of these nodes as logical objects that represent the stops. The nice
thing about them is that they have coordinates directly, no need to
recalculate center points over and over and over and over again.

Of course, if there are physical platforms, it's easy to map them as
separate objects, tagged with highway=platform or railway=platform on a way
or an area. No need to repeat all the details on them though.

About the stop_area relations, they're not needed everywhere, but they
could be used to show what belongs together. Of course, that would mean all
the objects related to the stop at one side of the street, not both sides.

public_transport=stop_position, I only use them at the beginning and the
end of the itineraries. We could also simply split the way on a node that
doesn't have tags.

Polyglot





On Sun, May 12, 2019 at 8:55 PM Tijmen Stam  wrote:

> On 07-05-19 15:29, Dave F via Talk-transit wrote:
> > 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,"
>
> a "public_transport=platform" is not defined as being "platform" (raised
> good concrete flooring) but as "the place where people wait to board a
> bus/tram/train". Whatever form that is.
>
> It is not uncommon for key/values to be misnomers in OSM. Clearest
> example is private-access ways being tagged as highway=* (plus
> access=no) which is a misnomer in British English (which we use), as
> highways are public-access roads by legal definition. (see
> https://en.wikipedia.org/wiki/Highway#Terminology)
>
> >>   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".
>
> This is circular reasoning. We can't use the new thing because the old
> thing is much more usual.
> Besides, the new thing (public_transport=platform in PTv2) has been
> voted on in 2011, with overwhelming majority (83 to 6)
>
> >  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.
>
> No, changing of tagging, not replication.
> There is no need to map with highway=bus_stop anymore (save for
> rendering on osm_carto)
>
> >>   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.
>
> He says the surface is irrelevant (regardless).
> I find it a losing argument by saying Stephen's examples are "imaginary,
> inaccurate and arbritary"?, even when he hardly gives an example in the
> post you quote.
>
> >>> 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
>
> That is a "place where people wait to board" (or in this instance, where
> people just alighted)
>
> >>> 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
>
> The reason double tagging exists, is that public_transport=platform
> isn't rendered yet.
>
> >> 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 

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

[Tijmen Stam]

On 09-05-19 23:03, Markus wrote:

On Tue, 7 May 2019 at 21:15, Jarek Piórkowski  wrote:


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?


Yes, this is what OsmAnd does.


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


It can be calculated. So why complicating mapping and maintaining
public transportation routes needlessly? :)


Because sometimes it can't (think of a fence or ditch between ways that 
is not mapped - besides, for renderers it is relatively hard to 
calculate whether there is something between a node and a way and 
whether that constitutes a barrier.


Please take note that the stop_position is _optional_ in PTv2! It 
doesn't need to be mapped!



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


If we go for the "improved PTv1" solution, my suggestion [1] was to
place both highway=bus_stop and railway=tram_stop beside the road.
Thus, highway=bus_stop and railway=tram_stop can and should be
combined on one node.


The PTv2 solution has this all and unifies tram and buses, while not 
being more complicated than bidirectional PTv1, except it has some 
optional features that make things unambiguous in difficult cases...



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


As i understand it [2], public_transit=platform does not describe
imaginary things. On a node, it means the waiting area of a stop
(i.e., it is equivalent to highway=bus_stop or railway=tram_stop), and
on a way or area, it means a real platform that acts as a stop (i.e.,
it is a combination of highway=bus_stop/railway=tram_stop and
highway=platform/railway=platform).

However, in my opinion it would have been better to create a tag like
public_transport=stop that -- as with all other tags -- always
(regardless of whether used on a node, way or area) means the same
thing (waiting area of a stop) and that could be used in combination
with highway=platform/railway=platform if there is a platform.


I think that is being pedantic. In The Netherlands, most "platform" bus 
stops can not be discerned from a normal sidewalk if not for a slightly 
raised kerb or block markings that have a second meaning of parking 
(within a certain distance of that marking).
To check whether someone is in the dirt or on pavement, one could always 
add a surface tag to the platform.



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


I think that a simpler mapping and maintaining of the routes as well
as a better routing are good reasons enough. :)


As well as unification of tram and bus mapping (and train for the same 
matter)



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.


In my opinion, if we decide to stick with PTv1 tags, the best way
would be to add a highway=bus_stop or railway=tram_stop in the middle
of the highway/railway=platform way or area.


I don't understand what you mean here, with add a highway=bus_stop in 
the middle of what? Of the highway way where the bus drives, or in the 
middle of the highway=platform way?


Why would we need this double-tagging of a way:highway=platform + 
node:highway=bus_stop?


Wouldn't it be simpler to have one tag that has the semantic meaning of 
"place where one waits to board/alights" that has the same meaning 
whether it is one spot, a linear element or an area, whether it is for a 
bus, tram or train? That would be public_transport=platform!


IIVQ

___
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

[Markus]

On Sun, 12 May 2019 at 18:06, Jarek Piórkowski  wrote:
>
> A requirement would be having one direction per relation, otherwise
> vehicles going in opposite directions might still be mapped to an
> incorrect stop_position if 2+ trip directions pass through a station.

Yes, this was the idea: PTv1 tags, but separate route relations per
direction and route variant, and bus and tram stops placed at the
waiting area.

Regards

Markus

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

On Sun, 12 May 2019 at 09:57, Jarek Piórkowski  wrote:
> I can imagine calculating correct stop position being challenging in
> case of multi-lane bus stations like
> https://www.openstreetmap.org/way/37096072 (looks like
> https://en.wikipedia.org/wiki/File:Islington_TTC_Bus_Barns.jpg in
> reality) or https://www.openstreetmap.org/way/617387384.

Follow-up: I've just re-read your other message where you mentioned
that with correct relation tagging, you would take a projection of
platform/bus_stop onto the nearest vehicle way which is in the route
relation.

In my experience the vehicle ways are included in route relations more
often than the stop/platform details, so it seems fair to expect that
if platform is mapped in detail, the routes using that platform will
have ways also included in the route relations. Of course route
relations are a bit prone to breaking, but so is detailed station
mapping.

A requirement would be having one direction per relation, otherwise
vehicles going in opposite directions might still be mapped to an
incorrect stop_position if 2+ trip directions pass through a station.

The possible edge cases I'm coming up with (trips where a vehicle
serves the same station twice _in one trip_ but on different
platforms) seem like they'd be incredibly rare so I am alright
ignoring them.

So I would agree that a strong case can be made for stop_position not
being necessary, provided we have a requirement that
platform/bus_stop/equivalent is not on the vehicle way, and that we
have only one trip direction in a route relation.

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

[Jarek Piórkowski]

On Thu, 9 May 2019 at 17:04, Markus  wrote:
> Could you please give some examples where the stop position can't be
> calculated from the waiting area? I'd also like to know for which use
> cases the stop positions are necessary.

I can imagine calculating correct stop position being challenging in
case of multi-lane bus stations like
https://www.openstreetmap.org/way/37096072 (looks like
https://en.wikipedia.org/wiki/File:Islington_TTC_Bus_Barns.jpg in
reality) or https://www.openstreetmap.org/way/617387384.

In case of Islington the individual stops/platforms are currently not
mapped, but if they were added, calculating the correct stopping
position will also require the router knowing if traffic in the region
is left hand or right hand - that is, on which side the buses have
doors, and thus in which lane they will be.

Then there is the weird case of
https://en.wikipedia.org/wiki/Harvard_station#Harvard_Bus_Tunnel where
buses run on the off-side, and some buses have doors on the off-sides
for historical infrastructure reasons.

Arguably the exact stopping position doesn't matter very much - does
it matter if you show the bus route on the next lane, 3 m over? But it
does complicate absolute correctness.

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

[Dave F via Talk-transit]

For reasons I've already stated I disagree with everything in this post, 
but this epitomises why the public transport schema concept was a 
complete cock-up:



I think it is suitable to go the way of unifying it as much as possible under 
the p_t-umbrella.


 * It wasn't to enable routers to design software
 * It wasn't to add anything new to the database
 * It wasn't to make it mapping easier.
 * It wasn't to simplify tagging (the PT equivalent of highway=bus_stop
   requires 100% more tags!)

It was purely to satiate the compulsive desire to compartmentalize, 
group obsessively into boxes. The jumbled up mess of PT's wiki pages 
show It failed to simplify matters; to the extent even those who were on 
board at the beginning are confused.


Think of all that wasted time which could have been spent on 
productively adding quality to the OSM database.


DaveF



___
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

[Markus]

On Tue, 7 May 2019 at 21:15, Jarek Piórkowski  wrote:
>
> 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?

Yes, this is what OsmAnd does.

> 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

It can be calculated. So why complicating mapping and maintaining
public transportation routes needlessly? :)

> 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?

Even if the stop (the waiting area) is mapped as a way or area, its
centroid can be calculated and projected on the road. In most cases,
parallel roads shouldn't be a problem either, as only one of them
would be in the route relation.

> 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

If we go for the "improved PTv1" solution, my suggestion [1] was to
place both highway=bus_stop and railway=tram_stop beside the road.
Thus, highway=bus_stop and railway=tram_stop can and should be
combined on one node.

[1]: 
https://lists.openstreetmap.org/pipermail/talk-transit/2019-April/002052.html

> 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

As i understand it [2], public_transit=platform does not describe
imaginary things. On a node, it means the waiting area of a stop
(i.e., it is equivalent to highway=bus_stop or railway=tram_stop), and
on a way or area, it means a real platform that acts as a stop (i.e.,
it is a combination of highway=bus_stop/railway=tram_stop and
highway=platform/railway=platform).

However, in my opinion it would have been better to create a tag like
public_transport=stop that -- as with all other tags -- always
(regardless of whether used on a node, way or area) means the same
thing (waiting area of a stop) and that could be used in combination
with highway=platform/railway=platform if there is a platform.

[2]: https://wiki.openstreetmap.org/w/index.php?oldid=625726

> 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

I think that a simpler mapping and maintaining of the routes as well
as a better routing are good reasons enough. :)

> 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.

In my opinion, if we decide to stick with PTv1 tags, the best way
would be to add a highway=bus_stop or railway=tram_stop in the middle
of the highway/railway=platform way or area.

Regards

Markus

___
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

[Markus]

On Wed, 8 May 2019 at 22:15, Tijmen Stam  wrote:
>
> On 06-05-19 19:29, Stephen Sprunk wrote:
> >
> > I'd love to see stop areas go away, or at least limited to instances
> > where the link between stop position and platform can't be deduced from
> > geometry.  Heck, in most cases, the stop position itself can be deduced
> > from the platform and route geometry--assuming the platform is in the
> > route relation, which isn't always the case.
>
> But in some it can't.

Could you please give some examples where the stop position can't be
calculated from the waiting area? I'd also like to know for which use
cases the stop positions are necessary.

> Also, the stop_area is, in the Netherlands, a concept used to map all
> stops "belonging" to each other together, for trhansit open data/transit
> planners. e.g. all four stops around a junction will be one "stop_area"
> (having one ref:IFOPT:NL:S: reference), even when those four
> stops will have different names (e.g. named in pairs after the side street).

If stops share the same ref, there is no need for a stop_area, as they
are already in a relation with each other by having the same ref.

Regards

Markus

___
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

[Jo]

The thing is, as the area around Stockholm clearly shows, highway=bus_stop
is indeed sufficient. If I were to remove all the
public_transport=platform/bus=yes tags from the stops in Belgium, it's very
likely that nobody would notice. If I were to remove highway=bus_stop, all
of  sudden it would seem that Belgium doesn't have bus stops anymore.

"Killing off" highway=bus_stop is what I have been trying to do (somewhat
passively, or at least not very actively) for the past few years. Since
about a year I came to the conclusion that forsaking public_transport tags
would be more straightforward if we really want a simplification.

And double tagging everyting to please everyone is quite likely the easiest
thing to keep doing, even though it's awkward every time when you have to
explain a highway=bus_stop isn't actually a highway and a
public_transport=platform isn't actually a platform in 90% of the bus stops
involved.

This is probably what is going to happen, because the people who would like
to abolish the public_transport tags will never agree with the people who
want to abolish the highway=bus_stop tags.

Polyglot, le défaitiste

On Thu, May 9, 2019 at 9:46 PM DC Viennablog 
wrote:

> Yes, one object would be nice, however, I think it should be versatile
> enough to be able to be a node, line or polygon.
> So basically what public_transport=platform is.
> I also don't mind it being called "platform", even if there is only a pole
> stuck in a field.
> That would not make p_t:v2 mapping futile, but enable a simpler scheme.
> Also, we would not have the problem of having "bus_stop", "tram_stop",
> "train_stop" being different things.
>
> The highway=bus_stop tag is a thing that locks the mode of transport in to
> much. That should be killed of, especially because a bus waiting area is
> pushing the "highway" tag a little bit (as are things like
> "highway=footway", but I don't want to fully open that box here now!).
>
> Those tags like hw=bus_stop or railway=station were thought up at a time,
> when those things (in OSM) were not seen as a group (public_transport) but
> as they are in reality pretty similar in use and form of amenity, I think
> it is suitable to go the way of unifying it as much as possible under the
> p_t-umbrella.
>
> Also, any tag that is duplicating p_t tags in the "railway"-key-area
> should possibly be looked at, but I think we would first need to simplify
> the p_t in order for any other keys to be fitted to that.
>
> So how would people like the suggestion:
>
>
>- Keeping only public_transport=platform as a needed object, without
>hw=bus_stop
>   - (as it should also be used for trams, trains and any other mean
>   of public_transport – thinking things like the "Emirates Air Line" in
>   London).
>- In a route relation, also only have that platform (with role "stop")
>and the streets/rails.
>   - You would still need to make sure the first/last street of the
>   relation ends on a node near the platform point/area!
>- Additional, purely convenient tags to say which mode of transport
>stops there (bus=yes, tram=yes...)
>
> That would only be a slight tweak, that would still make the mapping more
> straight forward, but also make it more dynamic in the usage-possibilities.
>
> Also, I think stop_area-relations should be rethought as grouping many
> stations that could be interchanged between together. Take the Hauptbahnhof
> in Vienna for example. The "Fernbusbahnhof", the regional bus terminal, the
> station "Hauptbahnhof" of 13A/69A, the station "Hauptbahnhof Süd" of the
> 69A and possibly even "Gertrude-Fröhlich-Sandner-Straße" are all just
> situated at or near exits of the train station. So they are all part of
> that "station-area". So I think, the stop-area should be kept, but as a
> more useful relation to sum up stop/station complexes. That is a much
> greater use for a relation than just telling within the database that one
> thing belongs to another that is right next to it...
>
> And if required, the deletion/retagging of
> stop_position/bus_stop/(tram_stop) nodes in areas where
> "platform"-nodes/ways exist could be done in a semi-mechanical edit.
>
> Then, maybe the renders would also hail this only available tag as
> something worth showing...
>
> KR
> RobinD. (emergency99)
> --
> *Von:* Jo 
> *Gesendet:* Donnerstag, 9. Mai 2019 20:22
> *An:* Public transport/transit/shared taxi related topics
> *Betreff:* Re: [Talk-transit] Ideas for a simplified public
> transportation scheme
>
> I have been holding off to respond to this. 

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

[DC Viennablog]

Yes, one object would be nice, however, I think it should be versatile enough 
to be able to be a node, line or polygon.
So basically what public_transport=platform is.
I also don't mind it being called "platform", even if there is only a pole 
stuck in a field.
That would not make p_t:v2 mapping futile, but enable a simpler scheme. Also, 
we would not have the problem of having "bus_stop", "tram_stop", "train_stop" 
being different things.

The highway=bus_stop tag is a thing that locks the mode of transport in to 
much. That should be killed of, especially because a bus waiting area is 
pushing the "highway" tag a little bit (as are things like "highway=footway", 
but I don't want to fully open that box here now!).

Those tags like hw=bus_stop or railway=station were thought up at a time, when 
those things (in OSM) were not seen as a group (public_transport) but as they 
are in reality pretty similar in use and form of amenity, I think it is 
suitable to go the way of unifying it as much as possible under the 
p_t-umbrella.

Also, any tag that is duplicating p_t tags in the "railway"-key-area should 
possibly be looked at, but I think we would first need to simplify the p_t in 
order for any other keys to be fitted to that.

So how would people like the suggestion:


  *   Keeping only public_transport=platform as a needed object, without 
hw=bus_stop
 *   (as it should also be used for trams, trains and any other mean of 
public_transport – thinking things like the "Emirates Air Line" in London).
  *   In a route relation, also only have that platform (with role "stop") and 
the streets/rails.
 *   You would still need to make sure the first/last street of the 
relation ends on a node near the platform point/area!
  *   Additional, purely convenient tags to say which mode of transport stops 
there (bus=yes, tram=yes...)

That would only be a slight tweak, that would still make the mapping more 
straight forward, but also make it more dynamic in the usage-possibilities.

Also, I think stop_area-relations should be rethought as grouping many stations 
that could be interchanged between together. Take the Hauptbahnhof in Vienna 
for example. The "Fernbusbahnhof", the regional bus terminal, the station 
"Hauptbahnhof" of 13A/69A, the station "Hauptbahnhof Süd" of the 69A and 
possibly even "Gertrude-Fröhlich-Sandner-Straße" are all just situated at or 
near exits of the train station. So they are all part of that "station-area". 
So I think, the stop-area should be kept, but as a more useful relation to sum 
up stop/station complexes. That is a much greater use for a relation than just 
telling within the database that one thing belongs to another that is right 
next to it...

And if required, the deletion/retagging of stop_position/bus_stop/(tram_stop) 
nodes in areas where "platform"-nodes/ways exist could be done in a 
semi-mechanical edit.

Then, maybe the renders would also hail this only available tag as something 
worth showing...

KR
RobinD. (emergency99)
____________
Von: Jo 
Gesendet: Donnerstag, 9. Mai 2019 20:22
An: Public transport/transit/shared taxi related topics
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme

I have been holding off to respond to this. Almost a decade ago I started 
asking for public_transport=platform combined with bus=yes to be rendered, so 
it would become possible to drop highway=bus_stop.

After all those years it has become obvious that there is no willingness to do 
so. So it makes sense to drop the public_transport tagging scheme instead as it 
clearly failed to deliver on its promise to streamline mapping of public 
transport.

As far as I am concerned a few things are important:

* 1 single object to represent a bus stop.
* This object should clearly show on which side of the way the stop is located.
* My preference is to have this mapped on a single node, which keeps 
representing the stop for its 'lifetime'.
* There is no problem to use highway=bus_stop for such a node.

So far, so good.

In Belgium, the cities of Antwerp and Ghent and all the villages along the 
coast have trams which are operated by the same operator as the buses. This 
means that it can happen that the pole next to where the passengers wait serves 
for both buses and trams. The operator assigned a single reference number to 
these, so for me it's obvious that such tram stops go on those same nodes and 
by extension so do all the other tram stops.
Apparently though tram and other rail infrastructure does have nodes, but those 
nodes seem to be mapped as nodes on the railway itself and that's where things 
start to clash. Not really a big deal, unless you meet a mapper who insists 
those nodes should be on the railway ways...

By analogy I would also have nodes next to the railway fo

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

[Jo]

I have been holding off to respond to this. Almost a decade ago I started
asking for public_transport=platform combined with bus=yes to be rendered,
so it would become possible to drop highway=bus_stop.

After all those years it has become obvious that there is no willingness to
do so. So it makes sense to drop the public_transport tagging scheme
instead as it clearly failed to deliver on its promise to streamline
mapping of public transport.

As far as I am concerned a few things are important:

* 1 single object to represent a bus stop.
* This object should clearly show on which side of the way the stop is
located.
* My preference is to have this mapped on a single node, which keeps
representing the stop for its 'lifetime'.
* There is no problem to use highway=bus_stop for such a node.

So far, so good.

In Belgium, the cities of Antwerp and Ghent and all the villages along the
coast have trams which are operated by the same operator as the buses. This
means that it can happen that the pole next to where the passengers wait
serves for both buses and trams. The operator assigned a single reference
number to these, so for me it's obvious that such tram stops go on those
same nodes and by extension so do all the other tram stops.
Apparently though tram and other rail infrastructure does have nodes, but
those nodes seem to be mapped as nodes on the railway itself and that's
where things start to clash. Not really a big deal, unless you meet a
mapper who insists those nodes should be on the railway ways...

By analogy I would also have nodes next to the railway for subway and maybe
even for train, but I never actually got around to mapping train
infrastructure, the 7 bus and tram stops were enough to keep me busy.

Polyglot

On Thu, May 9, 2019 at 1:19 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

>
>
> On 08/05/2019 20:56, Tijmen Stam wrote:
> >
> > I never understood the whole railway=platform discussion.
> > IHMO hw=bus_stop, hw=platform and rw=platform should die, and all be
> > replaced by public_transport=platform
>
> You fail to say why.
>
> > I have updated entire public transport concessions with almost all
> > stops having a platform way or area. In places where I did make
> > something _new_, I didn't include highway=bus_stop and deleted the old
> > one,
>
> Please clarify what you mean by the "old one"
>
> > under the "don't tag for the renderer" idea, and everything works fine
> > on my preferred renderer (osmand)
>
> That isn't the only rendering
>
>
> DaveF
>
> ___
> 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 08/05/2019 20:56, Tijmen Stam wrote:


I never understood the whole railway=platform discussion.
IHMO hw=bus_stop, hw=platform and rw=platform should die, and all be 
replaced by public_transport=platform


You fail to say why.

I have updated entire public transport concessions with almost all 
stops having a platform way or area. In places where I did make 
something _new_, I didn't include highway=bus_stop and deleted the old 
one,


Please clarify what you mean by the "old one"

under the "don't tag for the renderer" idea, and everything works fine 
on my preferred renderer (osmand)


That isn't the only rendering


DaveF

___
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

[Tijmen Stam]

On 06-05-19 19:29, Stephen Sprunk wrote:

On 2019-04-30 06:06, Dave F via Talk-transit wrote:

On 29/04/2019 16:22, Stephen Sprunk wrote:


Stop areas are supposed to link stop positions to platforms, so a 
router knows which platform you need to take a route that only stops 
on a particular track.  In most cases, this can be inferred by 
proximity, but in some it can't, particularly at very complex stations.


If there needs to be a 'link' (& I'm still not convinced it does), can
it not be achieved with unifying tags on nodes/ways? Why does it
require a relation?

Relations were devised to allow items which couldn't be achieved on
nodes/ways alone (ie routes) not to collect things together. If it can
be done without relations it makes tagging so much simpler & less
prone to errors.


What is the "unifying tag" you propose, and how would it work?

I'd love to see stop areas go away, or at least limited to instances 
where the link between stop position and platform can't be deduced from 
geometry.  Heck, in most cases, the stop position itself can be deduced 
from the platform and route geometry--assuming the platform is in the 
route relation, which isn't always the case.


But in some it can't.

Also, the stop_area is, in the Netherlands, a concept used to map all 
stops "belonging" to each other together, for trhansit open data/transit 
planners. e.g. all four stops around a junction will be one "stop_area" 
(having one ref:IFOPT:NL:S: reference), even when those four 
stops will have different names (e.g. named in pairs after the side street).


Example of a stop_area with stops: 
 (unfortunately, this is 
not the best example as the whole station complex is divided into three 
stop_areas, one for the subway, and two for the east and west bus station)


___
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

[Tijmen Stam]

On 28-04-19 16:27, Jarek Piórkowski wrote:

On Sun, 28 Apr 2019 at 10:04, Markus  wrote:



Tram stops often have platforms (and bus stops sometimes too). For
such stops, two PTv1 elements are necessary because railway=tram_stop
can't be used on the same area (or way) as railway=platform (they use
the same key). With a new tag for stops (such as the suggested
public_transport=stop tag) or a new tag for platforms, this were
possible. However, much retagging were needed. Alternatively,
railway=tram_stop (or highway=bus_stop) could be placed on the
platform area (first suggested solution).


In some cases I've seen (https://osm.org/way/395511322 comes to mind),
the duplicate tagging when platforms are present is handled by having
hw=bus_stop tag on one of the nodes of the platform way, and then the
platform way has hw=platform (pt=platform in this case but it would
work with hw=platform as well). That helps to compute "these are part
of one logical stop" without needing a relation.


I never understood the whole railway=platform discussion.
IHMO hw=bus_stop, hw=platform and rw=platform should die, and all be 
replaced by public_transport=platform (but for widespread acceptance, 
rendering on openstreetmap.org standard and public_transport layers, for 
node/way/areas should exist).


I have updated entire public transport concessions with almost all stops 
having a platform way or area. In places where I did make something 
_new_, I didn't include highway=bus_stop and deleted the old one, under 
the "don't tag for the renderer" idea, and everything works fine on my 
preferred renderer (osmand)


IIVQ

___
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

[Tijmen Stam]

On 28-04-19 16:02, Markus wrote:

On Sat, 27 Apr 2019 at 14:30, Snusmumriken
 wrote:


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.


In my opinion, it's never too late for improvements. :) And if we go
for the first solution ("improved PTv1"), not much retagging were
required as nearly all stops, stations and platforms use the PTv1 tags
for rendering anyway.


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


This seems like normal PTv1 except you have routes in both ways, which 
very easily could be brought up to PTv2 standards:


If you would give the stop nodes the "platform" node instead of "stop" 
and public_transport=platform (and move all the stops to the top of the 
ways), you would confirm to PTv2 (off course you would also have to 
change the version from 1 to 2).


Note that nowhere in the PTv2 wiki it says it is mandatory to have both 
a stop and a platform! Either one is ok (although I strongly prefer to 
have both).


IIVQ

___
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

[Ed Loach]

I've been generally ignoring this thread, but did spot the handy summary from 
Jarek.

In particular:

> 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

I do not use the (documented as optional last time I looked) stop_position 
nodes. The (UK based) opendata I use for maintaining local bus routes[1][2] is 
based on a dataset which includes the latitude and longitude of the stop nodes 
(I add both highway=bus_stop and public_transport=platform to such nodes), and 
the routes data which contains ordered lists of the stop nodes based on their 
reference in the stops dataset. Recently someone "broke" one of the relations 
by removing the stop/platform nodes and adding stop_position ones instead. I 
did leave those stop_position nodes when I added the platform nodes back, but 
ignore them in my validation.

Ed

[1] https://wiki.openstreetmap.org/wiki/Tendring(Essex)/Bus_Routes
[2] https://wiki.openstreetmap.org/wiki/Colchester(Essex_District)/Bus_Routes



___
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

[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] Ideas for a simplified public transportation scheme

[Stephen Sprunk]

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).



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.


Ditto for railway=platform implying public_transport=platform, 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.


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.  Same as any 
other structure where someone puts a node as a "temporary" marker.  It's 
better than nothing, but it can be improved.


If you're trying to construct a route that involves walking to a bus 
stop, riding the bus to another stop, and then walking some more, then 
you need a linkage connecting the bus route (using stop positions) 
with the walkways (using platforms).  I'm not saying that's the only 
way to do it, but it's the only way that was proposed.


Do you have an example as I'm unsure what you mean by 'walkways' and
platforms are disconnected from the bus routes, as are bus stops, so,
as I said above, PT can use bus stops.


Walkways as in places where people walk.  The router needs to give me 
directions down the sidewalk or whatever to where I wait for the bus.  
If the only node is on the highway, am I supposed to stand in the middle 
of the highway until I get hit by the bus?  No, it should route me to 
the platform beside the highway.


But the bus stays on the way, so it can't stop at a platform correctly 
off the way.  That's where the stop position comes in, and the supposed 
need to link the two together.



Markus previously said "OsmAnd Is able to navigate with routes
consisting only of highway=bus_stop beside the road."


I assuming they're calculating the stop position based on geometry, 
which  should work fine in most cases.  But if an explicit stop position 
does exist, they should use that instead.



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.


S

--
Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

___
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 04/05/2019 19:15, john whelan wrote:


Unfortunately people make notes often on paper.  So someone leading a
mapping group will refer to their notes when repeating the exercise.
Finding those notes and correcting them is not easy.

Experience is what you get when you don't get what you expected.


  Not sure of the relevance of that to the subject of this thread. That 
could occur in any OSM scenario.


DaveF

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

>
> .
>
> I don't understand. Tutorials are local, or do you mean bus stops? Local
> to what? All entities are locatable.
> Please expand.
>
> Cheers
> DaveF
>

Unfortunately people make notes often on paper.  So someone leading a
mapping group will refer to their notes when repeating the exercise.
Finding those notes and correcting them is not easy.

Experience is what you get when you don't get what you expected.

Cheerio John

>
___
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 04/05/2019 16:01, John Whelan wrote:
So can the proposal build on existing highway=bus_stop? 


I've yet to hear a reason why.

On reason for this is a number of cites have imported their bus stops 
from Open Data which ensures completeness.  ie all the bus stops in 
the city are present and occasionally they are reimported to catch any 
new bus stops or removal of others.  Changing from bus stops means 
everyone who does this sort of import has to reconfigure their import 
system and doing that will be awkward and may lead to a bus stop being 
mapped twice.


*All* edits from a single node to a world wide mass import requires care 
& attention.It shouldn't prevent the database quality rom being 
improved. I don't equate change with being awkward


Also there are existing tutorials on how to map a bus stop.  Many will 
be local so finding them to correct them will be a major problem.


I don't understand. Tutorials are local, or do you mean bus stops? Local 
to what? All entities are locatable.

Please expand.

Cheers
DaveF

___
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 can the proposal build on existing highway=bus_stop?  On reason for 
this is a number of cites have imported their bus stops from Open Data 
which ensures completeness.  ie all the bus stops in the city are 
present and occasionally they are reimported to catch any new bus stops 
or removal of others.  Changing from bus stops means everyone who does 
this sort of import has to reconfigure their import system and doing 
that will be awkward and may lead to a bus stop being mapped twice.


Also there are existing tutorials on how to map a bus stop.  Many will 
be local so finding them to correct them will be a major problem.


Thoughts?

Thanks

Cheerio John

Dave F via Talk-transit wrote on 2019-05-04 10:53 AM:

Hi

On 04/05/2019 11:12, Wiklund Johan wrote:
At least in Norway, highway=bus_stop is a free floating node 
representing the location of a stop,


public_transport=platform is also 'free floating'.


not the geometry of a stop.


147 platforms are nodes.

In the examples of your overpass public_transport=platform doesn't 
represent the geometry of a stop, just arbitrary areas of pavement 
adjacent to bus stop poles. Other furniture maybe present (shelter, 
bench etc) but they can either be added as extra tags to the more 
abundant highway=bus_stop or, preferably, as separate items.


I should also say that platforms are abundant in Norway, especially 
in the Oslo region where consistent mapping is in place. 
http://overpass-turbo.eu/s/IGK


There are 300 more bus stops than platforms 
http://overpass-turbo.eu/s/IHi


Bus stops can be tagged to provide the same data. Think of the time & 
effort saved if they'd been utilised.


Just because something was mapped incorrectly in the past it doesn't 
mean it should continue. It should be corrected to improve the 
database Please remember this thread (& others) were started in an 
attempt to "simplified public transportation scheme". To achieve that, 
remapping & code rewriting will have to occur.


PS This one doesn't look right: 
https://www.openstreetmap.org/way/361309229


Cheers
DaveF



/Johan

-Original Message-
From: Dave F via Talk-transit 
Sent: fredag 3. mai 2019 23.56
To: talk-transit@openstreetmap.org
Cc: Dave F 
Subject: Re: [Talk-transit] Ideas for a simplified public 
transportation scheme


Hi Johan

Is there reason it can't use highway=bus_stop,& equivalents for trams 
etc, which were already in the database & more abundant than 'platform'?


DaveF

On 03/05/2019 21:48, Wiklund Johan wrote:

In response to:
Please show me a router which uses platforms as I'm struggling to 
see the benefits atm.

And:

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


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/3890a0f451e1a6900d174b29125b3
c80.jpg
We use public_transport=platform abundantly in routing with OTP, and 
it is a key component in specifying the origin of walk links. We use 
it as an area, or a way. We need these to make direct contact 
between our stops (separate database) and the foot-routing network 
of OSM.


I further see no problem in extending the usage of the platform 
(public_transport=platform) to any waiting area for public 
transport. To force correct word description would force one to use 
terms like "street_waiting_area" "dirt_pit", "ditch" or "sidewalk" 
which would only be hairsplitting. If the usage of the word platform 
is misappropriation, I think it is the wording in the scheme that is 
too narrowly defined, rather than the widespread usage being wrong.


However, don’t get me wrong. I don’t really care what it's called as 
long as there is an area which can represent where passengers wait, 
and to which public transport vehicles arrive. This is of course the 
needs of our own journey planner, and we have no stake in the wider 
public transport scheme of OSM. I just wanted to show that there are 
indeed routers which use the platforms, and have great emphasis on 
their usage.


In case you were wondering which router I'm talking about:
https://en-tur.no/ (https://github.com/entur/opentripplanner)

Sincerely (and possibly missing a few points because I haven't been
reading the whole discussion),

Johan Wiklund
Entur




-Original Message-
From: Dave F via Talk-transit 
Sent: fredag 3. mai 2019 19.09
To: Public transport/transit/shared taxi related topics
; selfishseaho...@gmail.com
Cc: Dave F 
Subject: Re: [Talk-transit] Ideas for a simplified public
transportation scheme

Hi

(This amalgamates replies to Markus's points in his last post.)

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 

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

[Wiklund Johan]

At least in Norway, highway=bus_stop is a free floating node representing the 
location of a stop, not the geometry of a stop. I should say was, because they 
have since been replaced by data from our stops database so it's not really a 
neutral statement as of where the position is (our position is where the 
passenger crosses over from platform to vehicle), but the old stop mapping was 
the same or very similar (free nodes).
I should also say that platforms are abundant in Norway, especially in the Oslo 
region where consistent mapping is in place. http://overpass-turbo.eu/s/IGK

/Johan

-Original Message-
From: Dave F via Talk-transit  
Sent: fredag 3. mai 2019 23.56
To: talk-transit@openstreetmap.org
Cc: Dave F 
Subject: Re: [Talk-transit] Ideas for a simplified public transportation scheme

Hi Johan

Is there reason it can't use highway=bus_stop,& equivalents for trams etc, 
which were already in the database & more abundant than 'platform'?

DaveF

On 03/05/2019 21:48, Wiklund Johan wrote:
> In response to:
>> Please show me a router which uses platforms as I'm struggling to see the 
>> benefits atm.
> And:
>
>> This reinforces my point about misappropriation of tags. A platform is a 
>> physical construction higher than the surrounding ground to allow easier 
>> boarding.
>>
>> 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/3890a0f451e1a6900d174b29125b3
>> c80.jpg
>
> We use public_transport=platform abundantly in routing with OTP, and it is a 
> key component in specifying the origin of walk links. We use it as an area, 
> or a way. We need these to make direct contact between our stops (separate 
> database) and the foot-routing network of OSM.
>
> I further see no problem in extending the usage of the platform 
> (public_transport=platform) to any waiting area for public transport. To 
> force correct word description would force one to use terms like 
> "street_waiting_area" "dirt_pit", "ditch" or "sidewalk" which would only be 
> hairsplitting. If the usage of the word platform is misappropriation, I think 
> it is the wording in the scheme that is too narrowly defined, rather than the 
> widespread usage being wrong.
>
> However, don’t get me wrong. I don’t really care what it's called as long as 
> there is an area which can represent where passengers wait, and to which 
> public transport vehicles arrive. This is of course the needs of our own 
> journey planner, and we have no stake in the wider public transport scheme of 
> OSM. I just wanted to show that there are indeed routers which use the 
> platforms, and have great emphasis on their usage.
>
> In case you were wondering which router I'm talking about: 
> https://en-tur.no/ (https://github.com/entur/opentripplanner)
>
> Sincerely (and possibly missing a few points because I haven't been 
> reading the whole discussion),
>
> Johan Wiklund
> Entur
>
>
>
>
> -Original Message-----
> From: Dave F via Talk-transit 
> Sent: fredag 3. mai 2019 19.09
> To: Public transport/transit/shared taxi related topics 
> ; selfishseaho...@gmail.com
> Cc: Dave F 
> Subject: Re: [Talk-transit] Ideas for a simplified public 
> transportation scheme
>
> Hi
>
> (This amalgamates replies to Markus's points in his last post.)
>
> 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.
>
> 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/3890a0f451e1a6900d174b29125b3c
> 80.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
>
>
>> 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 t

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

[Dave F via Talk-transit]

Hi Johan

Is there reason it can't use highway=bus_stop,& equivalents for trams 
etc, which were already in the database & more abundant than 'platform'?


DaveF

On 03/05/2019 21:48, Wiklund Johan wrote:

In response to:

Please show me a router which uses platforms as I'm struggling to see the 
benefits atm.

And:


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

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


We use public_transport=platform abundantly in routing with OTP, and it is a 
key component in specifying the origin of walk links. We use it as an area, or 
a way. We need these to make direct contact between our stops (separate 
database) and the foot-routing network of OSM.

I further see no problem in extending the usage of the platform (public_transport=platform) to any waiting area for 
public transport. To force correct word description would force one to use terms like "street_waiting_area" 
"dirt_pit", "ditch" or "sidewalk" which would only be hairsplitting. If the usage of the 
word platform is misappropriation, I think it is the wording in the scheme that is too narrowly defined, rather than 
the widespread usage being wrong.

However, don’t get me wrong. I don’t really care what it's called as long as 
there is an area which can represent where passengers wait, and to which public 
transport vehicles arrive. This is of course the needs of our own journey 
planner, and we have no stake in the wider public transport scheme of OSM. I 
just wanted to show that there are indeed routers which use the platforms, and 
have great emphasis on their usage.

In case you were wondering which router I'm talking about: https://en-tur.no/ 
(https://github.com/entur/opentripplanner)

Sincerely (and possibly missing a few points because I haven't been reading the 
whole discussion),

Johan Wiklund
Entur




-Original Message-
From: Dave F via Talk-transit 
Sent: fredag 3. mai 2019 19.09
To: Public transport/transit/shared taxi related topics 
; selfishseaho...@gmail.com
Cc: Dave F 
Subject: Re: [Talk-transit] Ideas for a simplified public transportation scheme

Hi

(This amalgamates replies to Markus's points in his last post.)

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.

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



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.


I think the idea was that nobody _could_ build routers with the data
we had, which was inconsistently tagged between areas and sometimes
even between mappers in the same area.

This maybe true, but as I point out in my previous post, adding extra tags only masks the 
problems. The "inconsistencies" should be corrected.


If you're trying to construct a route that involves walking to a bus
stop, riding the bus to another stop, and then walking some more, then
you need a linkage connecting the bus route (using stop positions)
with the walkways (using platforms).  I'm not saying that's the only
way to do it, but it's the only way that was proposed.

Do you have an example as I'm unsure what you mean by 'walkways' and platforms 
are disconnected from the bus routes, as are bus stops, so, as I said above, PT 
can use bus stops.

Markus previously said "OsmAnd Is able to navigate with routes consisting only of 
highway=bus_stop beside the road."

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 anot

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

[Wiklund Johan]

In response to:
> Please show me a router which uses platforms as I'm struggling to see the 
> benefits atm.

And:

> This reinforces my point about misappropriation of tags. A platform is a 
> physical construction higher than the surrounding ground to allow easier 
> boarding.
>
> 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


We use public_transport=platform abundantly in routing with OTP, and it is a 
key component in specifying the origin of walk links. We use it as an area, or 
a way. We need these to make direct contact between our stops (separate 
database) and the foot-routing network of OSM.

I further see no problem in extending the usage of the platform 
(public_transport=platform) to any waiting area for public transport. To force 
correct word description would force one to use terms like 
"street_waiting_area" "dirt_pit", "ditch" or "sidewalk" which would only be 
hairsplitting. If the usage of the word platform is misappropriation, I think 
it is the wording in the scheme that is too narrowly defined, rather than the 
widespread usage being wrong.

However, don’t get me wrong. I don’t really care what it's called as long as 
there is an area which can represent where passengers wait, and to which public 
transport vehicles arrive. This is of course the needs of our own journey 
planner, and we have no stake in the wider public transport scheme of OSM. I 
just wanted to show that there are indeed routers which use the platforms, and 
have great emphasis on their usage.

In case you were wondering which router I'm talking about: https://en-tur.no/ 
(https://github.com/entur/opentripplanner)

Sincerely (and possibly missing a few points because I haven't been reading the 
whole discussion),

Johan Wiklund
Entur




-Original Message-
From: Dave F via Talk-transit  
Sent: fredag 3. mai 2019 19.09
To: Public transport/transit/shared taxi related topics 
; selfishseaho...@gmail.com
Cc: Dave F 
Subject: Re: [Talk-transit] Ideas for a simplified public transportation scheme

Hi

(This amalgamates replies to Markus's points in his last post.)

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.

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


> 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.

> I think the idea was that nobody _could_ build routers with the data 
> we had, which was inconsistently tagged between areas and sometimes 
> even between mappers in the same area.

This maybe true, but as I point out in my previous post, adding extra tags only 
masks the problems. The "inconsistencies" should be corrected.

>
> If you're trying to construct a route that involves walking to a bus 
> stop, riding the bus to another stop, and then walking some more, then 
> you need a linkage connecting the bus route (using stop positions) 
> with the walkways (using platforms).  I'm not saying that's the only 
> way to do it, but it's the only way that was proposed.

Do you have an example as I'm unsure what you mean by 'walkways' and platforms 
are disconnected from the bus routes, as are bus stops, so, as I said above, PT 
can use bus stops.

Markus previously said "OsmAnd Is able to navigate with routes consisting only 
of highway=bus_stop beside the road."

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?

Cheers
DaveF


_

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

[Stephen Sprunk]

On 2019-04-30 05:50, Dave F via Talk-transit wrote:

On 29/04/2019 19:39, Markus wrote:
On Mon, 29 Apr 2019 at 17:18, Stephen Sprunk  
wrote:
Part of what seems to have started the PTv2 mess is that bus stops 
were
sometimes mapped on the way and sometimes beside the way, and both 
cases
were tagged the same.  PTv2 tried to separate those into "platform" 
and

"stop_position", to bring uniformity across modes.

It would have been a lot easier to just recommend placing stops beside
the road. :)


If there is a problem on the OSM database I believe sorting that
problem is beneficial rather than 'papering over the cracks' by adding
extra tags. It may seem quite laborious, but just as quick as adding
those tags.


I agree.

We need platforms beside the way so routers can get people to/from 
the

stop on foot.  This is a big deal because trains are long and can
usually be boarded along their entire length, unlike buses where a 
node

often suffices.

OTOH, we need stop positions so routers can get people from stop to 
stop

on the buses/trains.


Routers just need the platforms (the places beside the road) because
the journey begins and ends there.


Please clarify what you mean by 'platforms'? Many UK bus stops are
merely signs clamped to telegraph poles. In rural areas there may not
even be a pavement, let alone a raise platform. Please remember that
we should be mapping the physical world. PT schema should fit in with
what's actually there.


A platform is where people wait to board; if they stand at a pole 
(typical for buses), then the pole is logically the platform.  That's 
easily distinguished from large platforms because it's a node rather 
than a way/area.



Stop positions (on the road) are
irrelevant for routing. If someone, for whatever reasons, needs the
stop positions, they can be calculated (projection of the stop node or
centroid of the platform to the highway or railway way).


Wouldn't a stop position be easier to locate if it's a node on the
highway, rather than an imaginary, offset 'platform'?

Please show me a router which uses platforms as I'm struggling to see
the benefits atm.


I think the idea was that nobody _could_ build routers with the data we 
had, which was inconsistently tagged between areas and sometimes even 
between mappers in the same area.


If you're trying to construct a route that involves walking to a bus 
stop, riding the bus to another stop, and then walking some more, then 
you need a linkage connecting the bus route (using stop positions) with 
the walkways (using platforms).  I'm not saying that's the only way to 
do it, but it's the only way that was proposed.


S


--
Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

___
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 28/04/2019 17:13, DC Viennablog wrote:

...But in my opinion, as it stands, for bus or tram stops, these relations do 
not make that much sense. As any software should be able to find those 
connections between stops with the same name, the stop areas are quite 
redundent.


Agreed
Using a Vien example: https://www.openstreetmap.org/relation/7463438
As each stop has a unifying name tag each stop can be found & collected 
together.


Even when in a relation, routers still have to iterate each item to find 
if the bus stop is on the correct street


Note this is also an example of public_transport=platform being misused. 
There are no physical platforms, just a shelter with a bench.



For bigger train stations, with differently named bus stops around it, that all 
belong to it in some way, a relation can be useful, but that case is quite rare.

Disagree
There is no connection, other than approximate location. They're 
different modes of transport, different operators.
A passenger may wish to continue their journey using a bus stop hundreds 
of metres way, How far should this relation encompass?
Bus passengers alighting aren't guaranteed to use the train station, 
they may cross the road to get their hair cut.



  Usually the stations would have the same name. If I find the time, I might 
also write a tagging/relation sugesstion that would slightly unclutter the 
tagging, but as we know, there have been many such suggestions so far, and 
there is never a 100% consensus. But no harm in discussing it.

Agreed
It needs discussing as it's a bit of a mess right now.

Cheers
DaveF




Kind Regards
RobinD. (emergency99)

Von: Markus 
Gesendet: Sonntag, 28. April 2019 16:55:02
An: Public transport/transit/shared taxi related topics
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme

On Sun, 28 Apr 2019 at 16:29, Jarek Piórkowski  wrote:

Oh cool - with routing and time estimates and all?

Navigation while travelling doesn't seem to work yet (it says "public
transport navigation is currently in beta"), but it gives you a
preview of the route: walking route, where to get on and off the
vehicle, intermediate stops, estimated walking and driving time and
distance.

___
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 29/04/2019 16:22, Stephen Sprunk wrote:


Stop areas are supposed to link stop positions to platforms, so a 
router knows which platform you need to take a route that only stops 
on a particular track.  In most cases, this can be inferred by 
proximity, but in some it can't, particularly at very complex stations.


If there needs to be a 'link' (& I'm still not convinced it does), can 
it not be achieved with unifying tags on nodes/ways? Why does it require 
a relation?


Relations were devised to allow items which couldn't be achieved on 
nodes/ways alone (ie routes) not to collect things together. If it can 
be done without relations it makes tagging so much simpler & less prone 
to errors.


Cheers
DaveF

___
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 29/04/2019 19:39, Markus wrote:

On Mon, 29 Apr 2019 at 17:18, Stephen Sprunk  wrote:

Part of what seems to have started the PTv2 mess is that bus stops were
sometimes mapped on the way and sometimes beside the way, and both cases
were tagged the same.  PTv2 tried to separate those into "platform" and
"stop_position", to bring uniformity across modes.

It would have been a lot easier to just recommend placing stops beside
the road. :)


If there is a problem on the OSM database I believe sorting that problem 
is beneficial rather than 'papering over the cracks' by adding extra 
tags. It may seem quite laborious, but just as quick as adding those tags.






We need platforms beside the way so routers can get people to/from the
stop on foot.  This is a big deal because trains are long and can
usually be boarded along their entire length, unlike buses where a node
often suffices.

OTOH, we need stop positions so routers can get people from stop to stop
on the buses/trains.

Routers just need the platforms (the places beside the road) because
the journey begins and ends there.


Please clarify what you mean by 'platforms'? Many UK bus stops are 
merely signs clamped to telegraph poles. In rural areas there may not 
even be a pavement, let alone a raise platform. Please remember that we 
should be mapping the physical world. PT schema should fit in with 
what's actually there.



  Stop positions (on the road) are
irrelevant for routing. If someone, for whatever reasons, needs the
stop positions, they can be calculated (projection of the stop node or
centroid of the platform to the highway or railway way).


Wouldn't a stop position be easier to locate if it's a node on the 
highway, rather than an imaginary, offset 'platform'?


Please show me a router which uses platforms as I'm struggling to see 
the benefits atm.


Cheers
DaveF

___
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

[Markus]

On Mon, 29 Apr 2019 at 17:18, Stephen Sprunk  wrote:
>
> Part of what seems to have started the PTv2 mess is that bus stops were
> sometimes mapped on the way and sometimes beside the way, and both cases
> were tagged the same.  PTv2 tried to separate those into "platform" and
> "stop_position", to bring uniformity across modes.

It would have been a lot easier to just recommend placing stops beside
the road. :)

> We need platforms beside the way so routers can get people to/from the
> stop on foot.  This is a big deal because trains are long and can
> usually be boarded along their entire length, unlike buses where a node
> often suffices.
>
> OTOH, we need stop positions so routers can get people from stop to stop
> on the buses/trains.

Routers just need the platforms (the places beside the road) because
the journey begins and ends there. Stop positions (on the road) are
irrelevant for routing. If someone, for whatever reasons, needs the
stop positions, they can be calculated (projection of the stop node or
centroid of the platform to the highway or railway way).

Regards

Markus

___
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

[Stephen Sprunk]

On 2019-04-28 09:04, Markus wrote:

On Sun, 28 Apr 2019 at 13:47, Dave F via Talk-transit
 wrote:

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?


At least, stop_areas are required for underground stations (if
footways have not been mapped yet) to link the railway=subway_entrance
with the station.

Including other elements than station, platform and entrances IMHO is
useless and makes the relations unnecessarily confusing.


Stop areas are supposed to link stop positions to platforms, so a router 
knows which platform you need to take a route that only stops on a 
particular track.  In most cases, this can be inferred by proximity, but 
in some it can't, particularly at very complex stations.


If an entrance serves a subset of platforms (i.e. you might have to 
leave and re-enter via a different door to change trains), then it might 
make sense in a stop area, but otherwise, it's just part of the station.


S

--
Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

___
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

[Stephen Sprunk]

On 2019-04-28 06:46, Dave F via Talk-transit wrote:

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.


Agreed.


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.


Part of what seems to have started the PTv2 mess is that bus stops were 
sometimes mapped on the way and sometimes beside the way, and both cases 
were tagged the same.  PTv2 tried to separate those into "platform" and 
"stop_position", to bring uniformity across modes.


We need platforms beside the way so routers can get people to/from the 
stop on foot.  This is a big deal because trains are long and can 
usually be boarded along their entire length, unlike buses where a node 
often suffices.


OTOH, we need stop positions so routers can get people from stop to stop 
on the buses/trains.


Where things went off the rails (pun intended) is creating redundant 
mode-neutral tags (probably so routers would work regardless of mode) 
when mode-specific tags already existed.



Is public_transport=platform required at all on bus stops? As with
railways, use existing tags.


Agreed.

S

--
Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

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

Hello everyone,

I will briefly jump into this conversation, as I have mapped quite a few bus 
routes in and around vienna, austria, and amended most Stops there to fit the 
definitions of the pt:v2 from the wiki.

In my view, it would, at least for bus stops, be enough if there was a (bus) 
stop tag (whether highway= or public_transport= can be discussed), on the 
position of the station sign on the sidewalk/platform. Then, an optional way 
(line or polygon) could be added for a real platform (higher or extra sidewalk 
area).
In a route relation, only the stop node (that should then really only ever be a 
node with the station name_ref on it) should be part of that.

For the stop_area relations: I put each belonging stops in Vienna into their 
own stop area relations, as some other mapper once wanted to use them for some 
statistical reading of public transport in the city using the API to find the 
stop areas, which obviously is easier if they are already in relations. But in 
my opinion, as it stands, for bus or tram stops, these relations do not make 
that much sense. As any software should be able to find those connections 
between stops with the same name, the stop areas are quite redundent.

For bigger train stations, with differently named bus stops around it, that all 
belong to it in some way, a relation can be useful, but that case is quite 
rare. Usually the stations would have the same name. If I find the time, I 
might also write a tagging/relation sugesstion that would slightly unclutter 
the tagging, but as we know, there have been many such suggestions so far, and 
there is never a 100% consensus. But no harm in discussing it.

Kind Regards
RobinD. (emergency99)

Von: Markus 
Gesendet: Sonntag, 28. April 2019 16:55:02
An: Public transport/transit/shared taxi related topics
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme

On Sun, 28 Apr 2019 at 16:29, Jarek Piórkowski  wrote:
>
> Oh cool - with routing and time estimates and all?

Navigation while travelling doesn't seem to work yet (it says "public
transport navigation is currently in beta"), but it gives you a
preview of the route: walking route, where to get on and off the
vehicle, intermediate stops, estimated walking and driving time and
distance.

___
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

[seirra blake]

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 
case scenario.


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 
kerb often


On 4/28/19 12:46 PM, Dave F via Talk-transit wrote:

Hello
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.



DaveF

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. [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
public_transport=stop_position and introducing a new transport_mode=*
tag. -- 

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

[Markus]

On Sun, 28 Apr 2019 at 16:29, Jarek Piórkowski  wrote:
>
> Oh cool - with routing and time estimates and all?

Navigation while travelling doesn't seem to work yet (it says "public
transport navigation is currently in beta"), but it gives you a
preview of the route: walking route, where to get on and off the
vehicle, intermediate stops, estimated walking and driving time and
distance.

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

On Sun, 28 Apr 2019 at 10:04, Markus  wrote:
> I've tested the bus routes from Stockholm in OsmAnd. They seem to work
> perfectly despite not having any public_transport=platform tags and
> public_transport=stop_position nodes.

Oh cool - with routing and time estimates and all?

> Tram stops often have platforms (and bus stops sometimes too). For
> such stops, two PTv1 elements are necessary because railway=tram_stop
> can't be used on the same area (or way) as railway=platform (they use
> the same key). With a new tag for stops (such as the suggested
> public_transport=stop tag) or a new tag for platforms, this were
> possible. However, much retagging were needed. Alternatively,
> railway=tram_stop (or highway=bus_stop) could be placed on the
> platform area (first suggested solution).

In some cases I've seen (https://osm.org/way/395511322 comes to mind),
the duplicate tagging when platforms are present is handled by having
hw=bus_stop tag on one of the nodes of the platform way, and then the
platform way has hw=platform (pt=platform in this case but it would
work with hw=platform as well). That helps to compute "these are part
of one logical stop" without needing a relation.

My other observation is that perhaps the relatively relation-rich PTv2
came around in years when relations were cool and a solution to
everything. I haven't been around OSM much, but reading through some
historical conversations I get the sense that there's been a bit of a
swing back with many people now disliking relations for things that
are geographically close (and thus computable as belonging together).
Does this perhaps explain the stop_area origin and why it currently
seems not as useful?

Thanks,
--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

[Markus]

On Sun, 28 Apr 2019 at 13:47, Dave F via Talk-transit
 wrote:
>
> 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?

At least, stop_areas are required for underground stations (if
footways have not been mapped yet) to link the railway=subway_entrance
with the station.

Including other elements than station, platform and entrances IMHO is
useless and makes the relations unnecessarily confusing.

> 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.

I completely agree.

Regards

Markus

___
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

[Markus]

On Sat, 27 Apr 2019 at 14:30, Snusmumriken
 wrote:
>
> 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.

In my opinion, it's never too late for improvements. :) And if we go
for the first solution ("improved PTv1"), not much retagging were
required as nearly all stops, stations and platforms use the PTv1 tags
for rendering anyway.

> 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

Thanks for the link. This routes seem to have been mapped the same way
as the first solution i've suggested.

Regards

Markus

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

Hello
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.



DaveF

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. [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
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.

[1]: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Transport_modes_on_platforms_and_stations
[2]: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport

Thanks in advance for your replies.

Best regards

Markus

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

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

[Jarek Piórkowski]

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] Ideas for a simplified public transportation scheme

[Snusmumriken]

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

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

[Mateusz Konieczny]

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

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

[Marco Antonio]

Aun existen problemas al mapear elemento de transporte publico... markus
pregunta si se puede mejorar las etiquetas...

Abrazos,

Marco Antonio


On Fri, 26 Apr 2019 at 15: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
> 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.
>
> [1]:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Transport_modes_on_platforms_and_stations
> [2]:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport
>
> Thanks in advance for your replies.
>
> Best regards
>
> Markus
>
> ___
> 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