[Talk-transit] Multiple tracks

Richard Mann richard.mann.westoxford at googlemail.com
Thu Jun 25 23:57:26 BST 2009


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?

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.

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.

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20090625/9ad248cb/attachment.html>


More information about the Talk-transit mailing list