Feature Request
Description
Hi @aubryio, really cool project that unlocks a lot of possibilities.
I am experimenting with Cykel ombord, a Swedish public-transport route planner for journeys where a traveller brings an assembled bicycle. Sweden has good public GTFS data, but bicycle-carriage metadata is incomplete. The bicycle rules are known per operator and are also compiled in a public guide, so I encode those rules and prune the national GTFS feed to only explicitly bicycle-compatible services.
I then use Minotor to compile date-specific timetables for a static website. The browser downloads only the timetable for the selected date and runs routing locally. The whole pipeline can therefore run on GitHub Actions and publish to GitHub Pages without a routing server.
The pruned GTFS feed is small (about 1.5 MB compressed), and each resulting timetable is roughly 200–500 KB. I currently publish a rolling 90-day horizon, and may extend it to 180 days or more.
Today I invoke the CLI once per date:
minotor parse-gtfs bike.gtfs.zip \
--date 2026-08-09 \
--timetable-output-path timetable-2026-08-09.bin \
--stops-output-path stops.bin \
--virtual-transfers-radius 500
On the Github runner, one date takes about 1.2–1.5 seconds. The current CLI parses the GTFS ZIP for each invocation, including the static tables, then writes the shared stops index again. Generating 90 dates serially is consequently a material part of a daily GitHub Actions build; doubling the horizon doubles that cost.
Proposed Solution
Could Minotor offer a batch mode that produces several date-specific timetable binaries from one
GTFS parse? For example:
minotor parse-gtfs-range bike.gtfs.zip \
--from 2026-08-09 \
--to 2026-11-06 \
--output-directory dist/router \
--virtual-transfers-radius 500
Suggested output:
dist/router/
├── stops.bin
├── timetable-2026-08-09.bin
├── timetable-2026-08-10.bin
└── ...
An equivalent library API would also be useful, for example a parser method that accepts an iterable of dates and returns or writes a timetable per date.
The important property is that feed-level work is reused where safe: opening the archive; parsing stops, routes, and other date-independent GTFS tables; and constructing the stops index. The date-specific work—resolving active service IDs, filtering trips, and serializing each timetable—can still run once per date.
A future implementation might also parallelize independent per-date assembly with a configurable concurrency limit.
Alternatives Considered
Since I am pruning the GTFS feed so heavily, weekly binaries would probably also be OK. But that might bring issues that I have not foreseen
Feature Request
Description
Hi @aubryio, really cool project that unlocks a lot of possibilities.
I am experimenting with Cykel ombord, a Swedish public-transport route planner for journeys where a traveller brings an assembled bicycle. Sweden has good public GTFS data, but bicycle-carriage metadata is incomplete. The bicycle rules are known per operator and are also compiled in a public guide, so I encode those rules and prune the national GTFS feed to only explicitly bicycle-compatible services.
I then use Minotor to compile date-specific timetables for a static website. The browser downloads only the timetable for the selected date and runs routing locally. The whole pipeline can therefore run on GitHub Actions and publish to GitHub Pages without a routing server.
The pruned GTFS feed is small (about 1.5 MB compressed), and each resulting timetable is roughly 200–500 KB. I currently publish a rolling 90-day horizon, and may extend it to 180 days or more.
Today I invoke the CLI once per date:
On the Github runner, one date takes about 1.2–1.5 seconds. The current CLI parses the GTFS ZIP for each invocation, including the static tables, then writes the shared stops index again. Generating 90 dates serially is consequently a material part of a daily GitHub Actions build; doubling the horizon doubles that cost.
Proposed Solution
Could Minotor offer a batch mode that produces several date-specific timetable binaries from one
GTFS parse? For example:
Suggested output:
An equivalent library API would also be useful, for example a parser method that accepts an iterable of dates and returns or writes a timetable per date.
The important property is that feed-level work is reused where safe: opening the archive; parsing stops, routes, and other date-independent GTFS tables; and constructing the stops index. The date-specific work—resolving active service IDs, filtering trips, and serializing each timetable—can still run once per date.
A future implementation might also parallelize independent per-date assembly with a configurable concurrency limit.
Alternatives Considered
Since I am pruning the GTFS feed so heavily, weekly binaries would probably also be OK. But that might bring issues that I have not foreseen