On 29 June 2010 07:29, Roland Olbricht <roland.olbri...@gmx.de> wrote:
> > those two would meet in point A, from which the branch line sets > > off/rejoins the core line. So a hypothetical future route-finding > > algorithm would follow different_route to its end, upon meeting core > line > > it would continue along. > > It just doesn't work. Having an unordered relation or even mapping both > directions within the same relation leads to ambiguities. Just two > examples: > > http://www.openstreetmap.org/?lat=51.29314&lon=7.21791&zoom=17&layers=B > > <http://www.openstreetmap.org/?lat=51.29314&lon=7.21791&zoom=17&layers=B000FTF> > Bus service 618 southbound comes on the "Gennebrecker Str." from the north, > loops into "Agnes-Miegel-Straße" and then proceeds on the "Gennebrecker > Str." > to the south, always. 618 northbound passes on the "Gennebrecker Str." from > south to north only. > >From where the line split, point 768803020, to where they meet again, 768803016, they would be tagged "backward" and "forward", or any other appropriate pair of tags. Judging by the direction, routing software would either follow one or the other. > > > Now I would like to see how you discriminate this case from the case where 618 passes through the loop in both directions (so does line 624) if you don't > have an ordered relation. > > I'm not completely sure what you mean without seeing it graphically, but logically I cannot see what can't be done by tagging that is now done with two separate routes. The question is whether it is easier to enter and manage, and I maintain that tags are easier than two relations. > In Oxmoa it is very simple: you map what the bus does. > It is simple as a data structure, but neither simple nor efficient for the user. In the 21st century software is adjusted to users, not users forced to adjust to software. What I am opting for is simpler machine-user interface, easier experience for users. What it is now is clearly a mess. Look at the number of amendments made to my original post: all that info is probably somewhere there, but how does a beginner find and compile it? > Second example > > > http://www.openstreetmap.org/?lat=51.255881&lon=7.150008&zoom=18&layers=B000FTF > Line 643 passes in both directions from "Morianstraße" on the left to > "Islandufer" on the right. But in eastbound direction, it passes through > platform 5, in westbound direction is passes through platform 4. This is > important, because buses in both directions are at the stop at almost the > same > time. In Oxmoa, it is again simple and intuitive: > Raw XML simple and intuitive? We may be speaking a different language here. I am talking about user experience. User = map editor. Not a programmer by definition. > Second example > > <http://wiki.openstreetmap.org/wiki/Opening_hours> > http://www.openstreetmap.org/?lat=51.255881&lon=7.150008&zoom=18&layers=B000FTF > Line 643 passes in both directions from "Morianstraße" on the left to > "Islandufer" on the right. But in eastbound direction, it passes through > platform 5, in westbound direction is passes through platform 4. This is > important, because buses in both directions are at the stop at almost the > same > time. > Not difficult. You'd put "direction_to" and "direction_from" tags to the bus stop and the route. Same goes for lines with variants, you can have forward_variant_a, backward_variant_a, forward_variant_b, backward_variant_b. Believe me, "my" Verkehrsverbund is not any different from "yours". We face the same problems. > Nonetheless, there are still things that Oxmoa leaves open. For example, > there > is no specification how to store approximate journey time. But the usage of > ordered relations and the separation of directions is one of the strengths > of > Oxmoa, not a weakness. > Please convince me that tagged routes are more difficult than dealing with a nested collection of multiple routes. Possibly I am misled in my belief that editing/rerouting multiple variants as multiple relations is just time-consuming. For me now the system seems unnecessarily complex. B-trees are not easy to comprehend to common users-editors, who are not, by definition, programmers. > Concerning Potlatch ... It's just not open. You can easily contribute to > JOSM > by writing a plug-in or even submitting a patch. Potlatch makes the life > for > the programmer much more difficult; This is about editors, not programmers. > > > I'd suggest that we use the discussion page > http://wiki.openstreetmap.org/wiki/Public_Transport > of the wiki once the server is back again to write a consistent, > easy-to-use > and easy-to-implement standard. > I second that opinion. Email exchanges are a bit difficult when they grow. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk
_______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
