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

Paul Johnson baloo at ursamundi.org
Sun Apr 14 04:41:50 UTC 2013


I'd still stick to one-way-per-track for consistency, especially given many
cities (London, Portland) have 100% complete systems mapped already using
that method, and it's not just torturing the data.  Your assumptions of how
trams interact with traffic are also pretty far from universal, with
Portland and Phoenix being examples that pretty much flies in the face of
what you suggested (Portland's newest trams are actually slightly longer
than the shortest platforms, which are a city block long, frequently
leaving the tail end of the train in the intersection, with most trains
being only about 10 feet shorter; priority signaling is the norm; 480 tons
doesn't stop on a dime in any sense of the word).


On Sat, Apr 13, 2013 at 11:34 PM, Martin Atkins <mart at degeneration.co.uk>wrote:

> On 04/13/2013 12:52 PM, David Fisher wrote:
>
>>
>> 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).
>>
>>
> This is actually pretty insightful, and lead me to the following thought:
>
> Really my proposal is all about trams. The problems with level crossings
> and bridges tricked me into thinking it was a general rail problem, but
> really I think the core issue is with these special characteristics of
> trams as compared to full-blown trains:
>
> - They have a small form factor like a bus, and unlike a train. This
> allows them to behave more like "normal" traffic, with the exception of not
> being able to change lanes. For example, they can make tight turns and can
> stop quickly when traffic conditions require it. (Trolley buses are similar
> in that they are tethered to special infrastructure, but they have a little
> more flexibility because of the trolley poles.)
>
> - They usually participate as full members of the roadway... that is, they
> often stop at the same traffic signals, the same stop signs, get stuck in
> the same traffic queues. On the other hand, when full railways interact
> with roads they generally get automatic priority, stopping all other
> traffic that might otherwise be using the right of way.
>
> - They often have boarding areas that are more like bus stops than
> platforms, and depending on where in the roadway the track runs there may
> not be any special boarding facilities at all.
>
> Some of this applies to a lesser extent to light rail in some areas.
>
> So with all of that said, I'm considering reigning in my proposal to
> discuss trams only; would one-way-per-tramway but one-way-per-rail-track be
> an acceptable compromise? Again I'm really only personally interested in a
> comparable amount of detail as trolley_wire=yes, but if it will help to
> convince I can again try to create a strawman detailed mapping proposal.
>
> There is still the problem with level crossings to deal with, but that's
> minor and can be dealt with by a separate proposal (tramways don't usually
> have level crossings in the same sense as railways anyway) and otherwise
> the full detailed mapping of railways is harmless.
>
>
>
>
> ______________________________**_________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/tagging<http://lists.openstreetmap.org/listinfo/tagging>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20130413/4e6a6304/attachment.html>


More information about the Tagging mailing list