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.mil...@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-transit > > >
_______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
