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