All our products have been updated on with the releases associated to the Sprint 39.
Chouette permits to publish your transport data in many formats and in many ways. If you choose an API publication, Chouette publishes automatically for you a public page to help people to consume your API.
On this page, Chouette displays now the last publication time:
The analysis of the Chouette GTFS exports leads to some improvements on the number of calendars and trips produced.
Chouette has now a smarter approach for calendar and trips generation :
For each Timetable period, we need to create a Calendar with the associated date range and the day selection. The associated included/excluded dates must create CalendarDates
.
For a Timetable with only included dates, only the CalendarDates
should be used.
For each Calendar / service_id, the VehicleJourney
must be exported into a dedicated trip.
For example:
A Timetable A on week days with two periods and a excluded date (on the first period)
A Timetable B with only included dates
A Vehicle Journey 1 which uses the two timetables A & B
A Vehicle Journey 2 which uses only the Timetable B
These models should be exported as:
A Calendar (service_id A1) for the first period of Timetable A and an associated CalendarDate for the excluded date
A Calendar (service_id A2) for the second period of Timetable A
A CalendarDate for each included dates of Timetable B (with the same service_id B)
A Trip for Vehicle Journey 1 associated to the service_id A1
A Trip for Vehicle Journey 1 associated to the service_id A2
A Trip for Vehicle Journey 1 associated to the service_id B
A Trip for Vehicle Journey 2 associated to the service_id B
Chouette displays now this object identifier with the name “full id” (or “ID complet” in French)
This information is useful for users who want to
interpret identifiers used in exports (GTFS, NeTEx, etc)
prepare API requests in GraphQL
You can now mix filters to use search by name or identifier and every filters for Stop Areas and Lines : postal code, area type, status ...
Every publication made by Chouette launches exports in a specific format. You can now consult export details for each publication:
When a NeTEx IDFM dataset has a calendriers.xml
file with several ValidBetween
tags in the NETEX_CALENDRIER
, the associated Data Set is now created the defined periods.
Example of calendriers.xml file:
<?xml version="1.0" encoding="utf-8"?> <PublicationDelivery xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns="http://www.netex.org.uk/netex" xmlns:ifopt="http://www.ifopt.org.uk/ifopt" xmlns:acbs="http://www.ifopt.org.uk/acsb" xmlns:siri="http://www.siri.org.uk/siri" version="1.04:FR1-NETEX-2.0"> <PublicationTimestamp>2019-12-12T15:49:25Z</PublicationTimestamp> <ParticipantRef>32</ParticipantRef> <dataObjects> <GeneralFrame id="STRAV:GeneralFrame:NETEX_CALENDRIER-20191212T154925Z:LOC" version="any"> <ValidBetween> <FromDate>2020-01-02T00:00:00</FromDate> <ToDate>2020-04-11T00:00:00</ToDate> </ValidBetween> <ValidBetween> <FromDate>2020-04-14T00:00:00</FromDate> <ToDate>2020-04-30T00:00:00</ToDate> </ValidBetween> <ValidBetween> <FromDate>2020-05-02T00:00:00</FromDate> <ToDate>2020-05-07T00:00:00</ToDate> </ValidBetween> |
When the user launches an Import which creates a large number of Data Sets (this is possible with a large IDFM NeTEx import) with the automatic merge option, Chouette could merge in several operations these imported Data Sets. Chouette starts now only a single Merge when the Import operation is successfully done.
We improve our Benchmark library used in the code to analyse :
processing time
memory usage
This updated library checks now every merge and aggregate operation and delivers these data directly to Datadog (our monitoring service).
Chouette dependencies are constantly analyzed to find security issues. To handle this tasks Chouette uses 2 tools :
bundler-audit : check security issues for ruby libraries
snyk : check security issues for both ruby, javascript and go libraries
These libraries have been updated in this new release :
actionview to 5.2.4.2
shoulda-matchers to 4.1.2
nokogiri to 1.10.5
Each API endpoint is now documented and public for both Chouette and IBOO SaaS:
If the user adds a dedicated GTFS-RT broadcaster to a Partner, like gtfs-rt-trip-updates-broadcaster
, gtfs-rt-vehicle-positions-broadcaster
, etc, Ara provides associated endpoints to retrieve real-time data in GTFS-RT with a simple HTTP request:
GET /<referential_slug>/gtfs GET /<referential_slug>/gtfs/trip-updates GET /<referential_slug>/gtfs/vehicle-positions |
The user can select the expected GTFS-RT entities by using one of the GTFS-RT endpoints:
Global endpoint /<referential_slug>/gtfs
provides all entities.
Trip Update endpoint /<referential_slug>/gtfs/trip-updates
provides only Trip Update entities.
Vehicle Position endpoint /<referential_slug>/gtfs/vehicle-positions
provides only Vehicle Position entities
The user can specify a credential in the GTFS-RT request by using an HTTP header Authorization
with this syntax : for secret
token, Authorization: Token token=secret
GET /<referential_slug>/gtfs Authorization: Token token=secret |
If a token is given into the GTFS-RT request, the Partner associated to the request will be find by local_credential
.
If no token is given into the GTFS-RT request, the Partner without local_credential
will be associated to the request.
The GTFS-RT response contains a Feed Message structure as described in the GTFS-RT reference.
The following content is managed by Ara:
FeedMessage
FeedHeader
Incrementality
FeedEntity
TripUpdate
TripDescriptor
StopTimeUpdate
StopTimeEvent
VehiclePosition
TripDescriptor
Position
All GTFS-RT responses respect this structure.
The TripUpdate entities are provided only if the user request selects them and if the gtfs-rt-trip-updates-broadcaster
is associated to the Partner.
The VehiclePosition entities are provided only if the user request selects them and if the gtfs-rt-vehicle-positions-broadcaster
is associated to the Partner.
Complete example (in pseudo json content):
{ "header": { "gtfs_realtime_version": "2.0", "incrementality": "FULL_DATASET", "timestamp": "1580136888" }, "entity": [ { "id": "trip:281721", "trip_update": { "trip": { "trip_id": "281721", "route_id": "3001I", "start_time": "16:36:00" }, "stop_time_update": [ { "stop_sequence": 1, "departure": { "time": "1580135775" }, "stop_id": "1020503" }, { "stop_sequence": 2, "arrival": { "time": "1580136050" }, "departure": { "time": "1580136050" }, "stop_id": "1174501" }, { "stop_sequence": 3, "arrival": { "time": "1580136234" }, "stop_id": "1250501" } ] } }, { "id": "vehicle:943", "vehicle": { "trip": { "trip_id": "281721", "route_id": "3001I", "start_time": "16:36:00" }, "position": { "latitude": 60.27628707885742, "longitude": 24.856653213500977, "bearing": 133 }, "vehicle": { "id": "943" } } } ] } |
The completed specifications of the response contents are available in the Ara GTFS-RT Broadcast documentation.