Transport data
Settings → Transport data (also linked from the setup wizard) manages
sources separately from street regions. The initial reviewed catalog contains
VBB for Berlin/Brandenburg. Search by country, region or operator, or add an
HTTP(S) GTFS ZIP and an optional matching GTFS-RT TripUpdates URL manually.
The catalog lives in app-phoenix/priv/transit/providers.json; entries include
coverage, attribution, commercial-use conditions and the date of verification.
Connecting saves a selection. Download & apply downloads selected feeds and rebuilds only the selected, enabled transit engine, if its street input exists. It does not download PBFs, change the Settings region draft, or enable both engines. The wizard downloads connected feeds during its transit installation. Until a source selection is configured, existing region-preset GTFS behavior is retained. Once configured, that selection replaces the engine's automatic ZIP discovery; old cache files remain on disk but disabled sources are excluded from both engines.
Static updates are manual by default. Daily updates opts into a 03:00 UTC refresh, serialized with other regional installations. A source update can take the transport engine offline while its graph rebuilds. Live updates are polled by the selected engine every minute; no application API request is sent directly to the provider by the browser.
Downloads use temporary files and check ZIP readability and required GTFS table names before replacing a cached file. This is a structural check, not a full semantic GTFS validator. An invalid or unavailable download preserves the prior file for that source URL and records a warning. Engine import can still reject semantically invalid data. Matching realtime trip IDs and actual realtime health are not verified by the catalog UI. Live updates configured describes the configuration, not guaranteed realtime coverage. Disabled sources show live updates as inactive. Directions displays the per-leg status returned by the selected engine; live vehicle positions are not shown.
An optional HTTP header supports API keys, applied to this source's static and
realtime URLs. Credentials are held in the server Settings database and generated
engine configuration, never redisplayed in the form. Treat the database and
data/otp as sensitive. MOTIS/OTP must have permission to read the generated
configuration (default deployment uses the same runtime UID/GID). Keep the key
field blank while editing to preserve it; use Remove saved API key to clear it.
Managed files are data/gtfs/atlas-feeds/*, data/otp/atlas-feeds/*,
motis-datasets.yml, atlas-sources.json and managed sections of
build-config.json / router-config.json. Persistent source IDs namespace the
same feed in MOTIS and OTP. A changed GTFS URL gets a separate download cache,
so an old provider's ZIP is never mistaken for its replacement.