On Fri, Jan 14, 2011 at 12:30 PM, Michał Borsuk <[email protected]> wrote: > But if this IS really an issue, how about treating tram where it doesn't > have a right of was as a bus, and where it operates on separate track, as a > train? This will be confusing to new users IF they don't read the manual > (they will see two seemingly different systems for one tram line), but this > has a valuable advantage: it fits the German Stadtbahn - Karlsruhe mode > anybody?
Karlsruhe tags the infrastructure as tram, light_rail or rail, and the relation as S-Bahn (light-rail). >> Mapping variants of PT lines is indeed close to impossible if people still >> enforce the "one relation for one line" mantra. > > Again, how about roles? Why don't we try to use them? it seems that they > have been largely abandoned. But from the point of view of a non-geek roles > are easier to grasp than separate routes. Again, how do you copy a route in > Potlatch? The hard way - click on each way and copy relation memberships from the previous way. And then sort out relations/roles you've copied by mistake. I sure hope that gets fixed in P2. > As for roles vs. two relations, I mean to introduce arbitrary roles for > "legs" of strange bus/tram lines. Let the user call the "leg" where a bus > calls on Sunday mornings "Sunday morning service only". This is pefectly > enough for the rendering software, and as for routing software, I've > expressed my doubts (but it should be also enough - those roles can be > indexed). I think one relation for both directions is reasonably achievable and simple (assuming P2 will allow a way to be a member at two positions in the ordered list). This will allow many routes to be one service / one relation. I think roles for branches is prone to problems (you end up with "roles" being used for more than one purpose, which is asking for trouble). In my case I had a route with four branches (4,4A,4B,4C). Four relations, four ref= tags. Painful to do in P1, but conceptually quite simple. The only problem from my point-of-view is that each service has a pathetic frequency, and I've no way of pre-processing an aggregate frequency for the core section. But then I've no way of adding the frequency of other services (S1, U1, 400) on the core section either, so it's a problem that will need a more general solution, anyway. 4B had a Sunday-only variant which I just ignored. If I were ever to map it, I'd put it in as a separate relation and put days of operation in the two variants (do we have a tag for that?). I might also want a tag on the relation such as operation=normal|variant|??? to help renderers pick out the "normal" ones for rendering. The basic approach is to aggregate simple components. It's always easier than disaggregating complex components. Richard _______________________________________________ Talk-transit mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-transit
