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