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 [email protected] https://lists.openstreetmap.org/listinfo/talk-transit
