Default implementation for TripCreator with frequency support

[nlehuby]

We should allow the default TripCreator to work without schedule data and then generate a GTFS with a frequency.txt file that only uses OSM data.

Even if it won't fit all needs, it will allow to create very easily a first GTFS from OSM data that could even be usable for some simple cases (long distances buses with low frequency, ferries and shuttle bus, subways with high frequency, etc)

We can use

• the interval OSM tag to get the frequency : https://wiki.openstreetmap.org/wiki/Key:interval
• the opening_hours to define the stop time at the first stops
• the duration key (and the GTFS interpolate stop time utility) to deduce times at each stops

The Accra creator is a good start to implement this as it already does that. Well, almost :

• it has its opening_hours hard coded
• it uses travel_time tag instead of duration and frequency tag instead of interval
• the tags are read on either the route or the route_master (we should to be smart enough to handle both)
• the conditional part of the interval tag is not supported

[pantierra]

Currently the standard trips creator uses a kind of standartized time table input format, with the idea to cover all possibilities. In Managua we also have frequency/interval based data, we just converted it to the timetable format with a simple script. Your proposed direct interval approach is surely a simplification, which is interesting.

Is your proposal to remove the timetable input and to replace it with the interval approach? Or do think on supporting both? In the latter case, how do you suggest to differentiate between the two?

[ialokim]

converted it to the timetable format with a simple script

Just for reference, you can find it here. I think back then we went for the standard stop_times.txt approach as the frequencies.txt information seemed to be not fully supported by some GTFS consumers (?). There was also the idea of integrating the script into the osm2gtfs code.

to differentiate between the two [approaches]?

I would say, if the schedule_source key is present and set within the configuration (as e.g. for Estelí), it would use the already available standard approach. If it is not present, osm2gtfs could automatically use the schedule information from OSM or dump default values if there is no information on OSM either as proposed in #118.

[nlehuby]

:+1: fully agreed with @ialokim:

• if schedule_source is provided, use it as it currently works
• else if interval and duration tags are set in OSM, use them
• else use default values to generate a dumb GTFS anyway

[prhod]

Very nice idea :+1:

[nlehuby]

The ci_abidjan creator implements this and can be used a basis to add this feature in the default implementation.