[Tagging] Tram tracks running in a road

Michael Reichert nakaner at gmx.net
Sat Feb 7 09:56:53 UTC 2015

Hi Luca,

Am 2015-02-06 um 17:29 schrieb Luca Sigfrido Percich:
> first time I write to the list (after lurking for a while), so I introduce
> myself. I am from Milano - Italy, I work for the municipality's agency for
> environment and mobility, and we'we been working for the last months to
> integrate our road graph with OSM.
> Currently in Milano all tram tracks are mapped separately, so they are all
> oneway and no way has both highway=* and railway=tram tags (apart from some
> cases we're correcting).

Thats right. Tram tracks and the street ways should be to different ways
(may share the nodes in some cases) because we have a couple of tags in
OSM which are used for railway and road infrastructure (e.g. maxspeed=*).

Here some examples how to map if

(1) tram tracks totally separated from car traffic:

(2) tram tracks share space with cars, only a white line between the two

(3) tram tracks share space with cars and there is only one tram track
which is located in the middle of the street

> Now, we would like to store the information wether a certain rTailway track
> runs in a road sharing the same space with motor vehicles.

You do not need to change current tram mapping [1] to do this. Take a
GIS of your choice, import OSM data, calculate buffers around tram
tracks and street ways and intersect them. Tram track buffer should be a
little bit wider than the used structure gauge [2]. Ask your local tram
operating company which structure gauge is used on which tram line (it
may differ between older and newer lines) if it is not mapped yet
(structure_gauge=* or loading_gauge=* [5]).

Calculating buffers around streets is a little bit more difficult. You
have to check how wide the street is. Check following tags to do this:
- oneway=* (i.e. one OSM ways per driving direction or one way for both
- number of lanes (lanes=*)
- mapping offset (placement=*, see [3] and [4])
- width=* (you can measure width=* from aerial images)
- if lanes=* and width=* is not tagged, you can estimate the width by
  road classification (highway=primary is often wider than
  highway=tertiary) or add map it yourself

If you want to improve OSM you can add landuse=railway where tram does
not share the space with cars and use landuse=railway areas in your
buffer calculation/intersecting

> I am referring to situations similar to this one:
> http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg
> Which is here on the map:
> https://www.openstreetmap.org/#map=19/45.470987/9.236118
> I searched the wiki for a tagging or relation scheme, but found none.
> I was thinking about a simple tagging scheme: tram=yes|forward|backward for
> the highway, and road=yes for the railway.

There is one disadvantage. If I (or someone else) edit the tram tracks
there (e.g. because the have been removed or separated from car lanes),
I won't look at the neighbouring street way because trams tracks already
have been mapped separately. Don't map things which can be derived by
spatial queries (see above).

> From the previous example (the picture points at the opposite direction of
> the highway on which it was taken:
> For the center way (road):
> tram=yes (it's on both directions)

A mapper who has not read this discussion maybe think that tram=yes is
an access tag (in some countries, e.g. Germany, trams have to observe
(car) traffic signs because trams are considered as normal street
traffic by law) and remove it because it is not necessary (see the
access tagging hierarchy at OSM wiki).

> and on the two railways:
> road=yes (the track lies on a road used by motor vehicles)
> We could also user a lanes modifier:
> lanes=3
> lanes:backward=2
> tram:lanes:backward=yes|no
> tram:forward=yes

Tagging this can be useful if someone wants to render a lane diagram.
Maybe you can use these tags in your GIS, too.

> The tram tag should not be used for tracks which run separated from the
> road (they are tagged with railway=tram).
> The tram tag should go along with access tags, as we have lanes reserved
> for trams and buses/taxis:
> http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg
> So the center way (carriageway reserved to psv with two tram tracks in
> shared space) would get tagged as:
> access=no
> bus=yes
> taxi=yes
> tram=yes
> We could also think about a relation, type=tram_on_road, it could be useful
> for sorting things out in complex multi-carriageway situations like this
> one:
> https://www.openstreetmap.org/#map=19/45.49833/9.19607
> but would also be more difficult for users to mantain and for clients to
> consume.

Maintaining is the main problem of street relations. A mapper who edits
this area has to notice that there is a relation. An iD mapper (it may,
but not has to be a newbie) won't notice the relation. And even JOSM
users won't notice it as long as they do not delete anything. Street
relations are a collective relation which always have problems to be
complete (user often do not add new items to collective relations
because they do not know of the existence of collective relations).

Relations should not be created at OSM if their content/result could
also be obtained by running spatial queries (we do not creat a relation
type=collective name=supermarkets in Milano).

My solution (adding lanes=* + placement=*) would work. If all is mapped
right (it seems to be so), buffers of tram and streets won't intersect,
i.e. tram tracks do not share space with cars (apart from crossings). At
crossings tram and street buffers would intersect. You have to calculate
crossing angle at this positions (or check if the two OSM ways are
connected, maybe add railway=level_crossing on the crossing node).

Best regards

(a railway enthusiast and railway mapper)

[1] https://www.openstreetmap.org/#map=19/45.47099/9.22747
[2] https://en.wikipedia.org/wiki/Structure_gauge
[3] https://wiki.openstreetmap.org/wiki/Proposed_features/placement
[4] https://www.openstreetmap.org/way/255832226/history
[5] https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging#Tracks

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150207/9112c437/attachment-0001.sig>

More information about the Tagging mailing list