[Talk-transit] Public transport time information in OSM

Felix Delattre felix-lists at delattre.de
Mon Oct 31 09:54:31 UTC 2016

A great conversation about public transport time information in OSM is
coming out of a different initial question! Therefore, I'm taking the
liberty to group all information about this new topic and change the
subject line. My answers regarding this topic can be found below
everything else.

On 30/10/16 23:39, Jo wrote:
> 2016-10-30 21:27 GMT+01:00 Greg Troxel <gdt at lexort.com
> <mailto:gdt at lexort.com>>:
>     Felix Delattre <felix-lists at delattre.de
>     <mailto:felix-lists at delattre.de>> writes:
>     > 3. An actual tour a bus takes, on a certain time
>     > In OSM" not existen; in GTFS: "trip"
>     It makes sense to use "trip" in GTFS, and it makes sense that this is
>     not in OSM because we don't represent that level of information.
> Indeed. 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.

On 31/10/16 10:05, Roland Olbricht wrote:
> 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

Very interesting, Roland! My background is more about public transport
systems in developing countries, and that is why I'm very interested
also in what you call the "metropolitan model". As you probably can
imagine, this "frequency based" time information is also widely used for
(more) informal transit networks.

We crowd-sourced the transit network of Managua, Nicaragua in OSM and
also the time information based on frequencies. Those, obviously are
living in a separate table document. We want to have made and want to
continue to create useful products out of the data (paper map, simple
web app and now GTFS for routing in OpenTripPlanner and Transportr) and
the reason why we are working on osm2gtfs, is to combine OSM data with
schedule information of different nature/models to generate GTFS out of
it. We are also very interested in frequency based routing (playing
around with GTFS' frequencies.txt) and an Open place to store time
information for public transport.

As far as I have understood, the discussion of having time information
in OSM has been going back and forth for years. And I'd also be a
supporter of having this model included in OSM.

But - another idea - what about storing public transport time
information separately, but also with an open license? OSM is not just
the core project, there are so many good solutions in the bigger OSM
family (See the routing engines, JOSM, export tool, openaerialmap.org,
etc.. long list here). We could be a lot more flexible in a project
dedicated to store time information based on OSM stops (osm_id would be
the good identifier): I'm thinking about a (web) service, provide a
database instance, with an easy REST API to store and query data,
probably some editors (web interface, JOSM plugin,...). We could query
OSM public transport stops (by osm id), put them into the database and
add/edit time information on it collaboratively, implement imports and
exports (GTFS) and different schedule data models. Of course I'm
describing it very simply, but the basic idea is: Why fight to have it
inside the OSM data model, if we could create a decent service around it?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20161031/149fdb2e/attachment.html>

More information about the Talk-transit mailing list