[Talk-transit] Multiple tracks

Fri Jun 26 12:07:32 BST 2009

Ah. A choice between relationing for the specialist renderer and tagging for
the specialist & general renderer.

Given a choice, I would opt for the latter, because it's easier for the
tagger to see the results of their work - because it will be more likely to
appear in renderings that they see. So it's more likely that they will do
it. But perhaps the reality is that neither will be done.

Much the same problem exists for cycle tracks next to roads, and the
rendering is pretty poor as a result. Sometimes I get the impression that
renderers think it's a matter of pride that they should be able to hack the
data into shape for us. To the point that they leave things complicated (and
rendered poorly) when a slightly more structured approach to tagging would
simplify matters no end.

I think the absolute simplest is to stick to using a single way unless there
are really pressing reasons for separating them into individual tracks, and
if you do separate into individual tracks then call them something different
(railway=rail_track?) and leave the railway=rail way in place to continue to
represent the corridor. We don't generally do separate ways for each side of
a road (not least because of this rendering issue), so maybe we should
accept it's not a good idea for rail either.

Richard

On Fri, Jun 26, 2009 at 9:27 AM, Peter Miller <peter.miller at itoworld.com>wrote:

>
>  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!
>
>
>
> Regards,
>
>
> Peter
>
>
>  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/6df18bb3/attachment.html>