Hi all,
1. A general public transport service (e.g. No. 38):
In OSM: "route_master" in GTFS: "route"
For me that is a line. It has a line number. (which sometimes is not simply
numeric, so it's more of a symbol, but OK)
2. A theoretical tour a bus takes, but without schedule information, it
represents one each for different direction, but also if one is shorter
than the other
In OSM: "route"; in GTFS: /not existent/
I would call those itinerary. If OSM had started out with that term, we
wouldn't have the ambiguity today. But route is used for foot/bicycle/horse
and PT itineraries. For PT I resorted to call them route variations, but
they are 'represented' by route relations in OSM.
3. An actual tour a bus takes, on a certain time
In OSM" not existen; in GTFS: "trip"
[..] If we could figure out a way to represent it anyway, I think it
would be a plus. But I won't be holding my breath.
I fully support that wording.
But I would like to point you to another problem that has kept and is keeping
OSM PT painful:
There are two very distinct underlying data models in use by the transit
agencies.
The metropolitan (line based) model looks like subway lines usually look:
The full schedule is essentially modeled by the itineraries plus the list of
departure times per itinerary.
This works because all trips have the same set of stops and approximately the
same travel time.
If there are many trips per itinerary then there might not even be a fixed list
of departure times but just a defined departure frequency,
like
05h48 06h00 then every 2 to 5 Minutes 19h00 19h13 19h28 ...
That is all you need to know. Frequencies depend on the hardware (signalling
limits, number of vehicles for the line).
Thus they usually persist for years or decades. First and last times depends on
the habits of the local users and
therefore also persist usually for years. It would make sense to have that
information in OSM.
The rural model, also often used for long distance service, looks like school
buses:
Different trips may vary wildly, and times fluctuate quite often. A useful data
model would have to capture not only an itinerary for each single trip, but
also the operating dates.
This is out of scope for OSM, because it is ephemeral.
Nonetheless, trips have a line number that is displayed.
Operations based on the metropolitan model tend to be attractive for passengers
from the general public.
Operations based on the rural model tend to be cheap for the agency.
This is why it is a political issue to tell a local community that their public
transport network is too rural for OSM.
Long story cut short:
I would suggest that you keep a structure for unassigned trips in your
intermediate data structure, even if that is not filled from OSM.
If you want to fight for timetable data according to the metropolitan model in
OSM, then you have my support.
But a lot of people have tried that years ago and each eventually resigned.
There is quite a vocal part of the community concerned with more rural-style
services, and they have defeated so far all apporaches to metropolitan style
information to OSM.
Best regards,
Roland
--
Dr. Roland Olbricht
MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: [email protected], www.mentz.net
Sitz der Gesellschaft:
Grillparzerstraße 18, 81675 München
Geschäftsführer Dr.-Ing. Hans-J. Mentz
Amtsgericht München, HRB 91898
_______________________________________________
Talk-transit mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-transit
