Proposal talk:Multiple Tracks

From OpenStreetMap Wiki
Jump to navigation Jump to search

lanes

Looking at tagwatch it seems lanes is currently (miss)used for this purpose. However given the difference between rail and other ways personally I can accept the use of lanes inplace of tracks. --Pobice 12:55, 28 March 2009 (UTC)

Tramway tracks often share a way with highways, in that case the use of lanes= would be confusing. -- Skunk 18:57, 29 March 2009 (UTC)
how does the proposal handles this indeed quite common case? Should we tag such a way as higway=* + lanes=* + railway=* + tracks=*? -Kaitu 13:08, 2 April 2009 (UTC)
Sounds reasonable to me, doesn't it? -- Skunk 05:54, 3 April 2009 (UTC)
I draw a separate track and road, positioned as needed. When the track runs up the middle of the road, I draw the road as a dual_carriageway. I'm currently using tracks=* in the Ontario, CA, USA area. It's far more productive than drawing the individual tracks, which, in some areas with only Yahoo imagery, are hard to distinguish anyway.
Also, when drawing a switchyard, because of the complexity of all the junctions, and the difficulty in modeling them accurately from poor imagery, I've used a single railway that approximates the centerline with service=yard + tracks=x;y;z, where x is the number of tracks coming into the yard, y is the maximum number of tracks at any point, and z is the number of tracks going out of the yard. Since rails aren't really my focus (for now), this allows me to get the features located and rendered, leaving the detailed mapping for others in the future if they like. AM909 01:21, 9 October 2009 (UTC)

tracks=right;left

What is the purpose of e.g. tracks=right. Is there a link with attributes: highway=residential; railway=tram; tracks=right when the tram is on the right side of the street? Shouldn't it be two lines (one residential, one railway) instead? PieSchie 07:08, 7 April 2009 (UTC)

I think both should be possible. But just to make the point clear: The road is shared with the tram track, it's not a separate track. -- Skunk 13:38, 7 April 2009 (UTC)

Rendering

Proposed Single-track rendering
Proposed Double-track rendering

Can I suggest, especially for "railway=rail" rather than "railway=tram" -ways, that is would be good to have a way of showing number of tracks without rendering 2 lines. For example, as well as rendering separate lines at very high zoom levels(15+), at levels lower than this (ie: zoomed out) railway lines tagged as "tracks=1" would be shown as they are currently in Mapnik (a bordered dashed line), and "tracks=2" or more shown as a solid black line.--CunningPlan What's on your mind? 10:52, 13 May 2009 (UTC)

Compatibility with more individual lines & info

Pondering whether we should be marking individual tracks or just rail corridors, I thought of the following. I should say that my interest is in being able to see more detail (which lines carry fast services, which corridors have more than 2 tracks, which corridors are super-high-speed etc).

Simple model: one way for the corridor, number of tracks specified as tracks=1,2,3 etc.

Complex model: one way for each track, number of tracks specified as tracks=1of2,1of3,1of4 etc

The virtue of this is that it makes it possible to render a mixture of simple and complex, without the joins being too painful. At low zooms (which probably means 1-16), any complex modelling will appear as a single line, so you just render all the individual ways according to the total width. But at high zooms, you can render the two systems on the assumption that the tracks are 3m apart at the join. The complex modelling can then show platform layouts etc.

Possible additional tags such as fast_services=yes/no for lines that feature services running at a commercial speed (ie after allowing for stops) of more than 100kph, and line_type=slow/fast/high_speed where fast is for lines that are (almost) exclusively used for fast services, and high_speed is for new-built lines with line speed typically in excess of 200kph. That gives the basic distinction between branch and main lines, with High Speed Lines separate again.

The only thing this doesn't really cover is distinguishing the situations where the fast tracks are on the left, right, outside, inside, or even interleaved (eg Rugby-Brinklow). The default is probably to put the fast lines in the middle (because it's easier to render symmetrical lines). But a scheme on the lines of line_order=sffs/ssff/ffss/fsfs might be feasible (using LinePatternSymbolizer in Mapnik).

--RichardMann 13:27, 19 June 2009 (UTC)

I don't really see the reason for the distinction between simple and complex model. IMO if you want to mark each track as a single one, jump right in and do so and tag them as tracks=1. Anyway, maybe you want to have a look at this: User:Oxomoa/Public_transport_schema. -- Skunk 14:04, 19 June 2009 (UTC)
If you tag the individual tracks as tracks=1, how's the renderer supposed to identify the need to portray a difference between a single-track line and a four-track main line done as four separate ways? If I just put tracks=1, the renderer will just draw four single lines virtually on top of one another. Maybe an additional track_grouping=1of2,1of3,1of4 is better. Also, looking at the schema, "service" & "usage" could have multiple values and should be recast as four/more separate tags.--RichardMann 10:50, 20 June 2009 (UTC)
Renderers should be able to use their magic intelligence (c) to figure this out. Plus they could be helped along with a relation or two. I don't see the need to tag tracks=1 on individual tracks though - that should be the default? Frankie Roberto 09:29, 24 June 2009 (UTC)
IMHO tracks=1 is helpful, because it tells other users, that there's really only one track. If you don't do it, there could still be more tracks, but it hasn't been tagged (yet). -- Skunk 05:07, 7 August 2009 (UTC)
If there is something missing, then there is a universally used and rendered tag called FIXME=Description of error. We do not want to invent different tagging for errors in different objects, do we?

--Lulu-Ann 11:42, 7 August 2009 (UTC)

Contra

If you have two separated streets, where you can not go to the other lane, that is two ways. You can not jump over to the next track, so you need two ways. Positions of switches are of interest, at least for routing (Yes, railway routing! Why not ?). Sooner or later there is information collected only valid for one of the tracks, like the building date, if it is electrified or the material of the ground. I am against this proposal. --Lulu-Ann 14:46, 4 August 2009 (UTC)

I completely agree with you. A railway system is a complex network system with specific intersection points where you can change track. and that's what should be mapped. A hiker surely doesn't care where the 4 tracks are. It's enough to know that there are 4 tracks. But a railway-centered map surely needs more information. using a tag to describing multiple track sections is an oversimplification and will - in long term - always only be a temporary solution. Sooner or later we will have the need (I think it exists already) to represent the physical reality of railway lines and not only a conceptual representation. And I am clearly against a tag that simplifies the railway tracks since it enforces people to just do lazy mapping: "why should I map all 4 tracks when I can just map one and add a tag...". that's not the goal of OSM. There is just no need for two different systems to represent reality. Especially if one is more a hack than a real representation. If someone decides to just map one of 4 tracks I'm fine with that. He shall add a fixme tag, a bug entry or a comment so other mappers know there is still work left to do. (and yes: I'm not a fan of a highway-lane tag too. sooner or later we will start mapping the lanes, in fact people already started on certain highway types... so why invest in a temporary solution?!). Let's do it right from the beginning! --Marc 09:26, 23 December 2009 (UTC)
+1 --Gorm 22:26, 10 July 2010 (UTC)
I am also against this proposal, the tracks=* tag versus individual tagging would negatively impact accurate navigation on lines owned by clubs that are open to the public. Paul Johnson 18:15, 9 March 2011 (UTC)