[Tagging] Feature Proposal - RFC - More Consistency in Railway Tagging

Jo winfixit at gmail.com
Sat Apr 13 21:16:50 UTC 2013

FWIW I also prefer one way per track. When the tracks are embedded in the
tarmac of a normal 2 way street, I'll draw 3 ways (2 railways and 1
highway), each with the name included. When I bother to add
associatedStreet relations I'd add all of them into it.
When it's 1 track on a one way street (or half a dual carriage road), I'd
be inclined to simply add a railway=tram to the highway=...
But usually the tracks happen to be in the middle between the carriage
roads in that case, so 4 ways. If buses also us this middle part, this may
mean an additional 5th highway=service could be added. Although I'm usually
simply adding highway=service, psv=yes to both of those railways.
Technically the bus could overtake another bus or a tram, but that seems
like an unwise thing to do, unless it's defective. Maybe I'll start adding
that 5th way...

Anyway, the tendency is towards mapping more detail, not less, so mapping
tracks as separate ways makes the most sense to me, especially since aerial
imagery allows us to see the actual tracks. I certainly prefer that over
breaking trams by having them take 90 degrees turns.


2013/4/13 David Fisher <djfisher81 at gmail.com>

> Sorry, yes, "one way per track", of course.  Was writing hurriedly.
> Thanks,
> David.
> On Sat, Apr 13, 2013 at 9:06 PM, John F. Eldredge <john at jfeldredge.com>wrote:
>> David Fisher <djfisher81 at gmail.com> wrote:
>>> > Croydon Tramlink is one counter-example, and I'd concede that someone
>>> has done great work in accurately mapping the path of it that I wouldn't
>>> want
>>> > to destroy, but it is sadly completely disconnected from the highway
>>> network, and that is what I'd like to address.
>>> As a Croydon mapper myself who has made changes to the tramlink
>>> network... firstly thanks for noticing that it looks OK!  It's by no means
>>> all my own work, but I like to think I've done my bit :)   There's actually
>>> only one stretch which is relevant to this debate: the Addiscombe Road
>>> section between East Croydon and Sandilands (I presume it is this
>>> section you refer to when you say "completely disconnected from the highway
>>> network"?).  All the other on-highway parts are only single-track, so
>>> are easily represented by a single way with nodes merged with the highway.
>>> Anyway.  My two cents, for what it's worth:  I am strongly in favour of
>>> mapping highways and railways differently (one way per separated piece of
>>> tarmac for roads; one way per rail for railways).  One form of compromise,
>>> however, could be to treat specifically on-highway rail systems with the
>>> "highway" protocol.  Or, maybe for multi-rail on-highway sections, map them
>>> as separate ways (cf Addiscombe Road tramlink) and use a relation just to
>>> cover these sections?  I realise this is not ideal for cities with a large
>>> proportion of such sections, but long-term it may be a way to maintain
>>> detail whilst limiting complexity (since relations would not be needed for
>>> *every* section, just shared sections).
>>> Cheers,
>>> David Fisher.
>>> On Sat, Apr 13, 2013 at 7:11 PM, Martin Atkins <mart at degeneration.co.uk>wrote:
>>>> On 04/13/2013 10:18 AM, Rovastar wrote:
>>>>> Martin,
>>>>> The example you gave for tunnels and bridges are the same for roads as
>>>>> well.
>>>>> If you have a bridge or tunnel with 2 roads (one for each one-way) and
>>>>> a
>>>>> train line(s) and footpath each will be a tagged with a separate
>>>>> bridge. So
>>>>> in that regard rail is actually are consistent with the road network.
>>>> Point taken: it is a general problem with bridge tagging, not one with
>>>> railway tagging. I found some discussions on the wiki about modelling
>>>> bridges as areas that would address this, but I don't really have any
>>>> interest in mapping bridges in particular, so example retracted for the
>>>> purpose of this discussion.
>>>>  Also you say you want it better for simple mapping and other can do
>>>>> more
>>>>> detailed mapping if they want to. I see no part of your proposal to add
>>>>> additional tracks like is now yet you imply in the posts here that it
>>>>> is. If
>>>>> you do think this then it doesn't not help the crossing example you
>>>>> gave as
>>>>> we will have the same problem again.
>>>> I have not described a way to describe the actual routes of tracks; I
>>>> lack the expertise (or interest, frankly) to describe that next level of
>>>> detail, I just propose that we separate that next level of detail from this
>>>> simpler level of detail, rather than using the same tags for both.
>>>> I've seen the area:highway proposal for mapping the detailed shape of
>>>> streets, sidewalks and footways. My assumption was that this proposal could
>>>> be extrapolated to include a similar model for railways, modeling the
>>>> precise shapes of the trackbed the rails run along, the positions of the
>>>> individual tracks within that trackbed, etc.
>>>> If I were trying to define such a thing my first thought would be to
>>>> define a new way tag to mean "the exact path of a track" and use separate
>>>> ways from the simple route network. e.g. railway:track=rail . I've not
>>>> spent nearly as much time pulling that idea apart as I have my simple
>>>> route-oriented proposal, so I'm sure someone who knows more about railways
>>>> than I do could find examples where that doesn't apply, but it's a strawman
>>>> to start with.
>>>> I could also compromise on making the schematic network be the thing
>>>> that gets new tags, but I think it's tough to say whether it's better to
>>>> suggest re-tagging detail work in dense areas where there are evidently
>>>> lots of avid mappers at work (and the re-tagging could thus happen
>>>> relatively quickly), or to suggest re-tagging the basic network in areas
>>>> where there is less detail and there are fewer (or no) active mappers.
>>>>  Do you propose that we change *all* the currently mapped multi track
>>>>> rails
>>>>> to conform to your new standard?
>>>>> e.g. here there are hundreds of tracks/railways which IMHO accurately
>>>>> reflects what is on the ground.
>>>>> http://www.openstreetmap.org/?**lat=51.47119&lon=-0.14847&**
>>>>> zoom=15&layers=M<http://www.openstreetmap.org/?lat=51.47119&lon=-0.14847&zoom=15&layers=M>
>>>> Under my proposal it wouldn't do any harm to leave existing detailed
>>>> tagging in place where the railway doesn't cross the highway, since a
>>>> railway way represents "one or more tracks", and that holds for the example
>>>> you showed. Optionally one could add tracks=1 to the existing ways to make
>>>> it very clear.
>>>> The converse is not true: if you define that a railway way represents
>>>> exactly one track, then there's lots of work to do to turn miles of
>>>> existing one-way-per-railway tagging into one-way-per-track.
>>>> When it comes to tramways and level crossings, whichever approach we
>>>> take there are many counter-examples to be corrected, of course.
>>>> I would note that if we *did* adopt a separate tagging scheme for
>>>> detailed mapping of tracks then at least one could simply re-tag the
>>>> existing railway=rail as (e.g.) railway:track=rail and not destroy the
>>>> existing detailed geometry. Of course, someone would have to draw in the
>>>> basic route network too; I bet the data for that is somewhere buried in the
>>>> OSM historical record, since a schematic view of the UK railway network was
>>>> imported into OSM as a starting point many years ago and is still the basis
>>>> of simple mapping in many rural areas, but admittedly I have no idea how or
>>>> whether it could easily be recovered for situations like your Battersea
>>>> example.
>>>>  However what I do agree with you is that the rail guidelines should be
>>>>> more
>>>>> detailed but I would go the other way with saying that all tracks
>>>>> should be
>>>>> mapped not less for complete mapping. That is a common way of doing
>>>>> things
>>>>> and going forward especially as we get more detailed mapping (it's
>>>>> slowly
>>>>> coming to the US ;))
>>>> I'd be fine with that as long as the result includes details about how
>>>> to connect the road and rail networks in a clear, unambiguous way at all
>>>> levels of detail. It is the lack of definition around these interactions
>>>> that causes the most difficulty, I think.
>>>> London isn't a great example of the problem since it has many, many
>>>> railways but very few situations where railways connect with highways at
>>>> grade.
>>>> Croydon Tramlink is one counter-example, and I'd concede that someone
>>>> has done great work in accurately mapping the path of it that I wouldn't
>>>> want to destroy, but it is sadly completely disconnected from the highway
>>>> network, and that is what I'd like to address.
>>>> ______________________________**_________________
>>>> Tagging mailing list
>>>> Tagging at openstreetmap.org
>>>> http://lists.openstreetmap.**org/listinfo/tagging<http://lists.openstreetmap.org/listinfo/tagging>
>>> ------------------------------
>>> Tagging mailing list
>>> Tagging at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/tagging
>> Did you intentionally write "one way per rail", or did you intend to say
>> "one way per track"? I had not seen anyone in the discussion, up until now,
>> propose mapping each rail as a separate way. This would mean that a
>> single-track right-of-way would require two ways, unless you were mapping a
>> monorail.
>> --
>> John F. Eldredge -- john at jfeldredge.com
>> "Reserve your right to think, for it is better to think wrongly than not
>> to think at all." -- Hypatia of Alexandria
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20130413/adfd69fd/attachment-0001.html>

More information about the Tagging mailing list