[Talk-transit] Proposed changes to oxomoa schema [part 1]

[Michał Borsuk]

On 29 June 2010 07:29, Roland Olbricht <roland.olbricht at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20100629/03b09aba/attachment.html>