Skip to content

Wichtige Informationen/Änderungen

Geplant

2024-02-03: OJP in Kürze geplante Anpassungen

  • Zeiten werden neu in Zehntel-Minuten (auf 6 Sekunden genau) angegeben, wo sie verfügbar sind. Aktuell sind sie nur minutengenau ausgegeben.
  • OJP verwendet neu den RichtungsText aus der Echtzeit (aus VDV 454 AUS/REF-AUS) als DestinationText. Dies verbessert für den aktuellen Betriebstag die Zielangabe in einigen Fällen.
  • Wir versuchen auch, die Schattenzüge auf die Linien abzubilden. Hier sind allerdings noch ein paar Tests notwendig. Wir verwenden dazu die VDV-Fahrtbeziehungen).

 

Aktuell

2024-03-04: Probleme mit GTFS-RT / GTFS-RT not working properly

Update: Der GTFS-RT-Daten stehen wieder zur Verfügung, die Störung wurde behoben. The GTFS-RT data is available again.

Echtzeitdaten via GTFS-RT fehlen momentan. Wir arbeiten an der Lösung des Problems.

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.

 

Historie

2024-03-04: Behoben: Störung: Datensätze nicht erreichbar / Disruption: Datasets and Services temporarily not available

Die Datensätze und Dienste sind momentan nicht erreichbar, wir sind daran, den Fehler zu beheben.

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

2024-02-29: Abschlussarbeiten CKAN Update / Final maintenance work

2024-02-28: CKAN: Update und Anpassung der Funktionalität / CKAN: Update and adjustment of functionality

Am Mittwoch, 28.02.2024 wird CKAN ein Update erhalten. Es ist zu erwarten, dass die Datensätze dadurch für kürzere Zeit nicht erreichbar sind. Wir versuchen, diese Unterbrüche so kurz wie möglich zu halten. Nach dem bevorstehenden Update wird die Möglichkeit, Datensätzen zu folgen und ihre letzten Änderungen anzusehen, nicht mehr vorhanden sein.

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: neue Infrastruktur für OJP und TRIAS

Wir haben heute Morgen auf eine neue Infrastruktur für OJP und TRIAS umgeschaltet. Es sollte dabei zu keinem Unterbruch gekommen sein, und auch an Anfragen und Antworten für OJP2020 und TRIAS2020 sollte sich nichts ändern. Die Echtzeitupdates auf unserem Service erfolgen neu alle 30 Sekunden. Dies blockiert im Moment den Engine für jeweils 2 Sekunden. An diesem Problem arbeiten wir. Wir können auch auf Update pro 60 Sekunden wechseln, wenn Ihr das lieber möchtet. Falls irgendwelche Probleme bei Euch auftreten, bitten wir um sofortige Rückmeldung. Wir können den Schritt auch rückabwickeln, wenn bei einem von Euch ein Problem auftritt (opendata@sbb.ch).

FR:

Ce matin, nous sommes passés à une nouvelle infrastructure pour OJP et TRIAS. Il ne devrait pas y avoir d’interruption et les demandes et réponses pour OJP2020 et TRIAS2020 ne devraient pas non plus changer. Les mises à jour en temps réel sur notre service ont lieu toutes les 30 secondes. Cela bloque actuellement le moteur pendant 2 secondes. Nous travaillons sur ce problème. Nous pouvons également passer à une mise à jour toutes les 60 secondes si vous le préférez. Si vous rencontrez des problèmes, veuillez nous en informer immédiatement. Nous pouvons également annuler la démarche si l’un d’entre vous rencontre un problème (opendata@sbb.ch).

EN:

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

Seit Anfang Jahr stellen wir auf steigscharfe Daten in OJP um. Wo steigscharf eingeliefert wird, wird auch so ausgeliefert. Steigscharfe Daten sind immer mit einer SLOID ausgeführt und nicht mehr einer Didok-Nummer. Es sind aber gemischte Antworte möglich und Änderungen pro Betreiber/Linien können jederzeit erfolgen.

Alt:

                        <ojp:ThisCall>
                            <ojp:CallAtStop>
                                <siri:StopPointRef>8501300</siri:StopPointRef>
                                <ojp:StopPointName>
                                    <ojp:Text xml:lang="de">Montreux</ojp:Text>
                                </ojp:StopPointName>
                                <ojp:PlannedQuay>
                                    <ojp:Text xml:lang="de">6</ojp:Text>
                                </ojp:PlannedQuay>
                                <ojp:ServiceArrival>
                                    <ojp:TimetabledTime>2024-02-12T07:44:00Z</ojp:TimetabledTime>
                                    <ojp:EstimatedTime>2024-02-12T07:44:00Z</ojp:EstimatedTime>
                                </ojp:ServiceArrival>
                                <ojp:Order>15</ojp:Order>
                            </ojp:CallAtStop>
                        </ojp:ThisCall>

Neu:

                        <ojp:ThisCall>
                            <ojp:CallAtStop>
                                <siri:StopPointRef>ch:1:sloid:1300:2:3</siri:StopPointRef>
                                <ojp:StopPointName>
                                    <ojp:Text xml:lang="de">Montreux</ojp:Text>
                                </ojp:StopPointName>
                                <ojp:PlannedQuay>
                                    <ojp:Text xml:lang="de">3</ojp:Text>
                                </ojp:PlannedQuay>
                                <ojp:ServiceArrival>
                                    <ojp:TimetabledTime>2024-02-12T07:41:00Z</ojp:TimetabledTime>
                                    <ojp:EstimatedTime>2024-02-12T07:41:00Z</ojp:EstimatedTime>
                                </ojp:ServiceArrival>
                                <ojp:Order>7</ojp:Order>
                            </ojp:CallAtStop>
                        </ojp:ThisCall>

 

Alt

                            <ojp:OriginStopPointRef>8501394</ojp:OriginStopPointRef>
                            <ojp:OriginText>
                                <ojp:Text xml:lang="de">Château-d'Oex</ojp:Text>
                            </ojp:OriginText>
                            <ojp:DestinationStopPointRef>8501300</ojp:DestinationStopPointRef>
                            <ojp:DestinationText>
                                <ojp:Text xml:lang="de">Montreux</ojp:Text>
                            </ojp:DestinationText>

Neu:

                            <ojp:OriginStopPointRef>ch:1:sloid:1026:1:2</ojp:OriginStopPointRef>
                            <ojp:OriginText>
                                <ojp:Text xml:lang="de">Genève-Aéroport</ojp:Text>
                            </ojp:OriginText>
                            <ojp:DestinationStopPointRef>ch:1:sloid:1609:3:7</ojp:DestinationStopPointRef>
                            <ojp:DestinationText>
                                <ojp:Text xml:lang="de">Brig</ojp:Text>
                            </ojp:DestinationText>

Dies erlaubt dann auch bessere Fahrwege.

Die Umwandlungen gehen wie folgt:

  • Umwandlungsmethodik (falls Ihr intern mit DiDok arbeitet) für sloid -> didok:
    • Falls sloid im String drin ist,
    • Herauspicken des richtigen Elements, umwandeln in Zahl, und 8‘500‘000 hinzuzählen  (Bsp ch:1:sloid:1026:1:2 -> 8501026)

    Dies ist natürlich ein Hack. In Wirklichkeit müsste eine Mappingtabelle verwendet werden. Wir gehen aber davon aus, dass die letzten Didok-Nummer verschwinden für die Scheiz, bevor dies zum Problem wird.

     

  • Didok -> sloid geht ähnlich. Allerdings kann es zu Problemen bei ausländischen Haltestellen führen:
    •  Grundsätzlich nur 85xxxxx umwandeln, ausser ausländischer Nahverkehr, den wir in unseren Systemen auch erfassen mussten (8500700 -> ch:1:sloid:700)
    • Nahverkehr Ausland: 11xxxxx, 12xxxxx, 13xxxxx, 14xxxxx => ch:1:sloid:<didok>  (Bsp  “Annemasse, Adrien Ligué”:   1401664 à ch:1:sloid:1401664)

2024-02-08: Probleme mit der Suchfunktion

Momentan funktioniert die Suche nicht wie gewünscht. Wir arbeiten an der Lösung des Problems.

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

2024-01-24: Anpassungen im GTFS-Static-Export / Adjustments in the GTFS-Static export

Aufgrund von Rückmeldungen unserer Datenabnehmer zur Datei stops.txt haben wir gewisse Anpassungen am GTFS-Static-Export vorgenommen.

Im GTFS-Export gtfs_fp2024_2024-01-24_04-15

  • sind alle Steige (neu auch wenn die Haltestelle nur einen Steig hat) einem Parent zugeordnet
  • haben auch die Parents neu den “Haltestellennamen mit Ort” statt wie bisher den “Haltestellennamen ohne Ort”

Beispiel (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″,””

——————————————————————–

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: Andere Handhabung Swiss Journey Identification (SJYID) in Echtzeit / Different handling of Swiss Journey Identification (SJYID) in real time

Ab 1. Februar 2024 wird das Element “FahrtBezeichner” teilweise mit einer Swiss Journey ID (SJYID) befüllt. Bis dato konnten Datenbezüger davon ausgehen, dass

  • generierte/gelieferte SJYIDs als Fahrtbezeichner übernommen und an die Datenbezüger weitergegeben werden.
  • für alle übernommenen Verkehrsmittel eine SJYID als Fahrtbezeichner generiert wird, wenn keine solche geliefert wurde.
  • für kurzfristig erzeugte Extrazüge eine SJYID als Fahrtbezeichner generiert wird.

Auf Wunsch der Branche öV CH soll dieses Verhalten zu einem noch zu definierenden Zeitpunkt wie folgt geändert werden:

  • im Fahrplan generierte/gelieferte SJYIDs werden als Fahrtbezeichner übernommen und unverändert an die Datenbezüger weitergegeben.
  • eine SJYID als Fahrtbezeichner wird nur generiert, wenn keine solche geliefert wurde und es sich um ein Verkehrsmittel aus NeTS handelt.
  • für kurzfristig erzeugte Extrazüge wird eine SJYID als Fahrtbezeichner generiert.

Dies wird folgende Datensätze betreffen:

Bitte beachtet, SJYID wird noch nicht über GTFS unterstützt. Dies ist geplant per Ende Q1 2024.

Weitere Information vgl. oev-info.ch

——————————————————————–

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: Ersatz von bestehenden Datensätzen (Dienststellen, Geschäftsorganisationen, Swiss Line ID) / Replacement of existing data records (Service Points, Business Organisations, Swiss Line ID)

Beitrag vom 18.12.2023

Folgende Datensätze werden per 31. Januar 2024 nicht mehr aktualisiert:

Als Ersatz können folgende Datensätze genutzt werden:

——————————————————————–

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: Anpassung Realisierungsvorgaben HRDF 2.0.5: Neuer Release 16.01.2024

Weitere Informationen finden Sie im Dokument HRDF-Realisierungsvorgaben – öV-Schweiz.

Die folgenden Weiterentwicklungen sind geplant:

  • Dateien “BFKOORD_LV95” und “BFKOORD_WGS”: Die Länge der Felder für die X- und Y-Koordinaten wird von 10 auf 11 Zeichen erhöht. Die Attribute, welche diesen beiden Feldern folgen, werden um 2 Positionen verschoben.
  • zwei neue Dateien “GLEISE_LV95” und “GLEISE_WGS” werden zur Verfügung gestellt. Sie haben denselben Inhalt wie die Dateien “GLEIS_LV95” und “GLEIS_WGS”. Allerdings haben sich die Kennungen, um die folgenden Informationen zu unterscheiden, geändert:
  • Die neue Kennung für die SLOID ist der Wert g. (Die alte Kennung war der Wert I).
  • Die neue Kennung für die Koordinaten ist der Wert k. (Die alte Kennung war der Wert K).

Die Informationen zu den Gleisen (Kennung G) und Sektoren (Kennung A) sind auf getrennten Zeilen zu übermitteln.

Wir stellen Ihnen einen Testdatensatz mit den neuen Anpassungen zur Verfügung.

Hinweis:

Bitte beachten Sie, dass die Dateien GLEIS, GLEIS_LV95 und GLEIS_WGS bei der für das vierte Quartal 2024 geplanten Entwicklung nicht mehr zur Verfügung stehen werden.

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

2024-01-16 Update: Die Daten stehen inzwischen wieder zur Verfügung. The data is available again.

Zurzeit fehlen einige Echtzeitinformationen im GTFS-RT, insbesondere im Nahverkehr in den Städten Zürich, Basel, Bern, Luzern. Wir sind an der Analyse dran, damit die Daten baldmöglichst wieder vollständig zur Verfügung gestellt werden können.

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-12: Datenaktualisierung über die Feiertage / Data update over the holidays

Über die Feiertage werden die HRDF Daten ohne Unterbruch zur Verfügung gestellt, sich jedoch inhaltlich nicht oder nur sehr gering ändern. Andere Systeme (GTFS-S, GTFS-RT, TRIAS, OJP) werden am Mittwoch 27.12.2023 nicht mit einem neuen Fahrplan aktualisiert.

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: Fälschlicherweise zusätzliche Zusatzfahrten in GTFS-RT / Erraneous additional trips in GTFS-RT

Am 10.12.2023 am Vormittag gabe es in der GTFS-RT-Response fälschlicherweise jeweils ca. 65’000 Zusatzfahrten, weil ein Problem beim Matching auf die Solldaten bestand. Mit einem Workaround konnten die Probleme bis auf wenige Zusatzfahrten gelöst werden. Wir analysieren den Fehler im Detail und bitten um Entschuldigung für die Unannehmlichkeiten.

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: Fahrplanwechsel / Timetable change 2023/24

In der Woche von Mittwoch 06.12.2023 bis Mittwoch 13.12.2023 werden sowohl der 23er- als auch der 24er-GTFS-Static-Datensatz überlappend den Zeitbereich von Montag 04.12.2023 bis Mittwoch 13.12.2023 beinhalten. Dies ermöglicht, dass ihr zu einem beliebigen Zeitpunkt zwischen den beiden Mittwochen (vor und nach dem Fahrplanwechsel) auf die neuen GTFS-Static-Daten umschalten könnt und die GTFS-RT-Daten immer passen.

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 der Gesamtservices

Am 8.12. wird die Gesamtlösung migriert. Es sollte nicht zu Unterbrüchen kommen. Das Basissystem wird auf die neuste Version migriert. Dies ist ein Schritt zum Rollout von OJP 2.0. Falls doch Probleme bei Abnehmern auftauchen, bitte unbedingt sofort bei opendata@sbb.ch melden.  Bis Ende Februar wird auf Linux umgestellt. Der genaue Zeitpunkt wird kommuniziert.

2023-10-27: Netzwerkstörung behoben

Update 16 Uhr: Die Systeme laufen wieder stabil und die APIs sollten wieder uneingeschränkt erreichbar sein. Wir entschuldigen uns für die Unannehmlichkeiten und danken Ihnen für Ihr Verständnis.

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 Uhr: Es wurde ein vorübergehender Workaround eingerichtet, welcher zu einer Stabilisierung der Situation führt. Es wird weiter daran gearbeitet, das zugrundeliegende Problem zu lösen.

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

Seit ca. 9 Uhr bestehen Netzwerkprobleme, die zu Unterbrechungen bei der Erreichbarkeit der APIs führen. Wir arbeiten mit Hochdruck an der Lösung der Probleme und informieren weiter an dieser Stelle, sobald es Updates gibt.

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 – Langsamerer Service

Aufgrund verschiedener Faktoren waren OJP/TRIAS wesentlich verlangsamt. Ein ODV-Angebot war suboptimal konfiguriert und hat erhebliche Fusswegberechnungen zur Folge gehabt, das Log-Level war höher für die Analyse des Problems und die Tatsache, dass wir im Moment die Fahrpläne 2023 und 2024 im System führten, war noch nicht vollständig berücksichtigt. Es wurde ausserdem ein neuer Benutzer mit 300’000 Requests pro Tag aktiviert und von einem anderen Benutzer wurden Lasttests gefahren. Das Angebot wurde entfernt (es existiert auch nicht mehr), das Loglevel wurde gesenkt, das Memory der Systeme wurde erhöht. In diesem Zusammenhang wurde das neue Performance-Monitoring verbessert und in den Betrieb genommen.

 

2023-10-15 OJP: Zwei Fahrplanjahre aktiv

Damit eine Vorschau von 120 Tagen erreicht werden kann, wurde eine erste Versiondes Fahrplans 2024 in den OJP eingefügt.

 

2023-09-01: ODMCH: Anpassung Realisierungsvorgaben HRDF 2.0.5: Neuer Release Anfang 2024

Weitere Informationen finden Sie im Dokument HRDF-Realisierungsvorgaben – öV-Schweiz.

Die folgenden Weiterentwicklungen sind geplant:

  • Dateien “BFKOORD_LV95” und “BFKOORD_WGS”: Die Länge der Felder für die X- und Y-Koordinaten wird von 10 auf 11 Zeichen erhöht. Die Attribute, welche diesen beiden Feldern folgen, werden um 2 Positionen verschoben.
  • zwei neue Dateien “GLEISE_LV95” und “GLEISE_WGS” werden zur Verfügung gestellt. Sie haben denselben Inhalt wie die Dateien “GLEIS_LV95” und “GLEIS_WGS”. Allerdings haben sich die Kennungen, um die folgenden Informationen zu unterscheiden, geändert:
  • Die neue Kennung für die SLOID ist der Wert g. (Die alte Kennung war der Wert I).
  • Die neue Kennung für die Koordinaten ist der Wert k. (Die alte Kennung war der Wert K).

Die Informationen zu den Gleisen (Kennung G) und Sektoren (Kennung A) sind auf getrennten Zeilen zu übermitteln.

Hinweis:

Bitte beachten Sie, dass die Dateien GLEIS, GLEIS_LV95 und GLEIS_WGS bei der für das zweite Quartal 2024 geplanten Entwicklung nicht mehr zur Verfügung stehen werden.

 

2023-08-07: OJP: Wartungsarbeiten / Maintenance work

Am Montag, 07.08.2023 zwischen 21:00-24:00 Uhr finden geplante Wartungsarbeiten statt. Es wird während der Wartung voraussichtlich zu keinen Ausfällen kommen. Wir danken für Ihr Verständnis.

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: Fahrplandaten von MBC korrigiert

Die Fahrplandaten von MBC wurden korrigiert und stehen wieder zur Verfügung.

Les données des MBC ont été corrigées et sont donc à nouveau disponibles.

 

2023-06-28: Fahrplandaten von MBC momentan nicht aktualisiert

Die Fahrplandaten von MBC können zur Zeit wegen technischen Problemen beim Lieferanten nicht aktualisiert werden. Ein Update folgt sobald vorhanden.

Les données horaires des MBC ne peuvent actuellement pas être actualisées en raison de problèmes techniques chez le fournisseur. Une mise à jour suivra dès qu’elle sera disponible.

 

2023-06-12: ASTRA: Aktualisierung der Allgemeinen Geschäftsbedingungen des ASTRA

Die Allgemeinen Geschäftsbedingungen (AGB) des ASTRA wurden aktualisiert.

 

2023-06-06: ASTRA: Keine Echtzeit-Strassenverkehrsdaten zwischen 11-16 Uhr

Aufgrund technischer Probleme wurden am 06. Juni 2023 zwischen 11-16 Uhr keine Echtzeit-Strassenverkehrsdaten geliefert.

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

 

2023-04-24: ODMCH: Ist-Daten-File nicht ganz komplett

Beim Export der Ist-Daten vom 24.04.2023 gab es einen Fehler. Das File konnte wiederhergestellt werden und wurde am 01.05.2023 ersetzt. Zu beachten ist jedoch, dass die Datei aufgrund eines technischen Problems unvollständig ist.

 

2023-03-06: ODMCH/OJP: Migration: Neu generierte API-Keys werden nicht gespeichert / Generated API keys will not be stored zwischen dem 6. und 8. März 2023

Aufgrund einer technischen Migration werden API-Keys, die zwischen dem 06.03. und dem 08.03.2023 erstellt werden, nicht gespeichert. Entsprechend müssen nach dem 08.03.2023 neue Keys generiert werden. Am 08.03.2023 kann es zu kurzen Ausfällen kommen. Wir danken ihnen für Ihr Verständnis.

UPDATE 09.03.2023 / 10 Uhr: In der Nacht vom 08.03. auf den 09.03. kam es aufgrund der Migration zu einem längeren Ausfall der APIs. Wir entschuldigen uns dafür und arbeiten mit Hochdruck daran. Ausser der CKAN-API sollten inzwischen wieder alle APIs stabil sein.

UPDATE 09.03.2023 / 14 Uhr: Auch die CKAN-API ist wieder verfügbar.

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: Falsche Koordinaten in den HRDF-Daten

In den HRDF-Fahrplandaten des 15.02.2023 sind falsche Koordinaten enthalten. Diese sind im Datensatz des 16.02.2023 korrigiert.

 

2023-02-06: ODMCH: Wartungsarbeiten / Maintenance work

Am Montag, 06.02.2023 zwischen 21:00-23:00 Uhr finden geplante Wartungsarbeiten statt. Es kann zu kurzen Unterbrüchen der Plattform kommen, diese sollten jedoch im Sekundenbereich liegen. Wir danken für Ihr Verständnis.

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: Anpassungen der Kosten und Limiten für API-Requests / January 2023: Changes in costs and limits for API requests

Seit 01.01.2023 gelten neue Limiten und Kosten für den Bezug von dienstbezogenen Daten.

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

 

2022-12-31: ODMCH: Ereignisinformationen öV Schweiz (SIRI SX / VDV 736) als Open Data

Seit Ende 2022 stehen auf der Open-Data-Plattform Mobilität Schweiz Ereignisinformationen des öV Schweiz (SIRI SX / VDV 736) in einer neuen Schnittstelle zur Verfügung.

Der Dienst stellt alle Ereignisinformationen der Transportunternehmen in der Schweiz zur Verfügung, die an die zentrale Datendrehscheibe (DDS SKI) angeschlossen sind. Die laufend aktualisierten Daten können via API auf der Open-Data-Plattform als XML-Datei bezogen werden. Weitere Informationen dazu findet ihr auf der entsprechenden Cookbook-Seite.

Am Mittwoch, 25.01.2023, 16-17 Uhr führten wir ein Online-Meetup zum Thema Ereignisinformationen (VDV 736 und GTFS-RT Service Alerts) durch. Die Folien aus der Präsentation stehen unter diesem Link zur Verfügung.

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

Die Domain opentransportdata.swiss war am 28.12.2023 um ca. 20 Uhr bis 29.12.2023 12:15 nicht erreichbar. Grund war ein Zwischenfall beim Registrar. Für allfällige Probleme und die Umstände entschuldigen wir uns bei allen Nutzenden der Open-Data-Plattform Mobilität Schweiz.

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: Fehlende Ist-Daten / Missing Actual Data

Aufgrund einer Netzwerkstörung am 9.11.2022 sind für diesen Tag Ist-Daten nur in sehr beschränktem Umfang vorhanden.

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

Known Issues

  • In einigen fällen gibt es im Bereich LEX Linienbezeichnungen wie “L3_4”. Diese erhalten wir von der SNCF und sind falsch. Leider können wir das selber nicht ändern und müssen warten, bis die SNCF das Problem gelöst hat. Behebungsdatum: Unbekannt.

2022-08-24: Wichtige Information vom 24.08.2022

Heute um 04:55 wurden das File gtfs_fp2022_2022-08-24_04-15.zip veröffentlicht, bei welchen in stops.txt fälschlicherweise keine Steige mehr enthalten sind, sondern nur noch Bereiche, also z.B. nur noch “8507086:0” statt “8507086:0:2” und “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″

stop_times.txt beinhaltet aber weiterhin Referenzen auf die Steige, z.B. “8507086:0:2”, welche dann nicht mehr auf die Referenz “8507086:0” in stops.txt passt.

Als Workaround haben wir die stops.txt von gtfs_fp2022_2022-08-17_04-15.zip nach gtfs_fp2022_2022-08-24_10-23.zip kopiert, welche soeben neu veröffentlicht wurden und somit die gtfs_fp2022_2022-08-24_04-15.zip abgelöst haben.

Leider sind dadurch sicher noch nicht alle Errors behoben, aber es fehlen in gtfs_fp2022_2022-08-24_10-23.zip sicher viel weniger Referenzen als in gtfs_fp2022_2022-08-24_04-15.zip.

Wir arbeiten mit Hochdruck an einer neuen Version.

Wir bitten um Entschuldigung, danken für Ihre Geduld und halten euch betreffend neuer Version der Daten auf dem Laufenden.

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: Ab 14.7. 2022 | Du 14.7. 2022 | From 14.7. 2022

DE: Ab der Migration auf EFA 10.5 und der gleichzeitigen Freischaltung der Mehrsprachigkeit wird bei OJP nicht mehr nur bei einzelnen Textelementen das xml:lang-Attribut gesendet wird, sondern bei allen.

FR : Depuis la migration vers EFA 10.5 et l’activation simultanée du multilinguisme, l’attribut xml:lang n’est plus envoyé uniquement pour les éléments de texte individuels dans OJP, mais pour tous.

EN: 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.

Beispiel

EFA 10.4 ohne xml:lang-Attribut bei PublishedLineName.Text (bei Name.Text und ShortName.Text wird xml:lang-Attribut bereits jetzt gesendet):
<ojp:Name>
<ojp:Text xml:lang=”de”>Zug</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 neu auch mit xml:lang-Attribut bei PublishedLineName.Text
<ojp:Name>
<ojp:Text xml:lang=”de”>Zug</ojp:Text>
</ojp:Name>
<ojp:ShortName>
<ojp:Text xml:lang=”de”>IC</ojp:Text>
</ojp:ShortName>
</ojp:Mode>
<ojp:PublishedLineName>
<ojp:Text xml:lang=”de”>IC1</ojp:Text>
</ojp:PublishedLineName>

 

2022-06-29: Ab 29.6. 2022 | Du 29.6. 2022 | From 29.6. 2022

DE: Per sofort werden GTFS-Daten mit der zusätzlichen Spalte “block_id” in trips.txt bereitgestellt.

FR: Les données GTFS avec la colonne supplémentaire “block_id” seront fournies dans trips.txt avec effet immédiat.

EN: GTFS data with the additional column “block_id” will be provided in trips.txt with immediate effect.

trips.txt (trips mit 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″

DE: Bei den an der Grenze geschnittenen Fahrten z.B. von Singen nach Schaffhausen werden die block_ids noch nicht enthalten sein.
Dafür wird noch eine Erweiterung in unserem GTFS-Export benötigt, welche aktuell getestet wird.

FR : Les block_ids ne seront pas encore inclus pour les trajets coupés à la frontière, par exemple de Singen à Schaffhouse.
Cela nécessite une extension dans notre export GTFS, qui est actuellement en cours de test.

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

 

2022-06-20: Updates

  • Das Cookbook wurde aktualisiert. Aktuell sind die Änderungen nur in der Deutschen Version zugänglich. // EN: The cookbook was updated. The changes are currently only available in German. Other languages to be added soon.
  • 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.

Validierung OJP Requests (english/french below)

Weil einige OJP-Anwender am 01. März 2022 noch nicht bereit waren, konnte die Validierung der OJP-Anfragen noch nicht wie angekündigt aktiviert werden.
Deshalb werden neu ab dem 02. Mai 2022 alle OJP-Anfragen mittels ojp-xsd-v1.0 validiert. Entspricht eine Anfrage nicht den Vorgaben der xsd, wird sie mit “HTTP/1.1 400 Bad Request” zurückgewiesen.
Ein aktuell häufig auftretender Verstoss gegen die xsd-Vorgaben ist das Weglassen des Elementes <LocationName> in der PlaceRefStructure z.B. im OJPStopEventRequest oder OJPTripRequest.
Wenn beim Bilden von OJPStopEventRequest oder OJPTripRequest kein geeigneter LocationName zur Verfügung steht, kann alternativ <ojp:Text>unknown</ojp:Text> gesendet werden.

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.”

Validation des Requests OJP

Certains utilisateurs OJP n’étant pas prêts au 1er mars 2022, la validation des requêtes OJP n’a pas pu être activée comme annoncé.
Par conséquent, à partir du 2 mai 2022, toutes les demandes OJP seront validées à l’aide de ojp-xsd-v1.0. Si une requête ne répond pas aux spécifications xsd, elle est rejetée avec “HTTP/1.1 400 Bad Request”.
Une violation fréquente des spécifications xsd actuellement est l’omission de l’élément <LocationName> dans PlaceRefStructure, par exemple dans OJPStopEventRequest ou OJPTripRequest.
Si aucun LocationName approprié n’est disponible lors de la formation de OJPStopEventRequest ou OJPTripRequest, <ojp:Text>inconnu</ojp:Text> peut être envoyé comme alternative.”

 

2021-02-17: Updates

  • Problem bei La Gottaz gelöst. Es gab beim Fusswegrouting.
  • Das Matching zwischen Echtzeit und Fahrplan wurden verbessert. Jetzt werden auch Fahrten berücksichtigt, die nicht beim FahrtStart-Ende übereinstimmen.

 

2021-02-03: Changes in GTFS Static

  • GTFS Static: Die Dateinamen enthalten neu “_hh-mm”.

2021-01-22: Namen S-Bahnen geändert

  • Die Namen von S-Bahnen waren irrtümlich z.T. auf S1 gestellt worden. Dies wurde korrigiert mit einer neuen Version von GTFS Static. GTFS-RT wurde sofort aktiviert für das neue Static.

2021-01-21: GTFS Probleme

  • In der Datenaktivierung von gestern haben viele Zugfahrten gefehlt (ca. 100 S-Bahn-Linien). Das Problem wurde korrigiert mit einem neuen GTFS Static (https://opentransportdata.swiss/de/dataset/timetable-2021-gtfs2020) und einer sofortigen Aktivierung in der Echtzeit. D.h. das neue Static muss für das GTFS-RT geladen werden. OJP2020 und TRIAS2020 liefern damit auch wieder die korrekten Ergebnisse.
  • NumberOfResults wird im Server nicht immer perfekt eingehalten. Wenn eine “Gruppe” von Antworten mit gleicher Wahrscheinlichkeit angeschnitten wird, so wird die vollständige Gruppe zurückgeliefert, egal was angegeben wurde. Beispiel: Die Anfrage im LocationInformationRequest “St. Gallen, Haggen” liefert zwei Stops zurück: “St. Gallen, Haggen” und “St. Gallen Haggen”. D.h. es immer mit einem ResultSet zur rechnen.
    Anfragebeispiel:

    <?xml version="1.0" encoding="UTF-8"?>
    <OJP xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns="http://www.siri.org.uk/siri" version="1.0"
    xmlns:ojp="http://www.vdv.de/ojp" xsi:schemaLocation="http://www.siri.org.uk/siri ../ojp-xsd-v1.0/OJP.xsd">
    	<OJPRequest>
    		<ServiceRequest>
    			<RequestTimestamp>2020-09-17T11:55:48Z</RequestTimestamp>
    			<RequestorRef>theRequestorRef_test</RequestorRef>
    			<ojp:OJPLocationInformationRequest>
    				<RequestTimestamp>2020-01-09T08:00:00Z</RequestTimestamp>
    				<MessageIdentifier>0</MessageIdentifier>
    				<ojp:InitialInput>
    					<ojp:LocationName>St. Gallen Haggen</ojp:LocationName>
    				</ojp:InitialInput>
    				<ojp:Restrictions>
    					<ojp:Type>stop</ojp:Type>
    					<ojp:NumberOfResults>1</ojp:NumberOfResults>
    				</ojp:Restrictions>
    			</ojp:OJPLocationInformationRequest>
    		</ServiceRequest>
    	</OJPRequest>
    </OJP>

2021-01-20: GTFS Pseudohaltestellen entfernt

  • Mit der Aktivierung der neuen Daten am nächsten Mittwoch 20.01.2021 (GTFS-S morgens um 09:00, GTFS-R und OJP am Nachmittag um 14:00) werden die Pseudo-Haltestellen gemäss “neuem Verhalten” gesendet. Aktuelles Verhalten:
    ****************
    GTFS-S: Bahn-2000-Strecke wird normal gesendet
    GTFS-R: Bahn-2000-Strecke wird gesendet mit “ScheduleRelationship”: “Skipped”
    OJPTripDelivery ohne Echtzeit: StopPointRef 132 wie normaler Halt
    OJPTripDelivery mit Echtzeit: StopPointRef 132 mit NotServicedStop=trueneues Verhalten:
    **************
    GTFS-S: Bahn-2000-Strecke wird nicht mehr gesendet
    GTFS-R: Bahn-2000-Strecke wird nicht mehr gesendet
    OJPTripDelivery mit und ohne Echtzeit: Bahn-2000-Strecke wird nicht mehr gesendet (nur noch als Location in TripResponseContext)

2017-05-22: Neue Daten

  • 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/de/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: Neuerungen

  • 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