[Talk-transit] maintenance is very time consuming on public transport routes

Roland Olbricht roland.olbricht at gmx.de
Mon Dec 2 13:34:27 UTC 2013


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



More information about the Talk-transit mailing list