[Talk-transit] Naming concepts

Roland Olbricht olbricht at mentz.net
Mon Oct 31 09:05:04 UTC 2016

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,
   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,


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: olbricht at mentz.net, 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

More information about the Talk-transit mailing list