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

DC Viennablog emergency99 at outlook.com
Thu May 9 19:46:02 UTC 2019

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

RobinD. (emergency99)
Von: Jo <winfixit at gmail.com>
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 for subway and maybe even for train, but I never actually got around to mapping train infrastructure, the 70000 bus and tram stops were enough to keep me busy.


On Thu, May 9, 2019 at 1:19 PM Dave F via Talk-transit <talk-transit at openstreetmap.org<mailto:talk-transit at 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


Talk-transit mailing list
Talk-transit at openstreetmap.org<mailto:Talk-transit at openstreetmap.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20190509/6c5e12ad/attachment-0001.html>

More information about the Talk-transit mailing list