Re: [Talk-transit] stop_position proposal

[Roland Olbricht]

Dear all,

as a follow-up a statistic about whether highway=bus_stop is rather used 
on-street or off-street. The vast majority is (now) mapping bus stops 
off the street. The numbers vary, 99% of all bus stops in United Kingdom 
are mapped off street, about 80%-90% in France, Italy, and Germany. But 
also only 65% in Poland.


The request is per country, here "United Kingdom" as an example. Please 
change the country to your country of interest:

https://overpass-turbo.eu/s/xXp
The runtime can vary, and for Germany it is several minutes.
The important data points are the first entries on the "Data" tab.
The results visiable on the map indicate which stops the query could not 
sort as either on-the-road or off-the-road (including being on a footway 
or similar) because it could not classify the highway value as footway 
or vehicle related. highway=pedestrian is classified as vehicle way, 
because in all the examples I have checked it has been used that way:

https://overpass-turbo.eu/s/xXq

Maybe we should, rather than blurring the line between on-street and 
off-street use, make off-street the officially preferred way of mapping.


Best regards,
Roland

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

Re: [Talk-transit] Proposal for simplification of mapping public transport

[Stephen Sprunk]

stop_position is even worse for trains, which might be hundreds of
meters long with dozens of doors.  The wiki says to map it as the
"center" of the train, but I'm not sure that's useful other than to
explicitly indicate which track the train uses, which could probably be
deduced from the route relation anyway.  It's also not necessarily a
fixed point; at stations here where all passengers enter/exit a platform
at one end, trains always stop with their front/rear at that end of the
platform, so the center depends on the train's length.  Heck, even the
platform a route uses is not necessarily fixed; at many large stations,
different trains on the same route can show up on different platforms or
tracks, and that case doesn't seem to be mappable at all today. 

It seems a bit simpler for buses, where the front generally stops in the
same place every time and folks generally enter the front door, though
there are always exceptions.  The location of exit-only doors doesn't
seem like something that needs mapping. 

S 

On 2018-04-16 13:26, Jo wrote:

> Here in Belgium, we have normal buses and longer ones, either can have 2 
> doors or 3 doors. There is no way of knowing which of those buses is going to 
> serve which stops at a given time. The only thing we do know for sure, is 
> that we are supposed to get on in front, except for wheelchairs and parents 
> with strollers. I fail to understand why stop_positions are considered to be 
> that important. Especially for buses. For trains I might understand, but even 
> there it's impossible to predict where exactly the doors will be when the 
> train stops. And it's not important, what matters is when there are zones on 
> the platforms, those we can map by splitting those platforms. 
> 
> Jo 
> 
> 2018-04-16 20:17 GMT+02:00 Ed Loach :
> 
>> Stephen wrote:
>>> If a consumer doesn't care about stop_position members, it's trivial
>>> to
>>> ignore them.  If the current spec says they're mandatory, then
>>> propose
>>> making them optional; I would support that.  I don't support
>>> prohibiting
>>> or removing them.
>> 
>> They are optional in the current spec. I don't bother with them in bus route 
>> relations as physically a bus has to stop on a relation member way close 
>> enough to the bus stop (platform) node for passengers to get on (with the 
>> exact stop position depending whether the particular bus has doors at front, 
>> middle or rear).
>> 
>> Ed
>> 
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-transit [1]
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit

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

Links:
--
[1] 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] Proposal for simplification of mapping public transport

[Jo]

The node doesn't describe the platform. The naming is unfortunate, but I
think we're stuck with it. The node represents the stop. What stop platform
way and stop_position node belongs together can be expressed using a
stop_area relation. Then it's needed only once. There is no need to do it
over and over again in the route relations.

If it's such a problem that mapped stop_positions are not in the route
relations, my next step (for Belgium at least) is to remove the ones that I
added from the OSM. The route relations I'm maintaining will continue to
have 1 object per stop.

Unfortunately, my colleague in Brussels read the wiki and he is adding
stop_position nodes everywhere and adding them to the route relations of
the STIB/MIVB operator. The consequence is that I won't be maintaining
those (not really a problem, as I wasn't doing that anyway), but those
stops are being used by the other 2 operators too, of course. And I won't
be able to remove those stop_position nodes AND I won't be adding them to
the route relations, so it becomes impossible to comply with what the wiki
'dictates' at present (it didn't just a few months ago).

What I mean by stability of the data is the following:

A mapper comes along and maps a bus stop on a node. Another mapper adds it
to some route relations. Then a mapper passes by and adds a way for the
platform, transferring all the tags and adding the way to the route
relations.

Then somebody read the wiki and adds a stop_position node as well and adds
this to all the route relations as well.

Lots of changes to the relations, no real change to the itineraries. If the
second mapper had simply added a highway=platform and maybe a stop_area
relation, the route relations would have remained stable.

Anyway, I'll keep going the way I like mapping PT and the rest of the world
can do it in more complex ways, each slightly different from the other,
depending on when they read the wiki. It's all fine. I'd like to see it
become simpler, more inclusive for everyone. Now most mappers simply say:
public transport I don't touch it. Tried to read the wiki, gave up. Let the
'specialists' handle it.

I'll continue working on PT_Assistant and of course I'll try to make it
work for simple and complex ways of mapping alike.

Polyglot

2018-04-16 20:51 GMT+02:00 Stephen Sprunk :

> Jo,
>
> IMHO, if a stop_position exists but isn't in a relation, consumers can't
> be sure which routes/platforms it applies to, and that means it's just
> clutter rather than useful data.  Given how many of them seem to be
> flat-out wrong, though, we definitely need to document it better--and make
> maybe it optional so mappers aren't forced to add something that they don't
> really understand.
>
> If there's a way/area for the platform, then IMHO one should not add a
> separate node for the platform; that is redundant.  If you need a single
> point for some purpose, you can just compute the centroid.  I don't see
> what "stability" has to do with it; once it's mapped, it's not going to
> change much over time unless the physical platform itself is changed, and
> one shouldn't expect stability in that case.  One can tag either just as
> easily too, so I don't understand that argument at all.
>
> When I map a building, I can make a node and put all the tags there, or I
> can make an area and put all the tags there.  Nobody expects a a way for
> the outline and a separate node inside it with all the tags--or more
> likely, a conflicting set of tags because some mappers didn't notice the
> redundancy.  Why should a platform be any different?
>
> S
>
>
> On 2018-04-16 13:20, Jo wrote:
>
> I knew this was going to be hard. Anyway, I made sure that it's definitely
> allowed to tag bus stops as platform nodes. Every few months I look at the
> wiki and each time it changes. At present it says that if a stop_position
> node is present for a bus stop, it has to be added to the route relations.
> I definitely don't agree with that and I won't do that. The route relations
> I'm creating only contain 1 object per stop. Having said that, I won't be
> removing stop_position nodes or platform ways from route relations, if they
> are already present. Unless this proposal passes somehow, then I will help
> with the conversion.
>
> My proposal does not say that it's not allowed or possible to map
> platforms as ways or areas.
>
> It only says that for stability of the data, it would be better to map all
> the detail tags on 1 node and only add that node to the route relations.
>
> If a platform is present, it's perfectly possible to tag it with
>
> highway=platform or railway=platform
> and optionally
> tactile_paving=yes
> wheelchair=yes/limited/no
>
> Jo
>
> 2018-04-16 19:17 GMT+02:00 Stephen Sprunk :
>
>> On 2018-04-16 08:11, Philip Barnes wrote:
>>
>>> On 16 April 2018 07:46:13 BST, Jo  wrote:
>>>
 Anyway, you're right in that the main point of my proposal is to get

Re: [Talk-transit] stop_position proposal

[Jo]

It's not a coincidence that there are few 'failures' in Belgium. Over the
years I added 70k of them and cleaned up the existing ones as I got along,
maybe 1k. As I chugged along, I didn't read the wiki every time it changed
and when I went to have a look in neighbouring countries, I noticed the
mapping was done differently there. Of course, now I am the one who is
doing things differently, but the way I see it, I'm doing it in as simple a
way as possible, while still complying with what matters of PT v2. Anyway,
I didn't feel like adding 140k objects, so there will be relatively few
stop_position nodes compared to the number of platform nodes. If you look
more closely at the data, you will find that platform ways are actually
mapped, where they exist. It's also not that I'm not mapping any
stop_position nodes. Where lines start/end and where a node is needed to
split the way anyway, I am mapping them consistently.

Polyglot

2018-04-16 19:50 GMT+02:00 Roland Olbricht :

> Dear all,
>
> there is another proposal, distinct from Polyglot's proposal that is in
> RFC since some days:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_
> stop_positions_and_platforms
>
> Before I tell a personal opinion, I would like to present some related
> facts. The basic idea is to look how the tags are actually used.
>
> Taginfo tells us
> http://taginfo.openstreetmap.org/keys/public_transport
> that there are more platform tags than stop_position tags
> and both are so many that you cannot reasonably view them all on a map.
>
> About two thirds of elements with public_transport=platform
> bear also highway=bus_stop
> https://taginfo.openstreetmap.org/tags/public_transport=plat
> form#combinations
> but there are at least more than 100'000 nodes (not ways, not relations,
> hence not fully mapped platforms) that are public_transport=platform but
> not highway=bus_stop.
>
> These are still too many to reasonably show them on a map (and to not talk
> what should happen about them). For you convenience, I have added a bbox
> limited request for those that you need to move to your area of interest:
> https://overpass-turbo.eu/s/xWI
> From my fist impression, most of them are simply not tagged with
> highway=bus_stop. However, the first hit in Rome is a tram stop that for a
> good reason is not tagged as highway=bus_stop.
>
> It is much less compelling to retag public_transport=stop_position as
> highway=bus_stop. Less than one third of them is tagged as
> https://taginfo.openstreetmap.org/tags/public_transport=stop
> _position#combinations
> And here, many belong to railways. Again, a bbox bounded query:
> https://overpass-turbo.eu/s/xWM
>
> Another matter are definitely wrong public_transport=stop_position,
> because they are off any highway, railway, or ferry. There is a surprsingly
> large number of them. I have made an area related request because we need
> the statistics in a moment:
> https://overpass-turbo.eu/s/xWF
>
> Running this request for Germany, France, Belgium, the Netherlands,
> Austria, and Switzerland shows that more than half of all global uses of
> stop_position are in these six countries (go to "Data", read the first
> entry). This is not an arbitrary selection - all these six countries have
> about 1000 to 2000 stop_positions per million inhabitants, but for
> comparision UK has only 150 stop_positions per inhabitant.
>
> However, the number of failures are significant, between 5% and 10% (with
> the exception of Belgium). The uneven distribution suggest that these
> relates to specific users, but the total number of users is more than 500,
> suggesting that there is a problem to explain the difference between
> stop_position and platform.
>
> All in all, I do agree that there is definitely room for the improvement
> of public transport mapping. But making the tagging of 500'000 nodes
> deprecated and neglecting both problems with that and the more presseing
> problems is probably not a good way to go forward. Given that Ilya refuses
> for unknown reasons to read this mailing list, please discuss the matter on
> the discussion page if he wiki page.
>
> Best regards,
>
> Roland
>
> ___
> 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] Proposal for simplification of mapping public transport

[Jo]

Here in Belgium, we have normal buses and longer ones, either can have 2
doors or 3 doors. There is no way of knowing which of those buses is going
to serve which stops at a given time. The only thing we do know for sure,
is that we are supposed to get on in front, except for wheelchairs and
parents with strollers. I fail to understand why stop_positions are
considered to be that important. Especially for buses. For trains I might
understand, but even there it's impossible to predict where exactly the
doors will be when the train stops. And it's not important, what matters is
when there are zones on the platforms, those we can map by splitting those
platforms.

Jo

2018-04-16 20:17 GMT+02:00 Ed Loach :

> Stephen wrote:
> > If a consumer doesn't care about stop_position members, it's trivial
> > to
> > ignore them.  If the current spec says they're mandatory, then
> > propose
> > making them optional; I would support that.  I don't support
> > prohibiting
> > or removing them.
>
> They are optional in the current spec. I don't bother with them in bus
> route relations as physically a bus has to stop on a relation member way
> close enough to the bus stop (platform) node for passengers to get on (with
> the exact stop position depending whether the particular bus has doors at
> front, middle or rear).
>
> Ed
>
>
> ___
> 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] Proposal for simplification of mapping public transport

[Jo]

I knew this was going to be hard. Anyway, I made sure that it's definitely
allowed to tag bus stops as platform nodes. Every few months I look at the
wiki and each time it changes. At present it says that if a stop_position
node is present for a bus stop, it has to be added to the route relations.
I definitely don't agree with that and I won't do that. The route relations
I'm creating only contain 1 object per stop. Having said that, I won't be
removing stop_position nodes or platform ways from route relations, if they
are already present. Unless this proposal passes somehow, then I will help
with the conversion.

My proposal does not say that it's not allowed or possible to map platforms
as ways or areas.

It only says that for stability of the data, it would be better to map all
the detail tags on 1 node and only add that node to the route relations.

If a platform is present, it's perfectly possible to tag it with

highway=platform or railway=platform
and optionally
tactile_paving=yes
wheelchair=yes/limited/no

Jo

2018-04-16 19:17 GMT+02:00 Stephen Sprunk :

> On 2018-04-16 08:11, Philip Barnes wrote:
>
>> On 16 April 2018 07:46:13 BST, Jo  wrote:
>>
>>> Anyway, you're right in that the main point of my proposal is to get
>>> people to add 1 object per stop to the route relations.
>>>
>>
>> I think this is a good idea for bus routes as they are quite simple.
>> There is a sign, the passengers wait thereabouts, the bus stops so the
>> door is at this point and the passengers can then board, pay or show
>> their pass to the driver. Making this too complicated will deter
>> mappers from adding public transport.
>>
>> If mappers want to add additional information then they should be free
>> to do so but it should not be compulsory.
>>
>
> To me, this is the crux of the debate.  If mappers have put in additional
> data or detail that you don't care about, then you should ignore it rather
> than remove it (or demand that they do so), because some other consumer may
> want that additional data.  Ignoring data that is present but not needed is
> always easier and more reliable than trying to deduce data that is needed
> but not present.
>
> If a consumer doesn't care about stop_position members, it's trivial to
> ignore them.  If the current spec says they're mandatory, then propose
> making them optional; I would support that.  I don't support prohibiting or
> removing them.
>
> If a consumer only wants a node for the platform but it's mapped as a
> way/area, then it's trivial to detect that and compute the centroid.  I
> don't support replacing existing ways/areas with nodes or prohibiting new
> ways/areas in the future.  If the current spec says they must be
> ways/areas, then propose making nodes allowed too; I thought that was
> already the case, but if not, I would support fixing that.
>
> 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] Proposal for simplification of mapping public transport

[Ed Loach]

Stephen wrote:
> If a consumer doesn't care about stop_position members, it's trivial
> to
> ignore them.  If the current spec says they're mandatory, then
> propose
> making them optional; I would support that.  I don't support
> prohibiting
> or removing them.

They are optional in the current spec. I don't bother with them in bus route 
relations as physically a bus has to stop on a relation member way close enough 
to the bus stop (platform) node for passengers to get on (with the exact stop 
position depending whether the particular bus has doors at front, middle or 
rear).

Ed


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

[Talk-transit] stop_position proposal

[Roland Olbricht]

Dear all,

there is another proposal, distinct from Polyglot's proposal that is in 
RFC since some days:

https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms

Before I tell a personal opinion, I would like to present some related 
facts. The basic idea is to look how the tags are actually used.


Taginfo tells us
http://taginfo.openstreetmap.org/keys/public_transport
that there are more platform tags than stop_position tags
and both are so many that you cannot reasonably view them all on a map.

About two thirds of elements with public_transport=platform
bear also highway=bus_stop
https://taginfo.openstreetmap.org/tags/public_transport=platform#combinations
but there are at least more than 100'000 nodes (not ways, not relations, 
hence not fully mapped platforms) that are public_transport=platform but 
not highway=bus_stop.


These are still too many to reasonably show them on a map (and to not 
talk what should happen about them). For you convenience, I have added a 
bbox limited request for those that you need to move to your area of 
interest:

https://overpass-turbo.eu/s/xWI
From my fist impression, most of them are simply not tagged with 
highway=bus_stop. However, the first hit in Rome is a tram stop that for 
a good reason is not tagged as highway=bus_stop.


It is much less compelling to retag public_transport=stop_position as 
highway=bus_stop. Less than one third of them is tagged as

https://taginfo.openstreetmap.org/tags/public_transport=stop_position#combinations
And here, many belong to railways. Again, a bbox bounded query:
https://overpass-turbo.eu/s/xWM

Another matter are definitely wrong public_transport=stop_position, 
because they are off any highway, railway, or ferry. There is a 
surprsingly large number of them. I have made an area related request 
because we need the statistics in a moment:

https://overpass-turbo.eu/s/xWF

Running this request for Germany, France, Belgium, the Netherlands, 
Austria, and Switzerland shows that more than half of all global uses of 
stop_position are in these six countries (go to "Data", read the first 
entry). This is not an arbitrary selection - all these six countries 
have about 1000 to 2000 stop_positions per million inhabitants, but for 
comparision UK has only 150 stop_positions per inhabitant.


However, the number of failures are significant, between 5% and 10% 
(with the exception of Belgium). The uneven distribution suggest that 
these relates to specific users, but the total number of users is more 
than 500, suggesting that there is a problem to explain the difference 
between stop_position and platform.


All in all, I do agree that there is definitely room for the improvement 
of public transport mapping. But making the tagging of 500'000 nodes 
deprecated and neglecting both problems with that and the more presseing 
problems is probably not a good way to go forward. Given that Ilya 
refuses for unknown reasons to read this mailing list, please discuss 
the matter on the discussion page if he wiki page.


Best regards,

Roland

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

Re: [Talk-transit] Proposal for simplification of mapping public transport

[Stephen Sprunk]

On 2018-04-16 08:11, Philip Barnes wrote:

On 16 April 2018 07:46:13 BST, Jo  wrote:

Anyway, you're right in that the main point of my proposal is to get
people to add 1 object per stop to the route relations.


I think this is a good idea for bus routes as they are quite simple.
There is a sign, the passengers wait thereabouts, the bus stops so the
door is at this point and the passengers can then board, pay or show
their pass to the driver. Making this too complicated will deter
mappers from adding public transport.

If mappers want to add additional information then they should be free
to do so but it should not be compulsory.


To me, this is the crux of the debate.  If mappers have put in 
additional data or detail that you don't care about, then you should 
ignore it rather than remove it (or demand that they do so), because 
some other consumer may want that additional data.  Ignoring data that 
is present but not needed is always easier and more reliable than trying 
to deduce data that is needed but not present.


If a consumer doesn't care about stop_position members, it's trivial to 
ignore them.  If the current spec says they're mandatory, then propose 
making them optional; I would support that.  I don't support prohibiting 
or removing them.


If a consumer only wants a node for the platform but it's mapped as a 
way/area, then it's trivial to detect that and compute the centroid.  I 
don't support replacing existing ways/areas with nodes or prohibiting 
new ways/areas in the future.  If the current spec says they must be 
ways/areas, then propose making nodes allowed too; I thought that was 
already the case, but if not, I would support fixing that.


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] Proposal for simplification of mapping public transport

[Philip Barnes]

On 16 April 2018 07:46:13 BST, Jo  wrote:


>
>What I hear quite often in railway stations is: don't use the last
>three
>'cars' if you want to get off in minor station such and so. I almost
>never
>hear them say, get on the train in zone A-E, but I think it is written
>on
>the tickets sometimes, in case people have made reservations for
>specific
>seats.
Virgin West Coast use this system, there are a series of yellow numbers painted 
along the platform so that you will be in the right place for your carriage. 

>
>Anyway, you're right in that the main point of my proposal is to get
>people
>to add 1 object per stop to the route relations. 

I think this is a good idea for bus routes as they are quite simple. There is a 
sign, the passengers wait thereabouts, the bus stops so the door is at this 
point and the passengers can then board, pay or show their pass to the driver. 
Making this too complicated will deter mappers from adding public transport. 

If mappers want to add additional information then they should be free to do so 
but it should not be compulsory. 

I understand in big cities, such as that there London and in those places a 
more complex tagging is needed if for example a bus has multiple doors that are 
not at the front. 

Railway or tram platforms are large, dedicated areas and should be mapped as 
ways.

Phil (trigpoint) 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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