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

Jo winfixit at gmail.com
Tue May 14 14:07:48 UTC 2019

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

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

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


On Tue, May 14, 2019 at 3:50 PM DC Viennablog <emergency99 at outlook.com>

> @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 <winfixit at gmail.com>
> *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 <selfishseahorse at gmail.com> wrote:
> On Tue, 14 May 2019 at 12:31, Dave F via Talk-transit
> <talk-transit at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20190514/4ca3c8a1/attachment-0001.html>

More information about the Talk-transit mailing list