[Talk-transit] Mapping standard: how to make a standard that is easy to learn, use and fast to implement

[Michał Borsuk]

On 01/11/2011 08:53 PM, Michał Borsuk wrote:
> Hello everybody.

Now to what I'd change in the proposal:

>
> 1. Data consistency
> Data consistency (not having a myriad of standards) is important,

...but it's not everything. Reaching this point to near 100% will cost 
us the points below. I strongly suggest that we "let go" some quality in 
exchange of gaining on the points below.

Think about it, the final result will be a matematical product of all 
five points, not only of the first one. I'd rather have 10'000 bus lines 
mapped to 99% accuracy, then 1000 lines mapped to 99,9% accuracy. I 
monitor bus lines in my area, and find it much easier to review and 
correct 10 new bus lines by newbies, than enter one bus line myself. 
(Well, maybe three).

> 2. sensible "learning curve"
This point will have to be addressed as the last one, after "efficiency".

> 3. efficiency

Now for a bit longer rant:
The point of having very exact data is, among others, to have timetables 
in the future. Am I correct?

I have looked at the source data of a few companies, both in Europe 
(hafas), and in US (Google Transit). The actual data is FAR MORE 
COMPLICATED than you can imagine. Buses may have "early morning Sunday 
runs" that aren't probably mapped in OSM, because nobody noticed them. 
Many more exceptions. OSM would probably have to take the day of the 
week and time of the day into account. It would be nice to have this 
data on OSM, but at this moment I *really* don't see this happening.

Also, OSM seems to be in a kind of a beta state in many places. Not far 
from my place there's a town of 20 thousand, that has three streets, and 
the bus terminal, thanks to yours truly. (And lots of buildings thanks 
to French Cadastre. But no streets.)

So in my opinion there is not so much sense caring for super correct 
data structures like our proposal provides, but to get on the map as 
many lines as possible, in the quality that we have now. It is in many 
cases sufficient! So what that the same bus stops at stop A in both 
directions? There's the printed timetable at the stop, there's 
Hafas/Google Transit online. For the user with GPS it matters that 
he/she found the bus stop.

To the point:
* I'd drop the requirement to have one relation in each direction. Not 
user friendly, not really necessary. As I said, the bus diverts, doesn't 
go the same route in both directions? If it's a one-way street, ignore 
it. Otherwise set a label, or "role", and don't worry about it. 
ÖPNVkarte already displays it well.

* drop the mother relation with it. Again, not user friendly, and 
"normal" people don't like B-Trees (e.g. nested relations - it would be 
two-step nested relation).

* another point to dropping the relations is: leave the thinking and 
sorting to machines. Label (use relations) what is not standard, i.e. 
runs on different streets, and leave it to Melchior Moss' superb map to 
deal with. He managed, didn't he?

* bus stops: pardon le mot, but who cares where the stop_point is? 
People wait at bus stops. I'd scrap it. Surely this will introduce an 
inconsistency between buses and trams, but this can be solved.

* things like RER: for one line there is a central station, and a number 
of terminuses (termini). The entire schematic for *one* line looks like 
a Christmas tree. If we were to provide a relation for each possible 
destination and back, it would easily produce 10, 12 or more relations, 
nested in another relation. Again, what for? What do we want to achieve 
by this? If we want to get a timetable for a stop, there's the stop 
code, which can be entered into the local online timetable, and there 
you go. Example:

Bus stop name=Pieper stop_id=40028
http://www.openstreetmap.org/browse/node/906491624
Corresponding HAFAS page:
http://www.vgs-online.de/cgi-bin/stboard.exe/dn?input=40028
here's the stop ID:                                   ^^^^^^

Simple and easy, and I've been using those codes on my telephone (opera 
mini). It's easier to type "12613" than "Beim Weisenstein". It would be 
even easier if somebody could write a simple extension to OSM to 
automatize it.


> 4. usability with present software

I think we can assume that a lot of edits are done by small, one-time 
users (Pareto principle again). Those guys are not going to download 
JOSM, a piece of software requiring another download (Java), just to 
learn it and put one bus line. Are we ready to cut off a majority of 
small users by introducing something that they can't do with Potlatch? 
(Potlatch 2 doesn't provide all the required tools for this proposal)

> 5. Info page on wiki


The existing mess was quite recently turned into a standard of its own 
by a discussion on this list/newsgroup. Why don't we get back to it, 
make a website and just update a few things, instead of reinventing the 
wheel?

Greetings,

LMB