Re: [Talk-transit] [Spam] Re: Multiple tracks

2009-06-24 Thread Richard Mann
Choosing not to render a point because there's something else more important
close by is relatively easy. Aggregating adjacent lines is much (much)
harder. Identifying the number of lines that are adjacent is much
(much) easier for the tagger than for the renderer.

But I seem to be repeating myself; you either believe me or you don't.

Richard


On Tue, Jun 23, 2009 at 7:52 AM, Frankie Roberto fran...@frankieroberto.com
 wrote:


  On Mon, Jun 22, 2009 at 5:21 PM, Peter Miller 
 peter.mil...@itoworld.comwrote:


 Can I suggest that as a start you create the detailed track layout and
 then we can look at different grouping strategies and see which ones the
 Mapnik people and routing people will find useful. Whatever you do should
 work for rail and trams and I see no reason for there not to be generality
 with roads. Lets not worry too much about the wrapping until we have stuff
 to wrap.


 I think this is a good approach.  Using a tracks=1ofX tag could end up a
 complete waste of time if renderers can use the relations to dynamically
 pick whether to draw one track or more anyway.  Mapnik seems to decide how
 many POIs to render based partly on how many it can fit on the map, so this
 doesn't seem infeasible.

 I'd like to see some discussion about strategies for tagging individual
 tracks though. I've attempted to do it in a few places, but mainly only at
 stations (where I've also drawn the platforms).

 Has anyone attempted to draw the switches where two lines meet? How about
 adding oneway=yes? Level crossings?

 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


Re: [Talk-transit] [Spam] Re: Multiple tracks

2009-06-24 Thread Frankie Roberto
On Wed, Jun 24, 2009 at 1:31 PM, Richard Mann 
richard.mann.westoxf...@googlemail.com wrote:

Choosing not to render a point because there's something else more important
 close by is relatively easy. Aggregating adjacent lines is much (much)
 harder. Identifying the number of lines that are adjacent is much
 (much) easier for the tagger than for the renderer.

 But I seem to be repeating myself; you either believe me or you don't.


I do believe you, and I haven't actually tried to implement such an
algorithm myself. It's just my instinct that we should be tagging the data
and letting the renderers worry about rendering algorithms later. However, I
agree that there's a balance to be struck.

Do relations solve the problem at all? If a track is part of a route
relation, then could a renderer use that as a means of aggregating the
tracks together?

Are there any Mapnik people we can involve in this discussion?

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


Re: [Talk-transit] [Spam] Re: Multiple tracks

2009-06-24 Thread Frankie Roberto
On Wed, Jun 24, 2009 at 2:45 PM, Richard Mann 
richard.mann.westoxf...@googlemail.com wrote:


 Do relations solve the problem at all? If a track is part of a route
 relation, then could a renderer use that as a means of aggregating the
 tracks together?


 My hunch is that relations probably don't actually help much, unless you
 could rely on them being done consistently and accurately.


Hmm...

One idea another OSMer suggested a while back (when the idea of tagging
tracks still sounded ridiculous) is to have some way of distinguishing
between a 'track' and a railway line (or 'corridor' is perhaps a better
word), so that renderers can choose which to display (and so that the data
contains both conceptually different things).

Not sure how best to implement this. The easiest thing would be to have the
middle track double up as the way which represents the line, somehow. The
hardest thing might be to have ways which mark both edges of the rail
corridor (like how we do riverbanks).

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


Re: [Talk-transit] [Spam] Re: Multiple tracks

2009-06-23 Thread Richard Mann
The traditional method is to tag a node to be used as low zooms, and to tag
various bits of detail to be used at high zooms. Using a relation for a
point-location seems to be a rather more complicated way of achieving the
same end (more complicated to create, more complicated to maintain).

In the case of parallel ways, you could either:
1) create a further parallel way. This is what is done with house numbers
(and to my mind would work for central reservations)
2) add information for the group to all the components (eg tracks=1of2).
This works well if there's no obvious entity defining the centre line, but
the components are very consistently located in respect of one another
3) create a relation for the group to hold group-level information
(presumably this requires an algorithm to determine its geo-location, and
could go a bit haywire if the component elements weren't strictly identical
but offset, and would be complicated even if they were)

The group-level information needs to be held somewhere (ie we can't just put
tracks=1). But I don't think relations are the answer to all our problems.
Richard
On Mon, Jun 22, 2009 at 5:21 PM, Peter Miller peter.mil...@itoworld.comwrote:


  On 22 Jun 2009, at 12:53, Richard Mann wrote:

  On Roger's point about sidings - I'd map those as a separate track group,
 since they are the sorts of things people would expect to disappear at lower
 zooms. So north of Oxford station, I'd have the 4 down carriage sidings as
 one group, the four running lines as one group and the 4 up carriage sidings
 as a third group. Within each of those three groups, you could either do the
 individual tracks (as 1of4), or the tracks as a group (tracks=4).

 On loops, I'd probably exclude them from the running lines group, and use
 other tags (perhaps has_loops=yes) to tell me that there are extra tracks
 for a short-distance. You might also do has_loops:left and has_loops:right,
 but one-sided rendering is on the tricky side. So just south of Oxford at
 Kennington, you'd have the two running lines as tracks=2 (or 2xtracks=1of2)
 with has_loops=yes. If I had done the two tracks separately, the renderer
 would be entitled to expect me to have done the freight loops separately as
 well, so they can ignore has_loops=yes at high zooms, and just render the
 ways that have been drawn.


 Can I suggest that as a start you create the detailed track layout and then
 we can look at different grouping strategies and see which ones the Mapnik
 people and routing people will find useful. Whatever you do should work for
 rail and trams and I see no reason for there not to be generality with
 roads. Lets not worry too much about the wrapping until we have stuff to
 wrap.

 For your interest, here is an example road interchange which can be
 rendered as a dot if required, or used in driving instructions as 'turn left
 at the 'Whitehouse Junction'.
 http://www.openstreetmap.org/browse/relation/2470

 Here is a dual-carriageway example - just bind all the parallel ways
 together and a renderer can then do a line down the middle at some point.
 http://www.openstreetmap.org/browse/relation/2490

 Here is a railway station where all the elements (including tracks,
 sidings, platforms, buildings, car parking, taxi ranks and cycle racks) are
 all part of a relation.
 http://www.openstreetmap.org/browse/relation/2522

 And here is a sample rail junction wrapped up using a relation:-
 http://www.openstreetmap.org/browse/relation/162263

 This should make it very easy for a renderer. The general rule is 'if you
 can't fit in all the detail on the map and it is part of a relation then do
 a single dot or single line for the whole thing.


 Regards,



 Peter




 Richard



 On Mon, Jun 22, 2009 at 10:45 AM, Roger Slevin ro...@slevin.plus.comwrote:

 As someone who doesn't have the experience of mapping that you all do, but
 I
 do know something about public transport, I can see how the various
 concepts
 for single track and double track etc work along straightforward corridors
 (note these must be tracks (or maybe some other term) and not lines -
 as
 a line in public transport is something completely separate from the
 infrastructure) ... but what happens when operational details get more
 complicated ... at stations, or near and in depots and sidings?  What
 happens for passing bays?  Does a track have a directionality associated
 with it (even if it is only implied by a national convention of driving
 on
 the left/right... though that will give some issues on the German border
 where operations switch sides) - and what happens when multiple tracks are
 signalled for bi-directional working?

 I sense that there is a potential issue here between describing the
 physical
 infrastructure and describing its functional performance ... and I am not
 sure the boundary has been drawn correctly between the two.

 Roger

 -Original Message-
 From: talk-transit-boun...@openstreetmap.org
 

Re: [Talk-transit] [Spam] Re: Multiple tracks

2009-06-23 Thread Frankie Roberto
On Mon, Jun 22, 2009 at 5:21 PM, Peter Miller peter.mil...@itoworld.comwrote:


 Can I suggest that as a start you create the detailed track layout and then
 we can look at different grouping strategies and see which ones the Mapnik
 people and routing people will find useful. Whatever you do should work for
 rail and trams and I see no reason for there not to be generality with
 roads. Lets not worry too much about the wrapping until we have stuff to
 wrap.


I think this is a good approach.  Using a tracks=1ofX tag could end up a
complete waste of time if renderers can use the relations to dynamically
pick whether to draw one track or more anyway.  Mapnik seems to decide how
many POIs to render based partly on how many it can fit on the map, so this
doesn't seem infeasible.

I'd like to see some discussion about strategies for tagging individual
tracks though. I've attempted to do it in a few places, but mainly only at
stations (where I've also drawn the platforms).

Has anyone attempted to draw the switches where two lines meet? How about
adding oneway=yes? Level crossings?

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


Re: [Talk-transit] [Spam] Re: Multiple tracks

2009-06-22 Thread Peter Miller


On 22 Jun 2009, at 12:53, Richard Mann wrote:

On Roger's point about sidings - I'd map those as a separate track  
group, since they are the sorts of things people would expect to  
disappear at lower zooms. So north of Oxford station, I'd have the 4  
down carriage sidings as one group, the four running lines as one  
group and the 4 up carriage sidings as a third group. Within each of  
those three groups, you could either do the individual tracks (as  
1of4), or the tracks as a group (tracks=4).


On loops, I'd probably exclude them from the running lines group,  
and use other tags (perhaps has_loops=yes) to tell me that there are  
extra tracks for a short-distance. You might also do has_loops:left  
and has_loops:right, but one-sided rendering is on the tricky side.  
So just south of Oxford at Kennington, you'd have the two running  
lines as tracks=2 (or 2xtracks=1of2) with has_loops=yes. If I had  
done the two tracks separately, the renderer would be entitled to  
expect me to have done the freight loops separately as well, so they  
can ignore has_loops=yes at high zooms, and just render the ways  
that have been drawn.


Can I suggest that as a start you create the detailed track layout and  
then we can look at different grouping strategies and see which ones  
the Mapnik people and routing people will find useful. Whatever you do  
should work for rail and trams and I see no reason for there not to be  
generality with roads. Lets not worry too much about the wrapping  
until we have stuff to wrap.


For your interest, here is an example road interchange which can be  
rendered as a dot if required, or used in driving instructions as  
'turn left at the 'Whitehouse Junction'.

http://www.openstreetmap.org/browse/relation/2470

Here is a dual-carriageway example - just bind all the parallel ways  
together and a renderer can then do a line down the middle at some  
point.

http://www.openstreetmap.org/browse/relation/2490

Here is a railway station where all the elements (including tracks,  
sidings, platforms, buildings, car parking, taxi ranks and cycle  
racks) are all part of a relation.

http://www.openstreetmap.org/browse/relation/2522

And here is a sample rail junction wrapped up using a relation:-
http://www.openstreetmap.org/browse/relation/162263

This should make it very easy for a renderer. The general rule is 'if  
you can't fit in all the detail on the map and it is part of a  
relation then do a single dot or single line for the whole thing.



Regards,



Peter





Richard



On Mon, Jun 22, 2009 at 10:45 AM, Roger Slevin  
ro...@slevin.plus.com wrote:
As someone who doesn't have the experience of mapping that you all  
do, but I
do know something about public transport, I can see how the various  
concepts
for single track and double track etc work along straightforward  
corridors
(note these must be tracks (or maybe some other term) and not  
lines - as

a line in public transport is something completely separate from the
infrastructure) ... but what happens when operational details get more
complicated ... at stations, or near and in depots and sidings?  What
happens for passing bays?  Does a track have a directionality  
associated
with it (even if it is only implied by a national convention of  
driving on
the left/right... though that will give some issues on the German  
border
where operations switch sides) - and what happens when multiple  
tracks are

signalled for bi-directional working?

I sense that there is a potential issue here between describing the  
physical
infrastructure and describing its functional performance ... and I  
am not

sure the boundary has been drawn correctly between the two.

Roger

-Original Message-
From: talk-transit-boun...@openstreetmap.org
[mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Peter  
Miller

Sent: 22 June 2009 10:31
To: Jochen Topf
Cc: osm
Subject: Re: [Talk-transit] Multiple tracks


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.