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
_______________________________________________
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit
