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.com>wrote: > > 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. 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 >> >> >> _______________________________________________ >> 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
