the bambam-gtfs crate approached the problem of modeling many simultaneous GTFS feeds by
- devising a format for a global route identifier incorporating agency, service, route attributes
- recording separate files for metadata + graph edges for each agency
this second detail has led to very complicated housekeeping when working with a sufficiently large number of agencies. for each of "edge list topology", "linestring geometries", and "schedules", we need a separate file and a separate entry in a toml file. with 800 feeds, this leads to 800 entries in the toml, for example:
[[mapping.geometry]]
type = "from_linestrings"
geometry_input_file = "/projects/mepcore/data/in/shared/rfitzger/2026-05-08-transit-model-2026-05-21-tomtom-us/edges-geometries-enumerated-1.txt.gz"
[[mapping.geometry]]
type = "from_linestrings"
geometry_input_file = "/projects/mepcore/data/in/shared/rfitzger/2026-05-08-transit-model-2026-05-21-tomtom-us/edges-geometries-enumerated-2.txt.gz"
[[mapping.geometry]]
type = "from_linestrings"
geometry_input_file = "/projects/mepcore/data/in/shared/rfitzger/2026-05-08-transit-model-2026-05-21-tomtom-us/edges-geometries-enumerated-3.txt.gz"
...
this allowed for flexibility in use of the generated datasets. if a user wanted to only take a few feeds for another TOML file, the lines could be copied over and the user would not need to re-run the data import script. however, in practice, this flexibility isn't useful, whereas bloating configs with 30k lines of duplication makes bambam configs unmanageable.
recent work in modeling gtfs-flex produced a different approach:
- devising a format for a global route identifier incorporating agency, service, route attributes (same)
- recording a single master file for metadata + graph edges for all agencies
this works fine and requires one TOML entry for edge topologies, geometries, and schedules.
the bambam-gtfs crate approached the problem of modeling many simultaneous GTFS feeds by
this second detail has led to very complicated housekeeping when working with a sufficiently large number of agencies. for each of "edge list topology", "linestring geometries", and "schedules", we need a separate file and a separate entry in a toml file. with 800 feeds, this leads to 800 entries in the toml, for example:
this allowed for flexibility in use of the generated datasets. if a user wanted to only take a few feeds for another TOML file, the lines could be copied over and the user would not need to re-run the data import script. however, in practice, this flexibility isn't useful, whereas bloating configs with 30k lines of duplication makes bambam configs unmanageable.
recent work in modeling gtfs-flex produced a different approach:
this works fine and requires one TOML entry for edge topologies, geometries, and schedules.