Continuing on "How routing software works (and why OSM as-is is not
ready for routing)":
Coming back to the mapping of bus lines in OSM: you can see now that
what is presented to the user, as in the example before (the PDF
http://tisseo.fr/sites/default/files/Tisseo_hiv16web.pdf), is a
cut-and-formed representation a level higher in the abstraction schema
above the actual data. It is done for historical reasons, because
printed maps did so, and users are used to it. The only reason to
implement it in OSM would be "historic". Why go backwards? OSM doesn't
have many of the limitations of printed maps, but the way it stores data
isn't suitable for storing full timetable information.
So my proposal is: since we can't provide all the necessary information,
why not go even higher towards simplicity at the cost of such details as
"bus in this street goes one way", and *just* provide the trace of the
bus line, with all its variants, as one line on the map? All other info
would be provided by routing software.
All we need is to point the user to the place where s/he can find actual
routing information. Users don't care which way a line goes in the
street, but where the bus stops. A pair of unique stop_id tags is all is
needed to create a route for the user. Not stop areas, and not the exact
bus runs - because we can't store them exactly enough.
Here's how I'd store data in OSM:
(let's say Simple Public Transport Schema)
Level 1: minimum requirement (for beginners, not really encouraged, but
allowed).
* stops are entered at their actual location (pole =>
"highway=bus_stop", or for railborne vehicles: platforms, optionally poles)
* bus lines are entered as a single relation covering all
versions/variants, without any roles
* relation describing the bus line contains at least the ref=tag
Level 2: optimum requirement, will allow routing extension: contains the
above, plus:
* from= and to= tags are added to the line relation (in order for
routing software to be able to match a bus stop with the direction of
the bus that stops there)
* if there is more than one terminus, we separate them with "/", e.g.
"to=Saint-Denis – Université / Asnières-Gennevilliers-Les Courtilles"
* stops/platforms are added to the line relation. Note that for the
railbolne vehicles, actual platforms must be added to the relation (see
below).
* stops contain a unique stop_id. All stops with the same name may
contain one stop_id (because they are usually stored in routing software
as one entry), but must contain backward_stop or forward_stop role on
stops or platforms (in order to be able to tell whether the user is
waiting at the correct stop/platform, and not its equivalent on the
opposite side of the street).
* forward_stop is a stop that is on the way from=terminus to to=terminus
* network= tag shows which network the line belongs to.
* other tags, such as color=, etc. remain unchanged
Level 3: advanced features (open for discussion)
* relation is part of a mother relation holding all relations within the
same network (optional, but encouraged)
* operator= tag shall be optional (do users care who drives the bus if
the ticketing system is the same all over the network?)
* Both Google Transit and HAFAS provide information on pairs of stops
that are intended to be transfer points, which was expressed as
"stop_area" in oxomoa, but in my opinion this is not necessary: OSM
contains the actual distance between stops, so whether two transfer
stops have the same name, or belong to the same stop_area is unimportant.
* Amenity=bus_station: I would keep this tag. OSM is a map, and a large
bus station differs from a mere pole in the street. Whether
Amenity=bus_station contains bus stops or platforms is to be discussed.
HOW THIS WOULD BE RENDERED: Same as now, except that öpnvkarte.de
wouldn't be able to show one-way routes (this didn't work anyway, when
two one-way routes run in opposite direction, as here:
http://www.openbusmap.org/?zoom=18&lat=49.26833&lon=7.10952&layers=BT)
More on compatibility and routing based on this proposal in next post.
Greetings,
LMB
_______________________________________________
Talk-transit mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-transit
