Skip to content

Important information / Changes

Planned

2024-09-09 Information event – “How to successfully switch from the TRIAS interface to OJP 2.0”

At the information event on 9 September at 10:30 a.m., we will present the most important tools and show what needs to be considered to ensure a smooth transition from TRIAS to OJP 2.0. Click here to register: https://umstieg-trias.event.sbb.ch/

Advance notice – Switch-off of the TRIAS interface in Q4/2024

We will cease operation of the TRIAS interface in the course of Q4/2024. As an alternative to TRIAS, we offer the new CEN standard OJP 2.0. An exact date for the shutdown is not yet known.

Current

2024 (History)

2024-08-29 No data update for OJP / GTFS / NeTEx

Update: Data from 2024-08-29 has been updated, but there is no new data from 2024-09-02.

The timetable data for OJP / GTFS / NeTEx has not been updated today.

2024-08-28 Update: GTFS-RT: route_id field is empty

The route_id is sent again.

Due to a programming error, the GTFS-RT feed contains empty RouteId fields, starting from 2024-08-21, but discovered only recently.

The provider’s developers are working to fix it. We hope to get it fixed soon.

2024-08-14 Resolved: Problem with GTFS-RT

The GTFS-RT service is disrupted, hardly any data is flowing. We are working on a solution to the problem.

2024-08-09 Fixed: Disruption CKAN

The data sets are available again. We apologize for the inconvenience. The APIs were not affected by the disruption.

2024-08-01 No updates on 1 August

No data updates will be performed/activated on 1 August.

2024-07-29 No updates to real-time data of traffic lights

Currently, new real-time data of traffic lights cannot be published. We are waiting for the problem to be solved.

2024-07-16 Migration of the API Gateway

We are migrating the API gateway on 16.07.2024. Unfortunately, there was an unexpected outage of the APIs. We apologize to our users.

2024-06-06 Planned maintenance work

Maintenance work will take place on 6 June 2024 between 6-8 pm. There may be brief interruptions during maintenance.

 

2024-06-03 Planned maintenance work

Maintenance work will take place on 3 June 2024 between 9pm and midnight. There are not expected to be any downtimes during maintenance.

 

2024-05-27: GTFS funiculars will be route_type=116

We will correct the route_type of funiculars to the correct value.

 

2024-05-27: OJP/NeTEx: Improved SIRI facilities mapping

We will map more offers (Lists of transport modes and hints (Dataset)) to SIRI facilities in the response.

 

2024-05-24 Publication Data draft timetable 2025

The new data for the draft timetable for 2025 is now available: https://opentransportdata.swiss/en/dataset/timetable-54-draft-hrdf

 

2024-05-19/20 Failure of our data management system CKAN

From 19 May 8:00 to 20 May 16:30 total failure of the CKAN system, so that unfortunately no datasets could be obtained. We apologise and thank you for your understanding.

 

2024-05-09/12: GTFS Static not updated correctly on Ascension Day

The GTFS Static was mistakenly not published on Ascension Day. However, the real time was switched. Therefore, until Monday’s version, there was a mismatch to real time in many cases.

 

2024-04-27: VDP fault: Short interruptions in the availability of road traffic data

The APIs for road traffic data may currently experience brief outages lasting a few minutes. We are working on rectifying the problems. Thank you for your understanding. For information on the status, see also https://status.opentransportdata.swiss.

 

2024-04-22: Switch of GTFS-RT to LINUX and new version

GTFS RT responses are now expected to be up to twice as large, because the deviation between the VDV454 target times accurate to the tenth of a minute and the GTFS target times accurate to the minute is now transmitted.
This means that GTFS clients now also benefit from planning that is accurate to a tenth of a minute, which cannot be provided in the GTFS Static data.

GTFS RT responses are now expected to be up to twice as large, because the deviation between the VDV454 target times accurate to the tenth of a minute and the GTFS target times accurate to the minute is now transmitted.
This means that GTFS clients now also benefit from planning that is accurate to a tenth of a minute, which cannot be provided in the GTFS Static data.

 

2024-04-18: The live switch from GTFSR to Linux will be postponed to Monday, 22nd April

 

2024-04-18: Update of static GTFS data cancelled today

The second update of the static GTFS data has unfortunately been cancelled this week. The next update is scheduled for next Monday, 22 April. The second update of the static GTFS data has unfortunately been cancelled this week. The next update is scheduled for next Monday, 22 April.

 

2024-04-15: Replacement of the existing “BehiG inventory” data records

From 15 April 2024, data on the accessibility of public transport stops in Switzerland will be recorded in the atlas application. This will replace the previous “DiDok” system. This will also affect the publication of the PRM inventory data records

The most important changes

  • Publication of three versions (actual, future_timetable, full) analogue to public transport service points Switzerland (servicePoints).
  • Minor adjustments to the field names. The scope of the data provided remains the same.
  • The data records will be published individually in future. It will therefore be possible to use the permalink.
  • The ticket and information counters are now combined in one object.
  • Publication in zip format.

Preview:

In order to prepare for the changeover to the new datasets, you will find an example of all files and a description of the data here. Please do not use this data productively.

 

2024-04-11: GTFS-Flex is published.

We are one of the first providers worldwide to offer on-demand services in the GTFS extension, namely GTFS-Flex.

 

2024-04-08: Planned changeover of static GTFS data, to 2 publications per week, delayed.

The next update (with the new release cycle) is scheduled for Thursday, 11 April.

 

2024-03-28: Solved: APIs currently not reachable.

We are working on the resolution of the problem.

 

2024-03-27: Maintenance Work between 8-11 pm

Maintenance work will be carried out tonight between 8pm and 11pm. There may be brief interruptions (max. 15 minutes) for the cookbook pages and data records. We try to keep interruptions as short as possible. The APIs are not affected by this.

 

2024-03-20: UPDATE Issues resolved: The APIs are available again.

The platform and APIs are available again. Apologies to all our users for the inconveniences.

 

2024-03-20: Network problems: APIs are currently unavailable

We are working on resolving the issue.

 

2024-03-14: GTFS 2x per week, new attribute SJYID, poll & call for topics

 

2024-03-04: GTFS-RT not working properly

Update: The GTFS-RT data is available again.

We are seeing some issues with missing GTFS-RT data. We are working on a solution to the problem.

 

2024-02-05: OJP: Bug

Bei einem Teilausfall fehlt auf dem letzten Halt das Not_Service_Stop=true in OJP 1.0.

 

2024-03-04: Solved: Disruption: Datasets and Services temporarily not available

The data records are currently not accessible, we are in the process of correcting the error.

 

2024-02-29: Final maintenance work CKAN

 

2024-02-28: CKAN: Update and adjustment of functionality

CKAN will receive an update on Wednesday, 28 February 2024. It is to be expected that the data sets will not be accessible for a shorter period of time. We try to keep this time as short as possible. After the upcoming update, the ability to follow records and view their latest changes will no longer be available.

 

2024-02-19: OJP: new infrastructure for OJP and TRIAS

We switched to a new infrastructure for OJP and TRIAS this morning. There should have been no interruption, and there should be no change to requests and responses for OJP2020 and TRIAS2020. The real-time updates on our service now occur every 30 seconds. This is currently blocking the engine for 2 seconds at a time. We are working on this problem. We can also switch to update per 60 seconds if you prefer. If you experience any problems, please let us know immediately. We can also reverse the step if one of you experiences a problem (opendata@sbb.ch).

 

2024-02-12: OJP: Sloid in StopPointRef

Since the beginning of the year, we have been switching to gradient-based data in OJP. Wherever goods are delivered with a sharp rise, they are delivered in the same way. Ascending data is always executed with a SLOID and no longer a Didok number. However, mixed answers are possible and changes per operator/lines can be made at any time.

Old:

New:

 

Old:

New:

This also allows for better routes.

The conversions are as follows:

  • Conversion method (if you work internally with DiDok) for sloid -> didok:
    • If sloid is in the string,
    • Pick out the correct element, convert to number, and add 8,500,000 (e.g. ch:1:sloid:1026:1:2 -> 8501026)

    This is of course a hack. In reality, a mapping table should be used. However, we assume that the last Didok numbers will disappear for Switzerland before this becomes a problem.

     

  • Didok -> sloid works similarly. However, this can lead to problems at foreign stops:
    • Basically only convert 85xxxxx, except for foreign local traffic, which we also had to record in our systems (8500700 -> ch:1:sloid:700)
    • Local traffic abroad: 11xxxxx, 12xxxxx, 13xxxxx, 14xxxxx => ch:1:sloid:<didok> (e.g. “Annemasse, Adrien Ligué”: 1401664 à ch:1:sloid:1401664)

 

2024-02-08: Problems with the search function

At the moment the search does not work as desired. We are working on a solution to the problem.

 

2024-02-03: OJP adjustments planned for the near future

  • Times are now given in tenths of a minute (to the nearest 6 seconds) where available. They are currently only issued to the minute.
  • OJP now uses the DirectionText from real-time (from VDV 454 AUS/REF-AUS) as DestinationText. This improves the destination information for the current operating day in some cases.
  • We also try to map the shadows onto the lines. However, a few tests are still necessary here. We use the VDV journey relationships).

 

2024-01-24: Adjustments in the GTFS-Static export

Due to feedback of several of our users regarding the file stops.txt, there have been some adjustments to the GTFS Static export. Example of the GTFS export gtfs_fp2024_2024-01-24_04-15:

  • All platforms (even if there is only 1 platform for a station) is assigned to a parent
  • The parents have the “station name including place name”

Example (Burgdorf):

8576504“,”Burgdorf, Bahnhof“,”47.0603910195685″,”7.62065110137342″,””,”Parent8576504″

“8576504:0:A”,”Burgdorf, Bahnhof”,”47.0603910195685″,”7.62065110137342″,””,”Parent8576504″

“8576504:0:B”,”Burgdorf, Bahnhof”,”47.0603910195685″,”7.62065110137342″,””,”Parent8576504″

“Parent8576504″,”Burgdorf, Bahnhof”,”47.0603910195685″,”7.62065110137342″,”1″,””

 

2024-01-24: Different handling of Swiss Journey Identification (SJYID) in real time

From 1 February 2024, the element “FahrtBezeichner” will be partially filled with a Swiss Journey ID (SJYID) (information in German or French). Until now, data recipients could assume that:

  • generated/supplied SJYIDs are adopted as journey identifiers and passed on to the data recipients.
  • SJYID is generated as a journey identifier for all transferred means of transport if none was supplied.
  • SJYID is generated as a journey identifier for extra trains created at short notice.

At the request of the Swiss public transport sector, this behaviour is to be changed as follows at a date yet to be defined:

  • SJYIDs generated/supplied in the timetable are adopted as journey identifiers and forwarded unchanged to the data recipients.
  • SJYID is only generated as a journey identifier if none was supplied and it is a means of transport from NeTS.
  • SJYID is generated as a journey identifier for extra trains created at short notice.

This affects the following data records:

Please note, that SJYID is not yet supported via GTFS. This is planned for Q1/2024.

Further information see oev-info.ch

 

2024-01-31: Replacement of existing data records (Service Points, Business Organisations, Swiss Line ID)

Contribution from 18.12.2023

The following data records will no longer be updated as of 31 January 2024

The following data records can be used as a replacement

 

2024-01-16: Adaptation of realisation specifications HRDF 2.0.5: New release 16.01.2024

Further information can be found in the document HRDF realisation specifications – Swiss public transport (German only).

The following further developments are planned:

  • Files “BFKOORD_LV95” and “BFKOORD_WGS”: The length of the fields for the X and Y coordinates is increased from 10 to 11 characters. The attributes that follow these two fields are shifted by 2 positions.
  • Two new files “GLEISE_LV95” and “GLEISE_WGS” are made available. They have the same content as the files “GLEIS_LV95” and “GLEIS_WGS”. However, the identifiers used to distinguish the following information have changed:
  • The new identifier for the SLOID is the value g. (The old identifier was the value I).
  • The new identifier for the coordinates is the value k. (The old identifier was the value K).

The information on the tracks (identifier G) and sectors (identifier A) must be transmitted on separate lines.

We will provide you with a test data set with the new adjustments.

Please note:

Please note that the GLEIS, GLEIS_LV95 and GLEIS_WGS files will no longer be available for the development planned for the fourth quarter of 2024.

 

2024-01-15: Missing realtime information (GTFS-RT)

2024-01-16 Update: The data is available again.

Some real-time information is currently missing in the GTFS-RT, especially for local transport in the cities of Zurich, Basel, Bern and Lucerne. We are analysing the situation so that the data can be made available again in full as soon as possible.

 

2023 (History)

2023-12: Data update over the holidays

Over the holidays, the HRDF data will be made available without interruption, but there will be little or no change in content. Other systems (GTFS-S, GTFS-RT, TRIAS, OJP) will not be updated with a new timetable on Wednesday 27 December 2023.

 

2023-12-10: Erraneous additional trips in GTFS-RT

In the morning of 10 December 2023, the GTFS RT response erroneously showed approx. 65,000 additional trips due to a problem with matching to the target data. With a workaround, the problems could be solved except for a few additional journeys. We are analysing the error in detail and apologise for any inconvenience caused.

 

2023-12-10: Timetable change 2023/24

In the week from Wednesday, December 6th 2023 to Wednesday, December 13th 2023, both the 23 and 24 GTFS-Static datasets will overlap to include the time range between Monday, December 4th 2023 to Wednesday, December 13th 2023. This means that you can switch to the new GTFS-Static data at any time between the two Wednesdays (before and after the timetable change) and the GTFS-RT data will always be correct.

 

2023-12-08: OJP/Trias – Upgrade of the overall services

The entire solution will be migrated on 8 December. There should be no interruptions. The base system is migrated to the latest version. This is a step towards the rollout of OJP 2.0. If problems do occur with customers, please contact opendata@sbb.ch immediately. We will switch to Linux by the end of February. The exact date will be communicated.

 

2023-11-27: Network fault rectified

Update 16:00: The systems are running stable again and the APIs should be fully accessible. We apologize for the inconveniences and thank you for your understanding.

Update 14:45: A temporary workaround has been set up to stabilise the situation. Work is continuing to solve the underlying problem.

Network problems have been causing interruptions in the accessibility of the APIs since around 9 am. We are working hard to solve the problems and will keep you informed here as soon as there are updates.

 

2023-10-23: OJP/Trias – Slower service

Due to various factors, OJP/TRIAS were considerably slower. An ODV offer was suboptimally configured and resulted in significant footpath calculations, the log level was higher for analysing the problem and the fact that we currently had the 2023 and 2024 timetables in the system was not yet fully taken into account. In addition, a new user with 300,000 requests per day was activated and load tests were carried out by another user. The offer has been removed (it no longer exists), the log level has been lowered and the memory of the systems has been increased. In this context, the new performance monitoring system was improved and put into operation.

 

2023-10-15 OJP: Two timetable years active

A first version of the 2024 timetable has been added to the OJP so that a preview of 120 days can be achieved.

 

2023-09-01: ODMCH: Adaptation of realisation specifications HRDF 2.0.5: New release at the beginning of 2024

Further information can be found in the document HRDF realisation specifications – Swiss public transport (German document).

The following further developments are planned:

  • Files “BFKOORD_LV95” and “BFKOORD_WGS”: The length of the fields for the X and Y coordinates is increased from 10 to 11 characters. The attributes that follow these two fields are shifted by 2 positions.
  • Two new files “GLEISE_LV95” and “GLEISE_WGS” are made available. They have the same content as the files “GLEIS_LV95” and “GLEIS_WGS”. However, the identifiers used to distinguish the following information have changed:
  • The new identifier for the SLOID is the value g. (The old identifier was the value I).
  • The new identifier for the coordinates is the value k. (The old identifier was the value K).

The information on the tracks (identifier G) and sectors (identifier A) must be transmitted on separate lines.

Please note:

Please note that the GLEIS, GLEIS_LV95 and GLEIS_WGS files will no longer be available for the development planned for the second quarter of 2024.

 

2023-08-07: OJP: Maintenance work

On Monday, 07/08/2023 between 21:00-24:00 scheduled maintenance work will take place. No interruptions are expected. We thank you for your understanding.

 

2023-07-03: MBC timetable data corrected

The MBC timetable data has been corrected and is available again.

 

2023-06-28: Timetable data from MBC currently not updated

MBC’s timetable data cannot be updated at present due to technical problems at the supplier. An update will follow as soon as available.

 

2023-06-12: FEDRO: Update of the General Terms and Conditions of FEDRO

The General Terms and Conditions (GTC) of FEDRO have been updated.

 

2023-06-06: FEDRO: No real-time road traffic data between 11am and 4pm

Due to technical problems, no real-time road traffic data was provided between 11am-4pm on June 6th.

 

2023-04-24: ODMCH: Actual data file not quite complete

There was an error when exporting the actual data from 24/04/2023. The file could be restored and was replaced on 01.05.2023. Please note, however, that the file is incomplete due to a technical problem.

 

2023-03-06: ODMCH/OJP: Migration: Newly generated API keys will not be stored between 6 and 8 March 2023

Due to a technical migration, API keys created between 06/03/2023 and 08/03/2023 will not be stored. Accordingly, keys must be re-generated after 08/03/2023. Short outages may occur on 08 March 2023. We thank you for your understanding.

UPDATE 09/03/2023 10 am: In the night from 08/03 to 09/03 there was a longer downtime of the APIs due to the migration. We apologize for this and are working on it at full speed. Except for the CKAN API, all APIs should be stable by now.

UPDATE 09/03/2023 2 pm: The CKAN-API is available again.

 

2023-02-16: ODMCH: Incorrect coordinates in the HRDF data

The HRDF timetable data for 15 February 2023 contains incorrect coordinates. These are corrected in the data record of 16 February 2023.

 

2023-02-06: ODMCH: Maintenance work

On Monday, 06/02/2023 between 21:00-23:00 scheduled maintenance work will take place. There may be short interruptions of the platform, but these should be in the range of seconds. We thank you for your understanding.

 

2023-01-01: ODMCH/OJP: Changes in costs and limits for API requests (January 2023)

As of 01/01/2023, new limits and costs for obtaining service-related data apply.

 

2022 (History)

2022-12-31: ODMCH: Event information public transport Switzerland (SIRI SX / VDV 736) as open data

Since the end of 2022, event information from Swiss public transport (SIRI SX / VDV 736) has been available in a new interface on the Mobility Switzerland open data platform.

The service provides all event information from transport companies in Switzerland that are connected to the central data hub (DDS SKI). The continuously updated data can be obtained as an XML file via API on the open data platform. You can find more information on the corresponding cookbook page.

On Wednesday, 25 January 2023, 4-5 pm, we held an online meetup on the topic of event information (VDV 736 and GTFS-RT Service Alerts). The slides from the presentation are available under this link.

 

2022-12-29: Incident of 28./29.12.2022

The domain opentransportdata.swiss was unavailable from 12/28/2023 at about 20:00 until 12/29/2023 12:15. The reason was an incident at the registrar. We apologize to all users of the Open Data Platform Mobility Switzerland for any problems this may have caused.

 

2022-11-09: Missing Actual Data

Due to network problems on 9.11.2022, actual data is available only to a very limited extent for this day.

Known Issues

  • In some cases there are line designations such as “L3_4” in the LEX area. We receive these from the SNCF and they are incorrect. Unfortunately, we can’t change this ourselves and have to wait until the SNCF has solved the problem. Remediation date: Unknown.

 

2022-08-24: Important information from 24.08.2022

Today at 04:55 the file gtfs_fp2022_2022-08-24_04-15.zip was published, where stops.txt incorrectly does not contain any “Steige” anymore, but only ranges, e.g. only “8507086:0” instead of “8507086:0:2” and “8507086:0:3”:

stops.txt in gtfs_fp2022_2022-08-17_04-15.zip:
“Parent8507086″,”Niederscherli”,”46.886434795937″,”7.38806829112965″,”1″,””
“8507086:0:2″,”Niederscherli”,”46.886434795937″,”7.38806829112965″,””,”Parent8507086″
“8507086:0:3″,”Niederscherli”,”46.886434795937″,”7.38806829112965″,””,”Parent8507086″
stops.txt in gtfs_fp2022_2022-08-24_04-15.zip:
“Parent8507086″,”Niederscherli”,”46.886434795937″,”7.38806829112965″,”1″,””
“8507086:0″,”Niederscherli”,”46.886434795937″,”7.38806829112965″,””,”Parent8507086″

However, stops_times.txt still contains references to the “Steige”, e.g. “8507086:0:2”, which then no longer matches the reference “8507086:0” in stops.txt.

As a workaround, we copied stops.txt from gtfs_fp2022_2022-08-17_04-15.zip to gtfs_fp2022_2022-08-24_10-23.zip, which has just been republished and thus replaced gtfs_fp2022_2022-08-24_04-15.zip.

Unfortunately this does not fix all errors, but gtfs_fp2022_2022-08-24_10-23.zip is missing much less references than gtfs_fp2022_2022-08-24_04-15.zip.

We are working hard on a new version.

We apologize, thank you for your patience and keep you informed regarding new version of the data.

 

2022-07-14: From 14.7. 2022

From the migration to EFA 10.5 and the simultaneous activation of multilingualism, the xml:lang attribute is no longer only sent for individual text elements in OJP, but for all of them.

EXAMPLE

EFA 10.4 without xml:lang attribute for PublishedLineName.Text (xml:lang attribute is already sent for Name.Text and ShortName.Text):
<ojp:name>
<ojp:Text xml:lang=”de”>Train</ojp:Text>
</ojp:name>
<ojp:ShortName>
<ojp:Text xml:lang=”de”>IC</ojp:Text>
</ojp:ShortName>
</ojp:Mode>
<ojp:PublishedLineName>
<ojp:Text>IC1</ojp:Text>
</ojp:PublishedLineName>

EFA 10.5 now also with xml:lang attribute for PublishedLineName.Text
&lt;ojp:name>
&lt;ojp:Text xml:lang=”de”>Train&lt;/ojp:Text>
&lt;/ojp:name>
&lt;ojp:ShortName>
&lt;ojp:Text xml:lang=”de”>IC&lt;/ojp:Text>
&lt;/ojp:ShortName>
&lt;/ojp:Mode>
&lt;ojp:PublishedLineName>
<ojp:Text xml:lang=”de”>IC1</ojp:Text>
&lt;/ojp:PublishedLineName>

 

2022-06-29: From 29.6. 2022

GTFS data with the additional column “block_id” in trips.txt is provided immediately.

trips.txt (trips with block_id “13192”)
*********
route_id,service_id,trip_id,trip_headsign,trip_short_name,direction_id,block_id
“96-186-3-j22-1″,”TA+rau00″,”542.TA.96-186-3-j22-1.18.R”,”Elgg, Bahnhof”,”68050″,”1″,”13192″
“96-185-6-j22-1″,”TA+rau00″,”7.TA.96-185-6-j22-1.1.H”,”Hagenbuch ZH, Dorf”,”68117″,”0″,”13192″

The block_ids will not yet be included in the journeys cut at the border, e.g. from Singen to Schaffhausen.
This requires an extension to our GTFS export, which is currently being tested.

 

2022-06-20: Updates

  • The Cookbook has been updated. Most changes are available in German, English, French and Italian, further translations will follow as soon as possible.
  • The News section was adapted to include this changelog to provide better transparency of the changes on the website.
  • Older release notes have been merged with this page.
  • Some unreachable and obsolete websites have been removed.

 

2022-06-14: Updates

  • PROD instance has been updated to EFA Version 10.5. Most important change is that all XML text tags contain now an xml:lang tag. E.g. <ojp:Text xml:lang=”de”>. The desired  language can be requestet by adding following lines in the <ServiceRequest>:
    <ServiceRequestContext>
    <Language>de</Language>
    </ServiceRequestContext>
    Available language tags are: de, fr, it, en

 

2022-06-09: Updates

  • Pages referring to the “Bahnstellen”/”train station” data set have been removed as the data item is obsolete.

 

2022-05-02: Updates

  • OJP Requests are validated against the XSD. Not valid Requests are no longer served. This may cause in errors, if Requests are not valid.

Validation of OJP requests

Because some OJP users were not ready on March 1st, 2022, the validation of the OJP requests could not be activated as announced.
Therefore, from May 2nd, 2022, all OJP requests will be validated using ojp-xsd-v1.0. If a request does not meet the xsd specifications, it is rejected with “HTTP/1.1 400 Bad Request”.
A currently frequently occurring violation of the xsd specifications is the omission of the <LocationName> element in the PlaceRefStructure, e.g. in the OJPStopEventRequest or OJPTripRequest.
If no suitable LocationName is available when forming OJPStopEventRequest or OJPTripRequest, <ojp:Text>unknown</ojp:Text> can be sent as an alternative.”

 

2021 & older (History)

2021-02-17: Updates

  • Problem solved at La Gottaz. There was footpath routing.
  • Matching between real-time and timetable has been improved. Journeys that do not match at the end of the journey start are now also taken into account.

 

2021-02-03: Changes in GTFS Static

  • GTFS Static: The file names now contain “_hh-mm”.

 

2021-01-22: Names of S-Bahn trains changed

  • Some of the names of S-Bahn trains were mistakenly set to S1. This has been corrected with a new version of GTFS Static. GTFS-RT was activated immediately for the new Static.

 

2021-01-21: GTFS Problems

  • Many train journeys were missing in yesterday’s data activation (approx. 100 suburban railway lines). The problem has been corrected with a new GTFS Static (https://opentransportdata.swiss/de/dataset/timetable-2021-gtfs2020) and immediate activation in real time. This means that the new static must be loaded for the GTFS-RT. OJP2020 and TRIAS2020 thus deliver the correct results again.
  • NumberOfResults is not always perfectly adhered to in the server. If a “group” of answers with the same probability is selected, the complete group is returned, regardless of what was specified. Example: The request in the LocationInformationRequest “St. Gallen, Haggen” returns two stops: “St. Gallen, Haggen” and “St. Gallen Haggen”. This means that a ResultSet must always be used.
    Enquiry example:

 

2021-01-20: GTFS pseudo stops removed

  • With the activation of the new data next Wednesday 20.01.2021 (GTFS-S in the morning at 09:00, GTFS-R and OJP in the afternoon at 14:00), the pseudo-stops will be sent according to the “new behaviour”. Current behaviour:
    ****************
    GTFS-S: Railway 2000 route is transmitted normally
    GTFS-R: Track 2000 route is sent with “ScheduleRelationship”: “Skipped”
    OJPTripDelivery without real-time: StopPointRef 132 like normal stop
    OJPTripDelivery with real-time: StopPointRef 132 with NotServicedStop=true behaviour:
    **************
    GTFS-S: Railway 2000 route is no longer broadcast
    GTFS-R: Railway 2000 route is no longer broadcast
    OJPTripDelivery with and without real-time: Rail 2000 route is no longer sent (only as location in TripResponseContext)

 

2017-05-22: New data

  • Features. The main new features are:
    • GTFS RT
    • Extensions in GTFS Static (agency.txt)
    • ZVV Real-Time: With the connection of the partner “ZVV” various transport companies were connected, including PAG for the region of Zurich. Not all lines are available. Only these, which have a sufficiently good data quality. An overview of all Transport Agencies with real-time can be found here: https://opentransportdata.swiss/en/dataset/go-realtime
  • Enhancements:
    • Departure / arrival schedule: For trains with undefined delays, the journey is marked as unsupervised.
    • Federation Opendata.swiss
  • Fixes:
    • Incomplete departure table / track information
    • Incomplete data on extracts
  • Known issues and problems. Within this release there are these known issues within the platform that will be resolved in a future release:
    • The sorting of the files is partly not yet optimal. We advise you to use the permalink.

 

2017-01-27: Changes

  • These release notes contain valuable information on the latest features and improvements in this release of the Open Data Platform Swiss Public Transport. The new version is online since today 10 AM:
    • First version of track information
    • Subscribing service to datasets
    • User self-administration
    • API-Explorer: https://opentransportdata.swiss/explorer/
    • Enhancements:
      • Red bar on homepage in case of disruptions Mobile view enhancements Various cookbook updates Language adjustments  Discourse also available in Cookbook
      • Didok File column country_code added HRDF Adaptations: The file UMSTEIGZ is supplied twice:
      • Once without traffic number (as before)
      • Once with traffic tag number (new file)
      • More information about HRDF is attached and here available: https://opentransportdata.swiss/en/cookbook/hafas-rohdaten-format-hrdf/
    • Fixes:
      • X axis in the developer dashboard shows the data in the correct order Fixed UTF-8 problems with data explorer “Last updated” for datasets now corresponds to the truth
    • Known issues and problems. Within this release there are these known issues within the product that will be resolved in a future release:
      • The real-time data, which are delivered via VDV interfaces, are not output yet in seconds
      • The handling of the track data will be optimized
      • Some detail optimization in the data will be done