[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 <lists at rohieb.name>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20180411/68bf7cb2/attachment.html>