Re: [Talk-transit] Multiple tracks

2009-06-26 Thread Richard Mann
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.mil...@itoworld.comwrote:


  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.5778172016144lon=-0.105679035186768zoom=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 

Re: [Talk-transit] Multiple tracks

2009-06-25 Thread Paul Johnson
On Sat, 2009-06-20 at 12:18 +0100, Richard Mann wrote:
 While I like the idea of marking individual railway tracks as separate ways, 
 I foresee a problem for the renderers if we don't tell them how many tracks 
 are adjacent. If a renderer makes a distinction between tracks=1 and 
 tracks=2, and we've marked two separate adjacent ways with tracks=1, then 
 we'll just end up with two single tracks on top of each other at medium zooms.

It seems like OSM is already quite well-suited to handling this problem
with the tools already available.  See the Metropolitan Area Express
system in Portland, here's a particularly good example from the
neighborhood by the high school I went to growing up.
http://www.openstreetmap.org/?lat=45.5107lon=-122.8481zoom=14layers=0B00FTF




signature.asc
Description: This is a digitally signed message part
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Multiple tracks

2009-06-22 Thread Richard Mann
While we could do it with relations, the dual-carriageway model might not be
the best starting point, since I don't think we'll ever need to set railways
up for routing programs to use. Nine months in, I can get my head round
route relations and turning-restriction relations, but I struggle a bit with
the value of relations to group parallel ways - it seems a complexity too
far for the purpose (and I don't see much evidence of renderers making use
of it to render dual carriageways).

If tracks are notably more than the standard ~3m between track centres, then
map them as single lines (tracks=1), as soon as they diverge. It's the
renderers job to smooth the transition from tracks=2 to tracks=1.

I'd do any pointwork as single lines, switching from 2xtracks=1of2 to
1xtracks=2 at some convenient point away from the junction where track
separation is roughly standard (and let the renderer worry about making the
transition seamless). Or just ignore pointwork for the moment.

I think in time, people will map individual tracks separately. But there
needs to be the ability to have a single way as a first step (not least to
make it backwards-compatible), and not to make it too difficult to add
descriptive detail (how many tracks, whether it is electrified, whether it
has passenger services, whether it has fast services, whether it has
fast/highspeed lines, whether it has freight lines). This is the sort of
information that makes sense at low zooms. Separately, you might want to add
the services as relations, so you can put together something more akin to
the operator's maps, at a higher zoom.

Richard
On Mon, Jun 22, 2009 at 10:30 AM, Peter Miller peter.mil...@itoworld.comwrote:


 On 22 Jun 2009, at 07:51, Jochen Topf wrote:

 On Sun, Jun 21, 2009 at 05:09:35PM +0100, Richard Mann wrote:

 No, simpler than that:

 tracks=1 = render a single line at all zooms
 tracks=2 = render a double line at all zooms
 tracks=X = render a multiple line with X tracks at all zooms
 tracks=1ofX = render a single line at high zooms, but render as if
 tracks=X
 at medium/low zooms


 But then you'd still draw several lines nearly on top of each other in
 medium
 zoom levels which doesn't look good, which was the problem we were trying
 to
 fix?

 Anyway, this is a rather specialized trick about rendering the number of
 tracks
 properly. But what if you want to render other attributes. Say one of your
 two
 tracks is an industrial railway, the other a normal passenger railway and
 you
 want to distinguish those types. On medium zoom levels, is this a two
 track
 thing and we loose the type distinction, or do we keep it?


 The dual_carriageway and Junction relations would appear to the a good way
 of doing such things. I realise that the 'dual carriageway' term is not
 right and that other work would be required on the specifications, however
 it would seem a better starting point.

 http://wiki.openstreetmap.org/wiki/Relations/Proposed/Junctions
 http://wiki.openstreetmap.org/wiki/Relations/Proposed/Dual_carriageways

 A group of parallel tracks would be combined using 'dual carriageway' and
 then a group short sections of track and nodes can be combined as a
 'Junction'. The render would then have a choice of drawing modes, either a
 single line and single point, or multiple lines/points.



 Regards,



 Peter




 Jochen
 --
 Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/ +49-721-388298


 ___
 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


Re: [Talk-transit] Multiple tracks

2009-06-21 Thread Jochen Topf
On Sun, Jun 21, 2009 at 07:24:37AM +0200, Cartinus wrote:
 On Saturday 20 June 2009 22:20:09 Jochen Topf wrote:
  Can you think of any software or at least give an algorithm that would make
  use of this tag?
 
 When you use a different linestyle for rendering single and double track, 
 then 
 (for the middle zoom levels) you can use the linestyle for double track on 
 any single track that has this extra tag. Aggregation then takes care of 
 itself.

So, do I understand this correctly: On small zoom levels you want to render all
tracks with track=1ofX and all with track=YofX with Y!=1 don't get rendered. It
is the responsibility of the mapper to decide which of several tracks gets to
be number one, because this is the only one rendered (presumably a middle
one, if available). Of course you still have to render all tracks without this
tag, because you don't know how they hang together.

I guess this could work for rendering. There'll probably be some oddities
where different railways join, but for small enough zoom levels one can't
see that. Mappers would need some guidance on how to tag railway yards,
larger stations etc. so that it comes out right.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Multiple tracks

2009-06-21 Thread Joseph Booker
On Sat, 20 Jun 2009 12:18:43 +0100
Richard Mann richard.mann.westoxf...@googlemail.com wrote:

 While I like the idea of marking individual railway tracks as
 separate ways, I foresee a problem for the renderers if we don't tell
 them how many tracks are adjacent. If a renderer makes a distinction
 between tracks=1 and tracks=2, and we've marked two separate adjacent
 ways with tracks=1, then we'll just end up with two single tracks on
 top of each other at medium zooms.
 
 My thought is that we either make it tracks=1of2 or have a separate
 track_grouping=1of2. Anyone else have a better idea?
 
 I've put a comment to this effect on the multiple_tracks proposal,
 but this list doesn't see much traffic, so I thought I'd raise it
 here.
 
 Richard

What if the adjacent tracks are physically 20m away, or 30m or 40m
away, but they are still part of the same rapid transit or freight
lines? Does tracks=1of2 imply that they must be close enough to overlap
at a given zoom level?

Honestly, I think the real problem with your proposal is you talk of
zoom levels like they are a definite thing. There are more renders then
just mapnik, and exactly what corresponds to 'medium' zoom seems like
you're putting renderer details into the data.

-- 
Joseph Booker


signature.asc
Description: PGP signature
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Multiple tracks

2009-06-20 Thread Cartinus
On Saturday 20 June 2009 22:20:09 Jochen Topf wrote:
 Can you think of any software or at least give an algorithm that would make
 use of this tag?

When you use a different linestyle for rendering single and double track, then 
(for the middle zoom levels) you can use the linestyle for double track on 
any single track that has this extra tag. Aggregation then takes care of 
itself.

-- 
m.v.g.,
Cartinus

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit