I'm not sure I like the idea of a "2" way on top of a shorter "2a" and "2b" way; hence my instinctive preference for nodes in the complicated situations. It can also be unclear where one subplatform starts and ends (especially where the split does't reflect a signalling berth, as is common in Germany, for instance). However, I can't really see the harm in using ways in the simple situation, and equally the full platform face name could be a way, but I'd make subplatform locations nodes rather than ways.
The length of a platform could equally well be recorded as a length= tag on a node; the info is on the NR website if you know where to look - and have permission to use it. And the fact that it may not _yet_ render is - ahem - not relevant. Richard On Wed, Sep 2, 2009 at 4:42 PM, Peter Miller <[email protected]>wrote: > > On 2 Sep 2009, at 16:27, Richard Mann wrote: > > 2) I don't like the idea of ways for platforms, except possibly for the > limited case where you've got one platform on each side. It's just not > extendable. They should be areas. Sublettering for parts of platforms should > probably be on nodes, representing the point on the platform that's the > midpoint for boarding a train that stops at that platform (it will be in the > timetable system as "2a", and a notional router ought to direct you to that > point). If a platform is split into 2a and 2b, you probably need three nodes > - 2a/2b and 2 (for trains that take up the full length). > > > Personally I find linear ways pretty satisfactory for platforms, which > often have no more width than a footpath after all (which are also tagged as > linear features)/ Possibly we should use areas for larger platforms (ie the > paved/tarmac area) with highway=pedestrian;area=yes and then add > railway=platform ways to the edges of the area as required. Sub platforms > can also be linear ways for their actual extent (I don't like using nodes > for sub-platforms because they do have an extent which can be measured and > is sometimes be important). For a platform that serves two tracks, one of > either side then an area should be used with the two different sides having > appropriate linear 'platforms' associated with them. I am not sure how to > represent a set of steps coming down to a point in the middle of an area > though. One reason to use linear ways for now is because we already have the > tools to build, render and route models that use them. Areas are fine with > side accesses, but not top and bottom accesses. > > > Regards, > > > Peter > >
_______________________________________________ Talk-transit mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-transit
