First of all, it's great to see that the list comes back to life again. I hope
we can use
the enthusiasm to solve some of the problems that have hade public transport
mapping so
tedious.
One of the core issues is that there are very different concepts of what makes
up a bus
service.
In the cities, bus routes almost always have fixed routes and run every few
minutes: An example is the bus route 26 in London:
http://en.wikipedia.org/wiki/London_Buses_route_26
These services aims to be easy-to-use for tourists and other strangers.
In the countryside and some small towns, bus services are merely a collection
of school
services. These services often aren't useful to anybody else than the pupils
using it.
Other types may exist as well. Think for example of shuttle services to ferries
or to
airports. They may run far fewer than a busy bus service in London, but they are
straightforward useful to all ferry or airport passengers. The urban services
also
tend to be long-term stable, line 26 for example since more than 20 years.
A first step would be to clearly distinguish these different types of bus
services,
and the best I can offer so far would be the subjective criteria if I would
suggest a
stranger to use that service without knowing the time table: I would encourage
to use
line 26 instead of a car, but discourage to use an arbitrary school service
instead of
a car.
I also claim that mapping these urban services is much more useful than mapping
school
services, hence tools should make at least adding these urban services as
simple as
possible. There is unfortunately less value in adding school services to OSM,
because
the general public cannot replace their car use by them anyway, regardless if
they
change frequently or not.
The state of affairs is that at least the JOSM relation editor handles such
relations
well, including splitting ways with multiple relations on it (I've just tested
with
35 bus services on a way, and it worked without notable delay). We should keep
in mind
that urban model simply works and do break things here.
Other editors have better chances to get to the same level of comfort if the
data model
is simple. And the simplest form is indeed: one relation per route and
direction, stops
and ways added in the order of service.
Does it make sense for me to elaborate on this and invest time into an actual
proposal?
Actually no. None of the above listed problems would be solved by yet another
proposal.
Proposals help if and only if there are already mulitple conflicting usage
patterns around
and the proposal process would offer the forum to bring proponents of all sides
to an
agreement.
They don't help if the problem is to choose a data model and to implement it in
software.
To make a good data model choice the best way is to collect as much examples as
possible
to check whether proposed data models does cover them and to implement them in
software.
This helps to understand whether a data model is really simple or just
simple-looking.
The sub-relation proposal is an example for simple-looking:
The code to figure out whether a given relation is a bus route and how to order
it for
the line diagram generator
http://overpass-api.de/public_transport.html
is already more than 2000 lines long.
Adding support for sub-relations and doing something sensible in all the
various error
cases will add some hundreds or thousands of lines, precisely because there is
plenty
of opportunity to create maybe-errorneous route relations with a more complex
data model
that you have to deal with a a software developer.
Requiring a routing capability is even worse: Implementing an A* algorithm that
does
the core routing is not the hard part. The hard part is to choose which kinds
of way to
take (sometimes buses may pass through pedestrian areas, sometimes not,
sometimes against
one-way routes, sometimes not), because you have a good chance to get several
kilometers
of bogus deviations if you wrongly exclude a way that's actually allowed, and
tagging
practices do subtlely differ between different local communities.
So I'm happy about the initiative, but yet another pile of prose text doesn't
make a tool
for mappers. By contrast, I would love rather an approach that has a chance to
work:
Let us collect a structured set of examples and then write code that can handle
all these examples.
This gives at least the chance that mappers, software developers and data users
all have a
chance to adopt the data model.
Best regards,
Roland
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit