[Talk-transit] Multiple tracks

Peter Miller peter.miller at itoworld.com
Fri Jun 26 09:27:07 BST 2009

On 25 Jun 2009, at 23:57, Richard Mann wrote:

> Rendering isn't generally that complicated. The renderer usually  
> just draws all the lines on top of each other. Why process relations  
> when you can just apply styles to appropriate selections of the raw  
> data in an appropriate order?

I agree that for basic rendering the tracks will go on top of each  
other and that for many purposes this will be sufficient and relations  
will not be required and we can just get on a create a detailed rail  
network with ways for every track and very set of points if we wish.  
The rendered will sort it all out reasonably well as one zooms out.

However I am participating in this thread because I want to be able to  
produce rail maps that use different line styles for single track,  
twin track and multi-track routes because single track working is a  
real pain for operators and it is important to be able to see where  
they are on a map. Typically single track sections will be in one  
colour, twin track in another and multi-track in another one.

I can already do this where there is a single way with 'tracks=1' or  
'tracks=2' or 'tracks=4' etc. I would use a different colour for  
sections where the number of tracks was not specified.

It can also do this easily where there was a relation with two or  
possibly more tracks as part of a group (I count the number of tracks  
and then render the route using a random track from the relation). As  
for junctions I would dump all the ways that were part of them and  
replace them with a node and terminate the tracks to the appropriate  
junction node.

The code to achieve this is simple and will be reusable for other  
transport modes such as dual carriageways.

> Thinking about it, I think the most economical approach is as follows:
> 1) tracks should be equal to the number of parallel running tracks  
> in the corridor
> 2) the tracks tag should be attached to a middle track (or an  
> additional way on a central alignment, eg along the middle of an  
> island platform)
> 3) the tracks tag should not be attached to other tracks (but won't  
> do much harm if it is)
> 4) a further tag, say tracks_highzoom should define how many tracks  
> this way represents at high zoom, if that's different. This will be  
> 0 if it's an additional way on a central alignment, 1 if it's a  
> middle track with the others also mapped out, and not stated if the  
> tracks aren't individually mapped out.

There are some awkward situations that need to be considered.

1) The middle track might not remain the middle track because might  
switch to become the outer track. Would one ignore this or select a  
different 'middle-track' or add an additional track?
2) How will it work where two different groups of tracks arriving at a  
junction and merge into a single (larger) group of tracks. The tracks  
north of Harringay is a pretty good test area for any tagging (http://www.openstreetmap.org/?lat=51.5778172016144&lon=-0.105679035186768&zoom=16 
3) The business of adding an additional tracks to help the rendered  
seems pretty unattractive.

It occurs to me that we also need to deal with the situation where  
there are mixed modes running parallel, for example a tram running  
parallel to, one or in the middle of a road or a road and a cycle  
track running parallel or a guided busway and a cycle-track running  
parallel. The renderer could have a special line style for a these  
mixed modes and use them when it spots different modes wrapped up into  
a single 'dual carriageway' relation.

> At low-medium zooms, the renderer looks for railway=rail+tracks=X,  
> and renders according to X
> At high zooms, the renderer looks for:
> a) railway=rail+tracks_highzoom<>0, and renders a single track
> b) railway=rail+tracks=X+tracks_highzoom=unstated, and renders  
> according to X
> So for simple single-way layouts, you just add tracks=X. For  
> detailed layouts, you add tracks=X+tracks_highzoom=1 to one of the  
> tracks (or create an extra way on a central alignment and tag it as  
> railway=rail+tracks=X+tracks_highzoom=0). To convert a simple single- 
> way layout into two parallel tracks, the best bet is to add  
> tracks=2+tracks_highzoom=0 to the original way, then create parallel  
> ways either side (1.5m separation), tagged simply as railway=rail.
> I think this defines the situation with the minimum of fuss, and  
> makes it easy for even a beginner-renderer to do it right.

Doesn't feel like the minimum of fuss to me, sorry. I suggest that  
beginner-renderer and contributors should ignore the problem!



> Richard
> On Wed, Jun 24, 2009 at 7:20 PM, Peter Miller <peter.miller at itoworld.com 
> > wrote:
> I would suggest that renderers should taker advantage of the fact  
> that as one zooms out then the different tracks are so close  
> together that it doesn't really matter in most cases which one it  
> draws and it can normally choose one at random to draw. As a  
> refinement the relation could identify the preferred track using a  
> 'role' to say 'draw this one' for situations where the geometry is  
> very different for the various ways.
> Similarly Junction relations would soak up all the fiddly tracks at  
> junctions and replace them with one point (and the junction relation  
> includes an optional 'hint' location to show where it should go).
> The selected track is then drawn from the starting junction (using  
> the location of the junction node rather than the first point on the  
> track) to the end junction taking via points from the selected way.
> This section of track from Finsbury Park through Harringay, Hornsey  
> to the junction past Aexandra Park might be a good test route to try  
> any of our proposals. Here is an image showing an overlay for the  
> proposed simplified rendering where there is only a single stroke  
> drawn to cover all of the individual tracks.
> http://www.flickr.com/photos/peterito/3657058971/
> Regards,
> Peter
>> Frankie
>> -- 
>> Frankie Roberto
>> Experience Designer, Rattle
>> 0114 2706977
>> http://www.rattlecentral.com
>> _______________________________________________
>> Talk-transit mailing list
>> Talk-transit at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-transit
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20090626/d651fd24/attachment.html>

More information about the Talk-transit mailing list