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

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

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

[Roland Olbricht]

Hi Polyglot,


https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_map_all_stops_as_nodes
I do agree that it would be easier for everyone to have one and only one 
member on the line relation per actual stop.


However, trains and sometimes also trams can have a significant length. 
Walking the full length of a train can take as long as 7 or 8 minutes. 
There are applications that send people before stepping on the train to 
the right section to have a shortest possible walk after getting off 
(search for e.g. "london tube exit routing", no link here to not 
advertise a specific one).


We render OSM useless for such applications if we force people towards 
adding fictitious nodes for trains. Please note that an easy approach 
like adding a node at the front position of the train does not bail out 
us because there are platforms that are called at in both directions of 
travel. In such cases, also the middle position of a train may vary.


Therefore I suggest to drop the node requirement and keep up the 
requirement to have only one object per stop.


A second thing for simplication: I suggest to require always a "name" 
tag on the member object or multiple "name:XX" tags if there is no 
preferred name in a multilingual setting. This way we could safely 
ignore relations for stop related objects.


When writing both a plugin for JOSM and the display tool
https://overpass-api.de/public_transport.html
it was the most frustrating part to go on a quest to find the 
appplicable name if people had hidden it in some special relation, 
including scores of new possible kinds of error if one has no or 
multiple names from multiple stop_area relations and so on. This was the 
main reason to discontinue the development.


I consider to write a proposal for the "name" requirement. Would it make 
more sense for you to instead include that in your proposal, i.e. add 
the requirement for the member object to have a "name" or multiple 
"name:XX" tags?


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

[Jo]

A few years ago it was meant as a way to comply with the PT v2 scheme. For
me a nice side effect is/was that JOSM assigns a platform role
automatically when adding them to route and stop_area relations. But it
wouldn't be hard to reprogram it to do that for simply
highway=bus_stop/railway=tram_stop.

Dropping the public_transport tags on stops is covered by Ilya's proposal
though. I'm somewhat indifferent to whether we do or don't drop those tags.

My proposal is mostly about not adding 2 objects to the route relations for
each stop and to keep all the stop's details together on that one object
that is added to the route relations, preferably a node.

Polyglot

2018-04-13 19:48 GMT+02:00 Selfish Seahorse :

> On 11 April 2018 at 19:38, Roland Hieber  wrote:
> > However, a main reason why the Public Transport schema was adopted [1]
> > was exactly this differentiation between stop position on the route and
> > platform position/waiting area for the passengers.  This was done to
> > increase the expressiveness of OpenStreeMap data, and to make
> > information more easier obtainable for routing software.  After all, the
> > two things are at different positions, and you cannot generally infer
> > the one from the other.  Reverting to the old schema would therefore
> > take away that expressiveness.
> >
> > [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/
> Public_Transport#Goal_of_this_public_transport_proposal
>
> If the waiting area is mapped as a node, it can be projected on the
> road or rail, thus making a separate stop position node on the road or
> rail unnecessary.
>
> However, I think it is not very straightforward that this node is
> proposed to be tagged public_transport=platform and a possible
> physical platform highway=platform. In my opinion, tagging the waiting
> area node only highway=bus_stop or railway=tram_stop would be much
> less confusing. Besides these tags are self-explanatory. (And, as you
> wrote, these tags will probably remain needed for rendering purposes
> for a long time to come. Why double tagging then?)
>
> ___
> 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

[Selfish Seahorse]

On 11 April 2018 at 19:38, Roland Hieber  wrote:
> However, a main reason why the Public Transport schema was adopted [1]
> was exactly this differentiation between stop position on the route and
> platform position/waiting area for the passengers.  This was done to
> increase the expressiveness of OpenStreeMap data, and to make
> information more easier obtainable for routing software.  After all, the
> two things are at different positions, and you cannot generally infer
> the one from the other.  Reverting to the old schema would therefore
> take away that expressiveness.
>
> [1]: 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Goal_of_this_public_transport_proposal

If the waiting area is mapped as a node, it can be projected on the
road or rail, thus making a separate stop position node on the road or
rail unnecessary.

However, I think it is not very straightforward that this node is
proposed to be tagged public_transport=platform and a possible
physical platform highway=platform. In my opinion, tagging the waiting
area node only highway=bus_stop or railway=tram_stop would be much
less confusing. Besides these tags are self-explanatory. (And, as you
wrote, these tags will probably remain needed for rendering purposes
for a long time to come. Why double tagging then?)

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

Mapping stop_position nodes is just fine. I would simply not add them to
the route relations.

Mapping platforms as ways or areas adds enhances detail. But no need to add
them to the route relations.

The proposal is about having 1 object to represent the stops for its whole
lifetime and nodes happen to be the most suitable kind of object for this.

Add all the pertinent details to this object and only add this object to
the route relations, once each time the vehicle serves it for that
particular itinerary variation. (route relation)

I've been using this scheme in Belgium, a country with 3-4 PT operators for
several years now and it works really well. I knew it was going to be hard
to propose a change, that for some is somewhat radical.

It does not mean that we're reverting back to PT "v1" though. Everything
can still be expressed in as much detail as needed or wanted. But to
enhance the detail during the lifetime of the stop, it won't be needed to
transfer tags from one object to another, or to replace objects in the
route relations.

We need a scheme that is easy to maintain by anybody and what I see
happening in Germany mostly, but also elsewhere around Europe, based on
what is described in the wiki is overly complex, thus making it only for
"experts", and we don't have enough of those.

Polyglot

2018-04-11 19:38 GMT+02:00 Roland Hieber :

> On Mon, Apr 09, 2018 at 07:19:32PM +0200, Jo wrote:
> > Here goes my proposal for a reform in mapping public transport:
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/
> Public_Transport_map_all_stops_as_nodes
> [...]
>
> As I understand it, in Public Transport schema speech, this proposal
> comes down to removing all public_transport=stop_position nodes (i.e.
> the position where a train/bus/… stops on the street) from the route
> relations, and retaining the public_transport=platform information
> (i.e. where the passengers wait or where the station pole is located).
> This would be effectively reverting part of the Public Transport schema,
> and going back to the way platforms were mapped previously.
>
> However, a main reason why the Public Transport schema was adopted [1]
> was exactly this differentiation between stop position on the route and
> platform position/waiting area for the passengers.  This was done to
> increase the expressiveness of OpenStreeMap data, and to make
> information more easier obtainable for routing software.  After all, the
> two things are at different positions, and you cannot generally infer
> the one from the other.  Reverting to the old schema would therefore
> take away that expressiveness.
>
> [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/
> Public_Transport#Goal_of_this_public_transport_proposal
>
> Furthermore, quoting from the proposal:
>
> > Rationale
> >
> > - nodes are convenient to work with and move, if needed, also using
> >   mobile apps
>
> This is true, but per the Public Transport schema you can already map
> both public_transport=stop_position and public_transport=platform as
> single nodes.  Your additional argument that both a node and a way could
> be added for the platform would not lead to more expressiveness, but
> only to more duplication of data.  (As simple as possible, as complex as
> necessary.)
>
> > - nodes have coordinates directly, no extra calculation required
> > - nodes are easy to work with using MapCSS, [...]
>
> See above.  Also, every way consists of nodes, which have a coordinates.
> Just take any.
>
> > - making comparison of location and tags with external sources is
> >   straightforward
>
> I don't know how this is meant, but the complexity of tag extraction
> from objects will be the same whether they are mapped on a node or
> mapped on a way.  Also the main work here is probably to match the
> external database schema to the OpenStreetMap data schema, as they will
> most probably not be very similar.
>
> That's all I can think of for now.
>
>  - 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

[Roland Hieber]

On Mon, Apr 09, 2018 at 07:19:32PM +0200, Jo wrote:
> Here goes my proposal for a reform in mapping public transport:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_map_all_stops_as_nodes
[...]

As I understand it, in Public Transport schema speech, this proposal
comes down to removing all public_transport=stop_position nodes (i.e.
the position where a train/bus/… stops on the street) from the route
relations, and retaining the public_transport=platform information
(i.e. where the passengers wait or where the station pole is located).
This would be effectively reverting part of the Public Transport schema,
and going back to the way platforms were mapped previously.

However, a main reason why the Public Transport schema was adopted [1]
was exactly this differentiation between stop position on the route and
platform position/waiting area for the passengers.  This was done to
increase the expressiveness of OpenStreeMap data, and to make
information more easier obtainable for routing software.  After all, the
two things are at different positions, and you cannot generally infer
the one from the other.  Reverting to the old schema would therefore
take away that expressiveness.

[1]: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Goal_of_this_public_transport_proposal

Furthermore, quoting from the proposal:

> Rationale
>
> - nodes are convenient to work with and move, if needed, also using
>   mobile apps

This is true, but per the Public Transport schema you can already map
both public_transport=stop_position and public_transport=platform as
single nodes.  Your additional argument that both a node and a way could
be added for the platform would not lead to more expressiveness, but
only to more duplication of data.  (As simple as possible, as complex as
necessary.)

> - nodes have coordinates directly, no extra calculation required
> - nodes are easy to work with using MapCSS, [...]

See above.  Also, every way consists of nodes, which have a coordinates.
Just take any.

> - making comparison of location and tags with external sources is
>   straightforward

I don't know how this is meant, but the complexity of tag extraction
from objects will be the same whether they are mapped on a node or
mapped on a way.  Also the main work here is probably to match the
external database schema to the OpenStreetMap data schema, as they will
most probably not be very similar.

That's all I can think of for now.

 - 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

[Jo]

2018-04-10 16:23 GMT+02:00 Stephen Sprunk :

> But for the thousands of platform ways/areas that do already exist, you're
> proposing that someone has to go back and add nodes, move all the tags
> over, change which is the relation member, etc.?  That's not very friendly.
>
You can rest assured that if the proposal happens to make it, I'll make
sure there are tools to help with that conversion. Compared to the
thousands upon thousands of stops and route relations that still need to be
mapped, their number is relatively small.

Polyglot
___
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 proposal doesn't say that it's not possible to map the actual platforms
as ways or areas in ADDITION to that node, if they are actually present.

What it says is that it's not necessary to transfer all the details from
the node to the way/area and replace the node in the route relations.

The node REPRESENTING the stop keeps fulfilling this function for the
lifetime of the stop's 'existence'.

Jo



2018-04-10 2:43 GMT+02:00 Bill Ricker :

> On Mon, Apr 9, 2018 at 1:19 PM, Jo  wrote:
> > Here goes my proposal for a reform in mapping public transport:
>
> [nodes not platforms]
>
> If this applies to Heavy Rail and Light Rail rapid transit and not
> just Bus Stops, I object.
>
> The Transport layer on OpenStreetMap is much more useful at high zoom
> levels with Platform entities in the DB than it would be without them.
>
> From
> https://www.openstreetmap.org/query?lat=42.34752=-71.
> 09989#map=18/42.34678/-71.09936=T
> one can see that the two lines do NOT share a platform so that one can
> not change directions with a wheelchair without taking two elevators,
> either of which may be out of service; but if there was only one
> platform between two lines, one could.
> THIS IS USEFUL TO MAP.
>
> I support simplicity, but agree with Einstein: Things should be as
> simple as possible, but not simpler. This proposal goes too far.
>
>
> --
> Bill Ricker
> bill.n1...@gmail.com
> https://www.linkedin.com/in/n1vux
>
___
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

[Bill Ricker]

On Mon, Apr 9, 2018 at 1:19 PM, Jo  wrote:
> Here goes my proposal for a reform in mapping public transport:

[nodes not platforms]

If this applies to Heavy Rail and Light Rail rapid transit and not
just Bus Stops, I object.

The Transport layer on OpenStreetMap is much more useful at high zoom
levels with Platform entities in the DB than it would be without them.

From
https://www.openstreetmap.org/query?lat=42.34752=-71.09989#map=18/42.34678/-71.09936=T
one can see that the two lines do NOT share a platform so that one can
not change directions with a wheelchair without taking two elevators,
either of which may be out of service; but if there was only one
platform between two lines, one could.
THIS IS USEFUL TO MAP.

I support simplicity, but agree with Einstein: Things should be as
simple as possible, but not simpler. This proposal goes too far.


-- 
Bill Ricker
bill.n1...@gmail.com
https://www.linkedin.com/in/n1vux

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