[Talk-transit] Summary of Public Transport Proposal Criticism -> a real example from Zürich

Michael von Glasow michael at vonglasow.com
Wed Feb 2 23:10:42 GMT 2011

On 02/02/2011 04:13 PM, Richard Mann wrote:
> On Wed, Feb 2, 2011 at 12:12 PM, Michał Borsuk<michal.borsuk at gmail.com>  wrote:
>> On 01/27/2011 06:56 PM, ant wrote:
>>>> 3) Whether there should be a new public_transport key, to try to
>>>> clarify the bus_stop/tram_stop distinction
>>>> a) aim to move tram_stops to alongside the track, and put something
>>>> else (tram_stop_group / tram_station?) on the track
>>>> b) aim to move bus_stops onto the road, and put something else
>>>> (platform?) alongside
>>>> c) encourage the use of platforms on tram systems, and use those in
>>>> the relation instead of tram_stop
>>>> d) add a new public_transport key, so that public_transport=platform
>>>> can be used for everything
>>> c and d (we shouldn't redefine tags that are in million-times use!)
>> c. with pole *or* platform. Ideally there would be some degree of
>> compatibility between tram stops and bus stops, i.e. a pair of tags on each
>> side that are at least compatible to a degree.
> If you do this, the line-diagram code won't work, and no-one seems to
> know how to fix it. For the code to work, you apparently need to use
> railway=tram_stop nodes as members of the relation with role=stop.
> Unless it can be fixed, I'd probably go for (a). The tool is too
> useful to ignore.
+0.5: If I got the history of OSM correctly, it was once common to put 
bus stops on the way, and at some point it was changed; hence I would 
expect that to work for tram stops as well. I consider that unlikely to 
break any application in use today - and if it does, that application 
most likely has a solution for bus stops, which I expect could easily be 
applied to tram stops. So far I agree.

I don't quite agree about placing something else on the track: The 
position on the track can be determined with standard GIS functions: 
take the stop, find the way with the lowest ST_Distance(stop,way), then 
for that way do ST_Line_Locate_Point(way,stop). Wrap that into 
ST_Line_Interpolate_Point to get a POINT geometry representing the stop 
on the way.

Hence, in most cases the extra node on the way is what I call courtesy 
tagging - it makes things easier for the renderer (less preprocessing) 
but can be automated. I would tend towards manual tagging only in those 
cases in which heuristics are likely to produce incorrect or 
unpredictable results (e.g. bus stop in the middle between two 

For the remaining cases - maybe someone comes up with a standard OSM 
preprocessor which can be run against a database and adds these courtesy 
tags where they are not present yet - or, even better, offers a 
preprocessed planet.osm with all these courtesy tags applied. I guess 
that would calm down the discussion about the necessity of certain tags: 
we would still need to define them, but in most cases they would get 
applied by a preprocessor running over the raw OSM data. Enough OT for 


More information about the Talk-transit mailing list