You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For integrating the public transport data of Esteli, we had a similar starting point: schedule information (mainly) given in frequency information. I've worked on @xamanu's script to be usable in different regions and with different requirements. The last version is published in mapanica/easy-timetable-converter and was done thinking of a possible latter integration into osm2gtfs. After merging in #99, we could discuss the support of a second schedule source format (see my specification here).
The text was updated successfully, but these errors were encountered:
It's also worth mentioning the GTFS frequencies.txt, which is an alternative source of time information for exactly the situations described above. We should discuss whether to include the above mentioned script which processes the frequencies to our known timetable.json format (and than into stop_times.txt or to generate with the help of transitfeed this frequencies.txt.
Reasons for integrating the script:
would be much easier to include, because the script is already working and we wouldn't need to rewrite some core functions
frequencies.txt is optional and might not be implemented/read by all GTFS consumer programs
Reasons for generating the frequencies.txt:
GTFS filesizes would be less big
standardized way of giving frequencies inside GTFS
For the creation of Managua's
timetable.json
, @xamanu wrote a little script to convert frequency data to the current schedule format specification.For integrating the public transport data of Esteli, we had a similar starting point: schedule information (mainly) given in frequency information. I've worked on @xamanu's script to be usable in different regions and with different requirements. The last version is published in mapanica/easy-timetable-converter and was done thinking of a possible latter integration into osm2gtfs. After merging in #99, we could discuss the support of a second schedule source format (see my specification here).
The text was updated successfully, but these errors were encountered: