Skip to content
LoginRegister
DEENFRIT
Home
Plateforme open data pour la mobilité en Suisse
  2. Remarques importants / changements

Remarques importants / changements

Prévu

2024-06-26 Préavis – Arrêt de l’interface TRIAS au T4/2024

Nous cesserons d’utiliser l’interface TRIAS dans le courant du 4e trimestre 2024. Comme alternative à TRIAS, nous proposons la nouvelle norme CEN OJP 2.0. La date exacte de l’arrêt n’est pas encore connue.

Actuel

2024-10-17 : Activation du GTFS-RT à 16h au lieu de 15h

Comme les données statiques GTFS ont été publiées plus tard aujourd’hui, les données GTSF en temps réel ne seront activées qu’à 16 heures.

2024-10-10 : Fichier HRDF erroné LINIE

Dans le fichier HRDF LINIE, il manque parfois des espaces pour déplacer les couleurs dans les colonnes spécifiées. L’erreur est signalée au fournisseur de données.

2024-10-10 : Retard dans l’activation des nouvelles données GTFS

Les données statiques GTFS ne seront publiées qu’aujourd’hui dans l’après-midi. L‘activation des données GTFS-RT suivra demain vendredi 11.10.2024 à environ 8 heures.

2024-09-12 Jeux de données de test HRDF directives de réalisation 2.0.6 et 2.0.7 disponibles

Les données de test avec les adaptations pour les spécifications de réalisation 2.0.6 et 2.0.7 sont disponibles dès maintenant (1x “normal” et 1x pour les automobilistes). Les adaptations et extensions des spécifications de réalisation 2.0.6 et 2.0.7 seront mises en production fin octobre 2024. Vous trouverez les principales adaptations dans le Cookbook. Pour plus d’informations, consultez le nouveau modèle de réalisation HRDF.

2024 (Historique)

2024-08-29 Pas de mise à jour des données pour OJP / GTFS / NeTEx

Mise à jour : Les données du 2024-08-29 ont été mises à jour, mais il n’y a pas de nouvelles données pour le 2024-09-02.

Les données horaires pour OJP / GTFS / NeTEx n’ont pas été mises à jour aujourd’hui.

2024-08-28 Mise à jour: GTFS-RT: les champs de données route_id sont vides

Mise à jour: Le route_id est à nouveau fourni

En raison d’une erreur de programmation, le flux GTFS-RT contient des champs route_id vides, à partir du 2024-08-21, mais ne découverts que récemment.

Les développeurs du fournisseur travaillent à la résolution de ce problème. Nous espérons que ce problème sera bientôt résolu.

2024-08-14 Résolu: Problème avec GTFS-RT

Le service GTFS-RT est perturbé, les données ne circulent pratiquement plus. Nous travaillons à la résolution du problème.

2024-08-09 Corrigé: Dérangement CKAN

Les jeux de données sont à nouveau disponibles. Nous vous prions de nous excuser pour la gêne occasionnée. Les API n’ont pas été affectées par la panne.

2024-08-01 Pas de mises à jour le 1er août

Aucune mise à jour des données ne sera effectuée/activée le 1er août.

2024-07-29 Flux des données en temps réel des feux de signalisation interrompu

Actuellement, il n’est pas possible de publier des données en temps réel des feux de signalisation. Nous attendons la résolution d’un problème.

2024-07-16 Migration de l’API Gateway

Le 16.07.2024, nous déménageons l’API Gateway. Malheureusement, une panne inattendue des API s’est produite. Nous nous excusons auprès de nos utilisateurs.

2024-06-06 Travaux de maintenance programmés

Des travaux de maintenance auront lieu le 6 juin 2024 entre 18 et 20 heures. Il peut y avoir de courtes interruptions pendant l’entretien.

 

2024-06-03 Travaux de maintenance programmés

Des travaux de maintenance auront lieu le 3 juin 2024 entre 21h et 24h. Il n’y aura vraisemblablement pas d’interruption de service pendant la 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

Nous mettrons en correspondance d’autres offres (Listes de moyens de transport et des indications (Dataset)) avec des installations SIRI dans la réponse.

 

2024-05-24 Publication des données du projet d’horaire 2025

Les nouvelles données du projet d’horaire pour 2025 sont disponibles dès à présent : https://opentransportdata.swiss/fr/dataset/timetable-54-draft-hrdf

 

2024-05-19/20 Panne de notre système de gestion des données CKAN

Du 19 mai 8:00 au 20 mai 16:30, panne totale du système CKAN, de sorte qu’aucun dataset n’a malheureusement pu être obtenu. Nous vous prions de nous excuser et vous remercions de votre compréhension.

 

2024-05-09/12: GTFS Static n’est pas correctement mis à jour le jour de l’Ascension

Le jour de l’Ascension, le GTFS Static n’a pas été publié par erreur. Le temps réel a cependant été commuté. C’est pourquoi, jusqu’à la version de lundi, il y avait dans de nombreux cas une incompatibilité avec le temps réel.

 

2024-04-27: Dysfonctionnement VDP : courtes interruptions dans la disponibilité des données routières

Les API des données routières peuvent actuellement subir de brèves pannes de l’ordre de quelques minutes. Nous travaillons à la résolution de ces problèmes. Merci de votre compréhension. Pour des informations sur le statut, voir également https://status.opentransportdata.swiss.

 

2024-04-22: Commutation de GTFS-RT sur LINUX et une nouvelle version

Dès maintenant, on attend des réponses GTFS-RT jusqu’à deux fois plus importantes, car désormais, pour les heures de consigne VDV454 au dixième de minute près, leur écart par rapport aux heures de consigne GTFS à la minute près est transmis.
Ainsi, les clients GTFS profitent désormais aussi de la planification au dixième de minute près, qui ne peut pas être fournie dans les données statiques GTFS.

Les réponses GTFS RT sont désormais censées être jusqu’à deux fois plus importantes, car l’écart entre les temps cibles VDV454 exacts au dixième d’une minute et les temps cibles GTFS exacts à la minute est désormais transmis.
Cela signifie que les clients GTFS bénéficient désormais d’une planification précise à la minute près, ce qui n’est pas disponible dans les données statiques GTFS.

 

2024-04-18: La mise en ligne de GTFSR vers Linux est reportée au lundi 22 avril.

 

2024-04-18: La mise à jour des données statiques GTFS est annulée aujourd’hui

La deuxième mise à jour des données statiques GTFS est malheureusement annulée cette semaine. La prochaine mise à jour est prévue pour lundi prochain, le 22 avril. La deuxième mise à jour des données statiques GTFS a malheureusement été annulée cette semaine. La prochaine mise à jour est prévue pour le lundi 22 avril prochain.

 

2024-04-15: Remplacement des jeux de données existants “Inventaire LHand”

A partir du 15 avril 2024, les données relatives à l’accessibilité des arrêts des TP suisses seront saisies dans l’application atlas. Le système actuel “DiDok” sera ainsi remplacé. Cela se répercute également sur la publication des données de l’état des lieux de la LHand.

Les principales modifications

  • Publication de trois versions (actual, future_timetable, full) par analogie avec les services des TP suisses (servicePoints).
  • Adaptations mineures aux noms des champs. L’étendue des données mises à disposition reste la même.
  • A l’avenir, les jeux de données seront publiés individuellement. L’utilisation du permalien devient donc possible.
  • Les guichets de vente de billets et d’information sont désormais regroupés dans un seul objet.
  • Publication au format zip.

Preview:

Afin de pouvoir préparer le passage aux nouveaux enregistrements, vous trouverez ici un exemple d’enregistrement de tous les fichiers ainsi que la description des données. Veuillez ne pas utiliser ces données de manière productive.

 

2024-04-11: GTFS-Flex a été publié.

Nous sommes l’un des premiers fournisseurs au monde à proposer des offres à la demande dans l’extension de GTFS, à savoir GTFS-Flex.

 

2024-04-08: Changement prévu des données statiques GTFS, à 2 publications par semaine, en retard.

La prochaine mise à jour (avec le nouveau cycle de publication) est prévue pour le jeudi 11 avril.

 

2024-03-28: Résolu : APIs momentanément inaccessibles.

Nous travaillons d’arrache-pied pour trouver une solution.

 

2024-03-27: Maintenance ce soir entre 20:00-23:00

Des travaux de maintenance seront effectués ce soir entre 20h et 23h. Il peut y avoir de courtes interruptions (max. 15 minutes) pour les pages de cookbook et les enregistrements. Nous nous efforçons de réduire au maximum les interruptions. Les API ne sont pas concernées.

 

2024-03-20: UPDATE Panne résolue : les API sont de nouveau disponibles

La plateforme et toutes les API sont à nouveau disponibles. Nous nous excusons auprès de tous nos utilisateurs pour les désagréments causés.

 

2024-03-20: Problèmes de réseau : Les API ne sont pas disponibles pour le moment

Nous nous efforçons de résoudre ces problèmes au plus vite.

 

2024-03-14: GTFS 2x par semaine, nouvel attribut SJYID, enquête et appel à sujets

 

2024-03-04: Problèmes avec GTFS-RT

Mise à jour : les données GTFS-RT sont à nouveau disponibles, le problème a été résolu.

Les données en temps réel via GTFS-RT font actuellement défaut. Nous travaillons à la résolution du problème.

 

2024-02-05: OJP: Bug

En cas de panne partielle, le Not_Service_Stop=true manque sur le dernier arrêt dans OJP 1.0.

 

2024-03-04: Correction: Panne: enregistrements inaccessibles

Les jeux de données et les services sont actuellement inaccessibles, nous sommes en train de corriger l’erreur.

 

2024-02-29: Travaux de fin d’études CKAN Update

 

2024-02-28: CKAN: mise à jour et adaptation des fonctionnalités

Le mercredi 28 février 2024, CKAN recevra une mise à jour. Il faut s’attendre à ce que les jeux de données soient ainsi inaccessibles pendant une période plus courte. Nous essayons de réduire au maximum ces interruptions. Après la mise à jour à venir, la possibilité de suivre des enregistrements et de voir leurs dernières modifications ne sera plus disponible.

 

2024-02-19: OJP: nouvelle infrastructure pour OJP et TRIAS

Nous sommes passés ce matin à 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 se font désormais toutes les 30 secondes. Cela bloque actuellement le moteur pendant 2 secondes à chaque fois. Nous travaillons sur ce problème. Nous pouvons aussi passer à la mise à jour par 60 secondes si vous 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).

 

2024-02-12: OJP: Sloid in StopPointRef

Depuis le début de l’année, nous passons à des données à précision croissante dans OJP. Lorsque la livraison est effectuée en montée, elle l’est également en descente. Les données à forte pente sont toujours exécutées avec un SLOID et non plus un numéro de didoc. Des réponses mixtes sont toutefois possibles et des modifications par opérateur/lignes peuvent intervenir à tout moment.

Ancien:

Nouveau:

 

Ancien:

Nouveau:

Cela permet aussi de meilleures voies de circulation.

Les conversions se déroulent comme suit:

  • Méthodologie de conversion (si vous travaillez en interne avec DiDok) pour sloid -> didok:
    • Si sloid est dans la chaîne,
    • Choisir le bon élément, le convertir en nombre et ajouter 8’500’000 (ex. ch:1:sloid:1026:1:2 -> 8501026)

    Il s’agit bien entendu d’un hack. En réalité, il faudrait utiliser une table de correspondance. Nous partons toutefois du principe que les derniers numéros de didoc disparaîtront pour la Suisse avant que cela ne devienne un problème.

     

  • Didok -> sloid fonctionne de manière similaire. Toutefois, cela peut poser des problèmes pour les arrêts étrangers:
    • En principe, ne convertir que 85xxxxx, sauf le trafic local étranger, que nous avons également dû saisir dans nos systèmes (8500700 -> ch:1:sloid:700)
    • Trafic local étranger : 11xxxxx, 12xxxxx, 13xxxxx, 14xxxxx => ch:1:sloid:<didok> (Ex “Annemasse, Adrien Ligué” : 1401664 à ch:1:sloid:1401664)

 

2024-02-08: Problèmes avec la fonction de recherche

Actuellement, la recherche ne fonctionne pas comme prévu. Nous travaillons à la résolution du problème.

 

2024-02-03: OJP en bref Adaptations prévues

  • Les temps sont désormais indiqués en dixièmes de minute (à 6 secondes près) lorsqu’ils sont disponibles. Actuellement, elles ne sont éditées qu’à la minute près.
  • OJP utilise désormais le texte de direction du temps réel (de VDV 454 AUS/REF-AUS) comme DestinationText. Pour le jour de fonctionnement actuel, cela améliore l’indication de la destination dans certains cas.
  • Nous essayons également de reproduire les traits d’ombre sur les lignes. Toutefois, quelques tests sont encore nécessaires à cet égard. Nous utilisons à cet effet les relations de transport VDV).

 

2024-01-24: Adaptations dans l’exportation de statiques GTFS

Suite aux réactions de nos acheteurs de données concernant le fichier stops.txt, nous avons procédé à certaines adaptations de l’exportation statique GTFS.

Dans l’exportation GTFS gtfs_fp2024_2024-01-24_04-15

  • tous les ponts (même si l’arrêt n’a qu’un seul pont) sont attribués à un parent
  • les parents ont désormais aussi le “nom de l’arrêt avec lieu” au lieu du “nom de l’arrêt sans lieu”

Exemple (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: Autre manipulation Swiss Journey Identification (SJYID) en temps réel

A partir du 1er février 2024, l’élément “FahrtBezeichner” sera partiellement rempli avec un Swiss Journey ID (SJYID, document en Allemand). Jusqu’à présent, les utilisateurs de données pouvaient partir du principe que

  • les SJYID générés/fournis soient repris comme identificateurs de trajets et transmis aux bénéficiaires des données.
  • un SJYID soit généré comme identificateur de trajet pour tous les moyens de transport repris, si aucun n’a été fourni.
  • pour les trains supplémentaires créés à court terme, un SJYID est généré comme identificateur de trajet.

A la demande de la branche TP CH, ce comportement doit être modifié comme suit à une date qui reste à définir:

  • les SJYID générés/fournis dans l’horaire sont repris comme identificateurs de trajets et transmis tels quels aux destinataires des données.
  • un SJYID en tant qu’identificateur de trajet n’est généré que si aucun n’a été fourni et qu’il s’agit d’un moyen de transport de NeTS.
  • pour les trains supplémentaires créés à court terme, un SJYID est généré comme identificateur de trajet.

Cela concernera les ensembles de données suivants:

Veuillez noter que SJYID n’est pas encore pris en charge par GTFS. Cela est prévu pour la fin du premier trimestre 2024.

Pour plus d’informations, voir tp-info.ch

 

2024-01-31: Remplacement de jeux de données existants (services, organisations commerciales, Swiss Line ID)

Contribution du 18.12.2023

Les jeux de données suivants ne seront plus mis à jour au 31 janvier 2024:

Les ensembles de données suivants peuvent être utilisés en remplacement:

 

2024-01-16: Adaptation des directives de réalisation HRDF 2.0.5 : Nouvelle version 16.01.2024

Vous trouverez de plus amples informations dans le document HRDF-Realisierungsvorgaben – öV-Schweiz (document en Allemand).

Les développements suivants sont prévus :

  • Fichiers “BFKOORD_LV95” et “BFKOORD_WGS” : la longueur des champs pour les coordonnées X et Y passe de 10 à 11 caractères. Les attributs qui suivent ces deux champs sont déplacés de 2 positions.
  • deux nouveaux fichiers “GLEISE_LV95” et “GLEISE_WGS” sont mis à disposition. Ils ont le même contenu que les fichiers “GLEIS_LV95” et “GLEIS_WGS”. Cependant, les identifiants permettant de distinguer les informations suivantes ont changé :
  • Le nouvel identifiant pour le SLOID est la valeur g. (L’ancien identifiant était la valeur I).
  • Le nouvel identifiant pour les coordonnées est la valeur k. (L’ancien identifiant était la valeur K).

Les informations relatives aux voies (identifiant G) et aux secteurs (identifiant A) doivent être transmises sur des lignes distinctes.

Nous mettons à votre disposition un jeu de données test avec les nouvelles adaptations.

Remarque:

Veuillez noter que les fichiers GLEIS, GLEIS_LV95 et GLEIS_WGS ne seront plus disponibles lors du développement prévu pour le quatrième trimestre 2024.

 

2024-01-15: Manque d’informations en temps réel (GTFS-RT)

2024-01-16 Mise à jour : les données sont à nouveau disponibles.

Actuellement, certaines informations en temps réel manquent dans le GTFS-RT, notamment pour le trafic local dans les villes de Zurich, Bâle, Berne, Lucerne. Nous sommes en train de l’analyser afin que les données soient à nouveau disponibles dans leur intégralité dès que possible.

 

2023 (Historique)

2023-12: Mise à jour des données pendant les fêtes

Pendant les fêtes, les données HRDF seront disponibles sans interruption, mais leur contenu ne changera pas ou très peu. Les autres systèmes (GTFS-S, GTFS-RT, TRIAS, OJP) ne seront pas mis à jour avec un nouvel horaire le mercredi 27 décembre 2023.

 

2023-12-10: Trajets supplémentaires erronés dans GTFS-RT

Le 10.12.2023 au matin, la réponse GTFS-RT comportait à chaque fois par erreur environ 65 000 courses supplémentaires, en raison d’un problème de concordance avec les données théoriques. Un workaround a permis de résoudre les problèmes, à l’exception de quelques trajets supplémentaires. Nous analysons l’erreur en détail et vous prions de nous excuser pour les désagréments occasionnés.

 

2023-12-10: Changement d’horaire 2023/24

Au cours de la semaine du mercredi 06.12.2023 au mercredi 13.12.2023, les deux ensembles de données statiques GTFS 23 et 24 se chevaucheront pour inclure la période du lundi 04.12.2023 au mercredi 13.12.2023. Cela vous permettra de passer aux nouvelles données statiques GTFS à n’importe quel moment entre les deux mercredis (avant et après le changement d’horaire) et les données GTFS-RT seront toujours adaptées.

 

2023-12-08: OJP/Trias – Mise à niveau de l’ensemble des services

Le 8 décembre, la solution globale sera migrée. Il ne devrait pas y avoir d’interruptions. Le système de base est migré vers la dernière version. Il s’agit d’une étape vers le déploiement d’OJP 2.0. Si des problèmes surviennent malgré tout chez des acheteurs, veuillez impérativement les signaler immédiatement à opendata@sbb.ch. Le passage à Linux se fera d’ici fin février. La date exacte sera communiquée.

 

2023-11-27: Panne de réseau résolue

Mise à jour 16h : Les systèmes sont de nouveau stables et les API devraient être de nouveau accessibles sans restriction. Nous vous prions de nous excuser pour la gêne occasionnée et vous remercions de votre compréhension.

Mise à jour 14h45 : Une solution de contournement temporaire a été mise en place, ce qui permet de stabiliser la situation. Les travaux se poursuivent pour résoudre le problème sous-jacent.

Depuis environ 9 heures, des problèmes de réseau entraînent des interruptions dans l’accessibilité des API. Nous travaillons d’arrache-pied à la résolution des problèmes et continuerons à vous informer ici dès que des mises à jour seront disponibles.

 

2023-10-23: OJP/Trias – Un service plus lent

En raison de différents facteurs, les OJP/TRIAS ont été considérablement ralenties. Une offre ODV était configurée de manière sous-optimale et entraînait des calculs de trajets à pied considérables, le niveau de log était plus élevé pour l’analyse du problème et le fait que nous tenions actuellement les horaires 2023 et 2024 dans le système n’était pas encore entièrement pris en compte. Un nouvel utilisateur a également été activé avec 300 000 requêtes par jour et des tests de charge ont été effectués par un autre utilisateur. L’offre a été supprimée (elle n’existe d’ailleurs plus), le niveau de log a été abaissé, la mémoire des systèmes a été augmentée. Dans ce contexte, le nouveau système de surveillance des performances a été amélioré et mis en service.

 

2023-10-15 OJP : deux années d’horaire actives

Afin d’obtenir un aperçu à 120 jours, une première version de l’horaire 2024 a été insérée dans l’OJP.

 

2023-09-01: ODMCH : adaptation des directives de réalisation HRDF 2.0.5 : nouvelle version début 2024

Vous trouverez de plus amples informations dans le document HRDF-Realisierungsvorgaben – öV-Schweiz (document en Allemand).

Les développements suivants sont prévus :

  • Fichiers “BFKOORD_LV95” et “BFKOORD_WGS” : la longueur des champs pour les coordonnées X et Y passe de 10 à 11 caractères. Les attributs qui suivent ces deux champs sont déplacés de 2 positions.
  • deux nouveaux fichiers “GLEISE_LV95” et “GLEISE_WGS” sont mis à disposition. Ils ont le même contenu que les fichiers “GLEIS_LV95” et “GLEIS_WGS”. Cependant, les identifiants permettant de distinguer les informations suivantes ont changé:
  • Le nouvel identifiant pour le SLOID est la valeur g. (L’ancien identifiant était la valeur I).
  • Le nouvel identifiant pour les coordonnées est la valeur k. (L’ancien identifiant était la valeur K).

Les informations relatives aux voies (identifiant G) et aux secteurs (identifiant A) doivent être transmises sur des lignes distinctes.

Remarque:

Veuillez noter que les fichiers GLEIS, GLEIS_LV95 et GLEIS_WGS ne seront plus disponibles lors du développement prévu pour le deuxième trimestre 2024.

 

2023-08-07: OJP : Travaux de maintenance

Des travaux de maintenance planifiés auront lieu le lundi 07.08.2023 entre 21:00 et 24:00 heures. Il n’y aura vraisemblablement pas d’interruption de service pendant la maintenance. Nous vous remercions de votre compréhension.

 

2023-07-03: Données horaires de MBC corrigées

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

 

2023-06-28: Les données horaires de MBC ne sont pas actualisées pour le moment

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: OFROU : mise à jour des conditions générales de l’OFROU

Les conditions générales (CG) de l’OFROU ont été mises à jour.

 

2023-06-06: OFROU : pas de données routières en temps réel entre 11h et 16h

En raison de problèmes techniques, aucune donnée de trafic routier en temps réel n’a été fournie le 06 juin 2023 entre 11h et 16h.

 

2023-04-24: ODMCH : fichier de données réelles pas tout à fait complet

Une erreur s’est produite lors de l’exportation des données réelles du 24/04/2023. Le fichier a pu être récupéré et a été remplacé le 01/05/2023. Il convient toutefois de noter que le fichier est incomplet en raison d’un problème technique.

 

2023-03-06: Migration : les clés API nouvellement générées ne seront pas enregistrées entre le 6 et le 8 mars 2023

En raison d’une migration technique, les clés API créées entre le 06.03 et le 08.03.2023 ne seront pas enregistrées. En conséquence, de nouvelles clés devront être générées après le 08.03.2023. Le 08.03.2023, il peut y avoir de courtes pannes. Nous vous remercions de votre compréhension.

UPDATE 09.03.2023 / 10h : Dans la nuit du 8 au 9 mars, la migration a entraîné une panne prolongée des API. Nous nous en excusons et travaillons d’arrache-pied pour y remédier. A l’exception de l’API CKAN, toutes les API devraient à nouveau être stables.

UPDATE 09.03.2023 / 14h : L’API CKAN est également à nouveau disponible.

 

2023-02-16: ODMCH : coordonnées erronées dans les données HRDF

Les données de l’horaire HRDF du 15 février 2023 contiennent des coordonnées erronées. Celles-ci sont corrigées dans l’enregistrement du 16.02.2023.

 

2023-02-06: ODMCH : travaux de maintenance

Des travaux de maintenance planifiés auront lieu le lundi 06.02.2023 entre 21h00 et 23h00. Il peut y avoir de courtes interruptions de la plateforme, mais elles devraient être de l’ordre de quelques secondes. Nous vous remercions de votre compréhension.

 

2023-01-01: ODMCH/OJP : ajustements des coûts et des limites pour les requêtes API (janvier 2023)

Depuis le 01.01.2023, de nouvelles limites et de nouveaux coûts sont en vigueur pour l’obtention de données liées au service.

 

2022 (Historique)

2022-12-31: ODMCH : Informations événementielles TP Suisse (SIRI SX / VDV 736) en Open Data

Depuis fin 2022, les informations événementielles des TP suisses (SIRI SX / VDV 736) sont disponibles sur la plateforme Open Data Mobilité Suisse dans une nouvelle interface.

Le service met à disposition toutes les informations sur les événements des entreprises de transport en Suisse qui sont reliées à la plaque tournante centrale des données (DDS SKI). Les données actualisées en permanence peuvent être obtenues via API sur la plateforme Open Data sous forme de fichier XML. Vous trouverez de plus amples informations sur la page Cookbook correspondante.

Le mercredi 25 janvier 2023, de 16 à 17 heures, nous avons organisé un meetup en ligne sur le thème des informations relatives aux événements (VDV 736 et GTFS-RT Service Alerts). Les diapositives de la présentation sont disponibles sous ce lien.

 

2022-12-29: Incident du 28/29.12.2022

Le domaine opentransportdata.swiss n’était pas accessible le 28.12.2023 à environ 20 heures jusqu’au 29.12.2023 12:15. La raison en était un incident chez le registraire. Nous nous excusons auprès de tous les utilisateurs de la plateforme Open Data Mobilité Suisse pour les éventuels problèmes et les circonstances.

 

2022-11-09: Données réelles manquantes

En raison d’une panne de réseau le 9 novembre 2022, les données réelles ne sont disponibles que dans une mesure très limitée pour cette date.

Problèmes connus

  • Dans certains cas, il existe dans le domaine LEX des désignations de lignes telles que “L3_4”. Nous les recevons de la SNCF et elles sont fausses. Malheureusement, nous ne pouvons pas changer cela nous-mêmes et devons attendre que la SNCF ait résolu le problème. Date de la correction : Inconnue.

 

2022-08-24: Information importante du 24.08.2022

Aujourd’hui à 04:55, le fichier gtfs_fp2022_2022-08-24_04-15.zip a été publié, dans lequel les stops.txt ne contiennent plus, par erreur, de pas, mais seulement des plages, donc par exemple seulement “8507086:0” au lieu de “8507086:0:2” et “8507086:0:3” :

stops.txt dans 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 dans 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 contient cependant toujours des références à la passerelle, par exemple “8507086:0:2”, qui ne correspond alors plus à la référence “8507086:0” dans stops.txt.

Comme solution de contournement, nous avons copié le stops.txt de gtfs_fp2022_2022-08-17_04-15.zip vers gtfs_fp2022_2022-08-24_10-23.zip, qui vient d’être republié et qui a donc remplacé gtfs_fp2022_2022-08-24_04-15.zip.

Malheureusement, cela ne résout certainement pas toutes les erreurs, mais il manque certainement beaucoup moins de références dans gtfs_fp2022_2022-08-24_10-23.zip que dans gtfs_fp2022_2022-08-24_04-15.zip.

Nous travaillons d’arrache-pied à une nouvelle version.

Nous vous prions de nous excuser, vous remercions de votre patience et vous tiendrons informés de la nouvelle version des données.

 

2022-07-14: Dès le 14.7.2022

A partir de la migration vers EFA 10.5 et de l’activation simultanée du multilinguisme, l’attribut xml:lang n’est plus seulement envoyé pour certains éléments de texte, mais pour tous.

exemple

EFA 10.4 sans attribut xml:lang pour PublishedLineName.Text (pour Name.Text et ShortName.Text, l’attribut xml:lang est déjà envoyé maintenant) :
<ojp:Nom>
<ojp:Texte xml:lang=”de”>Train</ojp:Texte
</ojp:Nom>
<ojp:ShortName>
<ojp:Text xml:lang=”de”>IC</ojp:Texte>
</ojp:ShortName>
</ojp:Mode>
<ojp:PublishedLineName>
<ojp:texte>IC1</ojp:texte>
</ojp:PublishedLineName>

EFA 10.5 avec attribut xml:lang pour PublishedLineName.Text
&lt;ojp:Nom>
&lt;ojp:Texte xml:lang=”de”>Train&lt;/ojp:Texte
&lt;/ojp:Nom>
&lt;ojp:ShortName>
&lt;ojp:Text xml:lang=”de”>IC&lt;/ojp:Texte>
&lt;/ojp:ShortName>
&lt;/ojp:Mode>
&lt;ojp:PublishedLineName>
<ojp:Text xml:lang=”de”>IC1</ojp:Texte>
&lt;/ojp:PublishedLineName>

 

2022-06-29: Dès le 29.6.2022

Désormais, les données GTFS sont mises à disposition avec la colonne supplémentaire “block_id” dans trips.txt.

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

Pour les trajets coupés à la frontière, par exemple de Singen à Schaffhouse, les block_ids ne seront pas encore inclus.
Pour cela, il faut encore une extension dans notre export GTFS, qui est actuellement testée.

 

2022-06-20: Mises à jour

  • Le Cookbook a été mis à jour. Actuellement, toutes les modifications sont accessibles dans la version allemande, les traductions dans toutes les autres langues suivront dès que possible.
  • La section Actualités a été adaptée pour inclure ce journal des changements afin d’assurer une meilleure transparence des changements sur le site web.
  • Les anciennes notes de publication ont été fusionnées avec cette page.
  • Certains sites web inaccessibles et obsolètes ont été supprimés.

 

2022-06-14: Updates

  • L’instance PROD a été mise à jour à la version 10.5 de l’EPT. Le changement le plus important est que toutes les balises de texte XML contiennent désormais une balise xml:lang. Par exemple <ojp:Text xml:lang=”de”>. La langue souhaitée peut être demandée en ajoutant les lignes suivantes dans le <ServiceRequest> :
    <ServiceRequestContext>
    <Language>de</Language>
    </ServiceRequestContext>
    Les langues disponibles sont : de, fr, it, en

 

2022-06-09: Updates

  • Les pages faisant référence à l’ensemble de données “Bahnstellen”/”gare” ont été supprimées car l’élément de données est obsolète.

 

2022-05-02: Updates

  • Les demandes de l’OJP sont validées par rapport au XSD. Non valide Les demandes ne sont plus servies. Cela peut entraîner des erreurs si les demandes ne sont pas valides.

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 & plus agé (Historique)

2021-02-17: Updates

  • Problème résolu à La Gottaz. Il y a eu des problèmes lors de la randonnée pédestre.
  • La concordance entre le temps réel et l’horaire a été améliorée. Désormais, les trajets qui ne correspondent pas au début et à la fin du trajet sont également pris en compte.

 

2021-02-03: Changements dans GTFS Static

  • GTFS Static : les noms de fichiers contiennent désormais “_hh-mm”.

 

2021-01-22: Changement de nom des trains de banlieue

  • Les noms des trains de banlieue avaient été mis par erreur en partie sur S1. Cela a été corrigé avec une nouvelle version de GTFS Static. GTFS-RT a été immédiatement activé pour le nouveau Static.

 

2021-01-21: Problèmes GTFS

  • Dans l’activation des données d’hier, il manquait de nombreux trajets en train (environ 100 lignes de RER). Le problème a été corrigé avec un nouveau GTFS Static (https://opentransportdata.swiss/de/dataset/timetable-2021-gtfs2020) et une activation immédiate en temps réel. C’est-à-dire que le nouveau static doit être chargé pour le GTFS-RT. OJP2020 et TRIAS2020 fournissent ainsi à nouveau les résultats corrects.
  • NumberOfResults n’est pas toujours parfaitement respecté dans le serveur. Si un “groupe” de réponses a la même probabilité d’être coupé, le groupe complet est renvoyé, peu importe ce qui a été spécifié. Exemple : La demande dans LocationInformationRequest “St. Gallen, Haggen” fournit deux arrêts en retour : “St. Gallen, Haggen” et “St. Gallen Haggen”. C’est-à-dire qu’il faut toujours compter avec un ResultSet.
    Exemple de demande:

 

2021-01-20: Suppression des pseudo-arrêts GTFS

  • Avec l’activation des nouvelles données le mercredi 20.01.2021 prochain (GTFS-S le matin à 09:00, GTFS-R et OJP l’après-midi à 14:00), les pseudo-arrêts seront envoyés selon le “nouveau comportement”. Comportement actuel :
    ****************
    GTFS-S : la ligne Rail 2000 est diffusée normalement
    GTFS-R : le trajet de Rail 2000 est envoyé avec “ScheduleRelationship” : “Skipped”.
    OJPTripDelivery sans temps réel : StopPointRef 132 comme arrêt normal
    OJPTripDelivery avec temps réel : StopPointRef 132 avec NotServicedStop=trueneues comportement :
    **************
    GTFS-S : le parcours de Rail 2000 n’est plus diffusé
    GTFS-R : le parcours de Rail 2000 n’est plus diffusé
    OJPTripDelivery avec et sans temps réel : le trajet Rail 2000 n’est plus envoyé (uniquement en tant que Location dans TripResponseContext)

 

2017-05-22: Nouvelles dates

  • Équipement. Les principales nouvelles fonctionnalités sont les suivantes:
    • GTFS-RT
    • Extensions dans GTFS Static (agency.txt)
    • ZVV Real-Time : la connexion du partenaire “ZVV” a permis de relier différentes entreprises de transport, dont PAG pour la région de Zurich. Toutes les lignes ne sont pas disponibles. Seuls ceux dont la qualité des données est suffisamment bonne. Vous trouverez un aperçu de toutes les agences de transport avec le temps réel ici : https://opentransportdata.swiss/fr/dataset/go-realtime
  • Extensions:
    • Plan de départ/d’arrivée : pour les trains dont le retard est indéterminé, le trajet est marqué comme non surveillé.
    • Fédération Opendata.swiss
  • Fixes:
    • Tableau des départs incomplet / informations sur les parcours
    • Informations incomplètes sur les extraits
  • Sujets et problèmes connus. Dans cette version, il y a ces problèmes connus au sein de la plateforme, qui devraient être résolus dans une version future:
    • Le tri des fichiers n’est parfois pas encore optimal. Nous vous recommandons d’utiliser le permalien.

 

2017-01-27: Nouveautés

  • Ces notes de mise à jour contiennent de précieuses informations sur les dernières fonctionnalités et améliorations de cette version de la plateforme de données ouvertes Swiss Public Transport. La nouvelle version est en ligne depuis 10 heures aujourd’hui:
    • Première version des informations sur les parcours
    • Service d’abonnement aux jeux de données
    • Autogestion des utilisateurs
    • Explorateur API: https://opentransportdata.swiss/explorer/
    • Améliorations:
      • Barre rouge sur la page d’accueil en cas de dysfonctionnement Améliorations de l’affichage mobile Diverses mises à jour du livre de cuisine Adaptations linguistiques Discourse également disponible dans le Cookbook
      • Didok Colonne de fichier country_code ajoutée Adaptations HRDF : le fichier UMSTEIGZ est livré deux fois:
      • Une fois sans numéro de circulation (comme auparavant)
      • Une fois avec le numéro de panneau de signalisation (nouveau fichier)
      • De plus amples informations sur le HRDF sont jointes et disponibles ici: https://opentransportdata.swiss/en/cookbook/hafas-rohdaten-format-hrdf/
    • Corrections:
      • L’axe X du tableau de bord du développeur affiche les données dans le bon ordre Problèmes UTF-8 résolus avec l’explorateur de données La “dernière mise à jour” des enregistrements est désormais conforme à la réalité
    • Sujets et problèmes connus. Dans cette version, il y a ces problèmes connus dans le produit, qui devraient être résolus dans une version future:
      • Les données en temps réel fournies par les interfaces VDV ne sont pas encore exprimées en secondes.
      • Le traitement des données de suivi est optimisé
      • Quelques optimisations de détail sont apportées aux données