Migration to Ara SaaS
This page helps you prepare your migration to Ara SaaS. From a business standpoint, Ara is a real-time data concentrator: it collects your sources and re-broadcasts them to your consumers. Preparing means listing both sides — your sources (inputs) and the third-party services to feed (outputs) — then planning your reference data (stops, lines, vehicle journeys).
Current setup audit
As a new Ara SaaS user, what should I prepare?
List your data sources
Ara can import data in several formats / standards: SIRI and GTFS-RT. List each source with its key elements:
Provider (PTA, city, opendata…) | Source (feed / system name) | Format (SIRI / GTFS-RT) | SIRI services (e.g. StopMonitoring, EstimatedTimetable…) | Mode (request / subscription) | Flow type (SIRI Lite / SIRI SOAP) | Code space of identifiers | Access (URL + token) |
|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
The SIRI services, Mode and Flow type columns only concern SIRI sources. The flow type distinguishes SIRI Lite and SIRI (SOAP) — Ara supports both. The code space and access prepare the partner configuration in Ara (remote_code_space, remote_url, credentials).
Qualify your real-time data
The imported data must comply with the format of its standard. Ara reads as much information as possible but is not a validator for SIRI or GTFS-RT. To get the detailed errors of a file, use dedicated tools:
GTFS-RT validator: https://transport.data.gouv.fr/validation?type=gtfs-rt
SIRI schemas / validation: https://bitbucket.org/enroute-mobi/siri-xsd/src/master/ (XSD repository)
Internal organization to produce your data
Real-time data production is organized differently depending on your structure and the actors involved. For each source, define:
the owner: who produces and maintains it;
isolation: should this source be isolated in its own Ara referential (rather than shared with others)? Useful when it has distinct governance (different actors / owners), confidentiality constraints, or can be brought online or removed independently of the others.
List the third-party services to feed
List your needs to feed third-party services, specifying the expected format. Ara can feed third-party services via GTFS-RT, SIRI or SIRI Lite.
Third-party service (passenger app, Open Data, data.gouv…) | Expected format (GTFS-RT / SIRI / SIRI Lite) | Access (URL + token) | Notes |
|---|---|---|---|
|
|
|
|
Consistency between theoretical and real-time data
Ara works on models — stops, lines, vehicle journeys, operators (see Ara's models). The key migration question: how are these models populated, and do they stay consistent with your theoretical data?
If you manage your theoretical data in Chouette SaaS — this is the whole point of Chouette + Ara: keeping theoretical and real-time data consistent (same identifiers).
Chouette feeds Ara: an “Ara export” publication (operators, stops, lines, vehicle journeys; choose lines by provider, company or list) is sent via an “Ara SaaS” destination — URL of the Ara referential + identification token.
The identifiers of the real-time flows (SIRI / GTFS-RT) must match the theoretical codes: with a GTFS / GTFS-RT pair they generally coincide; with SIRI flows (or NeTEx sources), the mapping is handled via code spaces.
👉 Everything is detailed in Manage Real-Time codes with Chouette.
Without theoretical data (Ara only) — Ara builds its models from the real-time flows themselves: in SIRI via StopPointsDiscovery / LinesDiscovery requests (for sources that expose them), and directly from the content of GTFS-RT flows for sources collected in GTFS-RT. No consistency mapping needed.
What's next?
Once this audit is done, move on to configuring Ara:
Ara Guides — concepts and setup of exchanges (collect / broadcast, SIRI / GTFS-RT);
Ara User Manual — create and manage your exchange Partners and your Code Spaces; view your stops / lines / vehicle journeys.