Proposition d'organisation du fichier ZIP du profil NeTEx France

[albanpeignier]

Voici une proposition d'organisation d'un fichier ZIP regroupant les informations. Elle se base sur un atelier du GT7 sur le nommage des fichiers et la description des Frames existante dans le profil NeTEx France.

Règles de base

Quelques règles de base ont dirigé les réflexions autour de cette organisation:

Organisation par ligne

Entre un fichier unique et une organisation en plusieurs fichiers, l'axe qui semble fournir le découpage le plus utile pour l'utilisateur des fichiers est celui par ligne.

Pas de duplication de ressources NeTEx

L'objectif est définir une organisation qui interdit la duplication des données entre les fichiers XML contenu dans le même fichier ZIP.

Une ressource est identifiée par sa classe et son id(entifiant).

Éviter les sur-informations

De nombreuses informations pourraient être mises en oeuvre, notamment dans le nommage des fichiers. Les discussions au sein du GT7 ont privilégié l'utilisation uniquement des informations strictement nécessaires à la bonne organisation interne du fichier ZIP.

Données associées à une ligne

Entrée ZIP: LINE-<id>.xml

La valeur de <id> doit être unique dans le fichier.

<?xml version="1.0" encoding="utf-8"?>
<PublicationDelivery xmlns="http://www.netex.org.uk/netex" version="1.09:FR-NETEX-2.1-1.0">
  <PublicationTimestamp>2023-01-01T00:00:00.0Z</PublicationTimestamp>
  <ParticipantRef>Exemple</ParticipantRef>
  <dataObjects>
    <CompositeFrame id="FR:CompositeFrame:NETEX_LIGNE:LOC" version="any">
      <TypeOfFrameRef ref="FR:TypeOfFrame:NETEX_LIGNE:" />
      <Name>Ligne d'exemple</Name>
      <frames>
        <GeneralFrame id="FR:GeneralFrame:NETEX_LIGNE:LOC" version="1.09:FR-NETEX-2.1-1.0">
          <TypeOfFrameRef ref="FR:TypeOfFrame:NETEX_LIGNE:" />
          <members>
            <Line id="sample" version="any">
              <Name>Ligne d'exemple</Name>
            </Line>
            <!-- 
              Peut contenir
              LINE
              DIRECTION
              GROUP OF LINE
              NETWORK
              ROUTE
              ROUTE POINT
              POINT ON ROUTE
              ROUTE LINK
              GROUPE OF ENTITIES (sous ligne)
              FLEXIBLE LINE
              FLEXIBLE ROUTE
            -->
          </members>
        </GeneralFrame>
        <GeneralFrame id="FR:GeneralFrame:NETEX_HORAIRE:LOC" version="1.09:FR-NETEX-2.1-1.0">
          <TypeOfFrameRef ref="FR:TypeOfFrame:NETEX_HORAIRE:" />
          <members>
            <!-- 
              Peut contenir
              SERVICE JOURNEY
              FLEXIBLE SERVICE PROPERTIES
              TEMPLATE SERVICE JOURNEY
              HEADWAY JOURNEY GROUP
              RHYTHMICAL JOURNEY GROUP
              SERVICE JOURNEY INTERCHANGE
              VEHICLE TYPE
              COUPLED JOURNEY
              JOURNEY PART COUPLE
              JOURNEY PART
              TRAIN
              TRAIN COMPONENT
              COMPOUND TRAIN
              TRAIN NUMBER
              TRAIN COMPONENT LABEL ASSIGNMENT
              COUPLED JOURNEY
              JOURNEY PART COUPLE
              JOURNEY PART
              TRAIN
              TRAIN COMPONENT
              COMPOUND TRAIN
              TRAIN NUMBER
              TRAIN COMPONENT LABEL ASSIGNMENT
            -->
          </members>
        </GeneralFrame>
        <GeneralFrame id="FR:GeneralFrame:NETEX_RESEAU:LOC" version="1.09:FR-NETEX-2.1-1.0">
          <TypeOfFrameRef ref="FR:TypeOfFrame:NETEX_RESEAU:" />
          <members>
            <!-- 
              TARIFF ZONE
              DESTINATION DISPLAY
              FLEXIBLE POINT PROPERTIES
              FLEXIBLE LINK PROPERTIES
              SERVICE JOURNEY PATTERN
              POINT IN JOURNEY PATTERN
              SCHEDULED STOP POINT
              TIMING POINT
              CONNECTION
              DEFAULT CONNECTION
              SITE CONNECTION
              ROUTING CONSTRAINT ZONE
              TRANSFER RESTRICTION
              PASSENGER STOP ASSIGNMENT
              TRAIN STOP ASSIGNMENT
              SCHEMATIC MAP  
            -->
          </members>
        </GeneralFrame>
  </dataObjects>
</PublicationDelivery>

References

• https://normes.transport.data.gouv.fr/normes/netex/reseaux/#ent%c3%aates-netex

Données associées aux arrêts

Entrée ZIP: STOP.xml

<?xml version="1.0" encoding="utf-8"?>
<PublicationDelivery xmlns="http://www.netex.org.uk/netex" version="1.09:FR-NETEX-2.1-1.0">
  <PublicationTimestamp>2023-01-01T00:00:00.0Z</PublicationTimestamp>
  <ParticipantRef>Exemple</ParticipantRef>
  <dataObjects>
    <GeneralFrame id="FR:GeneralFrame:NETEX_ARRET:LOC" version="1.09:FR-NETEX-2.1-1.0">
      <TypeOfFrameRef ref="FR:TypeOfFrame:NETEX_ARRET:" />
      <members>
        <!--
          STOP PLACE
          QUAY
          TOPOGRAPHIC PLACE
          STOP PLACE ENTRANCE
          GENERAL GROUP OF ENTITIES
          -->
      </members>

    </GeneralFrame>
  </dataObjects>                  
</PublicationDelivery>    

References

• https://normes.transport.data.gouv.fr/normes/netex/arrets/#ent%c3%aates-netex

Données associées aux points d'intérêt

Entrée ZIP: POI.xml

<?xml version="1.0" encoding="utf-8"?>
<PublicationDelivery xmlns="http://www.netex.org.uk/netex" version="1.09:FR-NETEX-2.1-1.0">
  <PublicationTimestamp>2023-01-01T00:00:00.0Z</PublicationTimestamp>
  <ParticipantRef>Exemple</ParticipantRef>
  <dataObjects>
    <GeneralFrame id="FR:GeneralFrame:NETEX_COMMUN:LOC" version="1.09:FR-NETEX-2.1-1.0">
      <TypeOfFrameRef ref="FR:TypeOfFrame:NETEX_COMMUN:" />
      <members>
        <!--
          POINT OF INTEREST
          -->
      </members>
    </GeneralFrame>
  </dataObjects>
</PublicationDelivery>

References

Aucune :(

Données communes

Entrée ZIP: RESOURCE.xml

<?xml version="1.0" encoding="utf-8"?>
<PublicationDelivery xmlns="http://www.netex.org.uk/netex" version="1.09:FR-NETEX-2.1-1.0">
  <PublicationTimestamp>2023-01-01T00:00:00.0Z</PublicationTimestamp>
  <ParticipantRef>Exemple</ParticipantRef>
  <dataObjects>
    <CompositeFrame id="FR:CompositeFrame:NETEX_FRANCE:LOC" version="1.09:FR-NETEX-2.1-1.0">
      <TypeOfFrameRef ref="FR:TypeOfFrame:NETEX_FRANCE:" />
      <frames>
        <GeneralFrame id="FR:GeneralFrame:NETEX_COMMUN:LOC" version="1.09:FR-NETEX-2.1-1.0">
          <TypeOfFrameRef ref="FR:TypeOfFrame:NETEX_COMMUN:" />
          <members>
            <!--
              VALIDITY CONDITION (AVAILABILITY CONDITION et VALIDITY TRIGGER)
              ALTERNATIVE NAME
              NOTICE
              NOTICE ASSIGNMENT
              RESPONSIBILITY ROLE ASSIGNMENT
              ORGANISATION
              POINT PROJECTION
              ZONE PROJECTION
              TYPE OF FRAME
              TYPE OF VALUE spécifiques
              -->
          </members>
        </GeneralFrame>
        <GeneralFrame id="FR:GeneralFrame:NETEX_CALENDRIER:LOC" version="1.09:FR-NETEX-2.1-1.0">
          <TypeOfFrameRef ref="FR:TypeOfFrame:NETEX_CALENDRIER:" />
          <members>
            <!--
              DAY TYPE
              OPERATING DAY
              SERVICE CALENDAR
              DAY TYPE ASSIGNMENT
              -->
          </members>
        </GeneralFrame>
      </frames>
    </CompositeFrame>
  </dataObjects>
</PublicationDelivery>

References

• https://normes.transport.data.gouv.fr/normes/netex/elements_communs/#typeofframe-types-sp%C3%A9cifiques

Données associées à la tarification

Entrée ZIP: FARE.xml

Travail en cours

Données associées à l'accessibilité

Entrée ZIP: ACCESSIBILITY.xml

Travail en cours

Données associées aux parkings

Entrée ZIP: PARKING.xml

Travail en cours

[albanpeignier]

Questions encore non résolues

Unicité de l'id des Frames LIGNE

La règle d'unicité n'est pas respectée par les Frames NETEX_LIGNE. Chaque fichier de ligne contient la "même" Frame FR:GeneralFrame:NETEX_LIGNE:LOC.

L'idéal serait d'avoir des Frame ids uniques aussi. Par exemple: id="FR:GeneralFrame:NETEX_LIGNE-<qqchose>:LOC". Ca aiderait par exemple les outils de diagnostic pour désigner la Frame.

Où mettre ?

• les NETWORK ne peuvent être stockés dans le fichier de ligne sans être dupliqué
• les GROUP OF LINE ne peuvent être stockés dans le fichier de ligne sans être dupliqué
• TARIFF ZONE: -> dupliqué .. et pas propre à une ligne ? Pourquoi pas dans le fichier FARE ?
• SITE CONNECTION: Pourquoi pas dans les arrêts ?
• ROUTING CONSTRAINT ZONE: peuvent être partagées par plusieurs lignes…
• Où peut-on mettre les ServiceLinks (pour gérer des tracés associés aux Service Patterns) ?

Autres

• Pas de spécification pour la CompositeFrame de RESOURCE
• Pas de spécification pour la localisation des Points Of Interest
• Le name de la ligne sur la CompositeFrame NETEX_LIGNE, ce n'est pas très utile et très contraignant

[albanpeignier]

Cette proposition a servi de base pour organiser les fichiers NeTEx créés par conversion par transport.data.gouv.fr/. Donc les exemples sont nombreux.

[thbar]

Je partage ici ce que fait la Norvège (poke @gonzalezsuitt & @TuThoThai qui seront intéressés):

• https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728563782/General+information+NeTEx#%5BinlineExtension%5DExchanging-information

Petit extrait:

Information exchanged in the NeTEx format should be XML files containing only one root tag: PublicationDelivery
The information should be delivered with one XML file per Line, packed as ZIP-file with a flat structure (no subdirectories). It is technically possible to deliver each line separately, packed in separate ZIP-files if all the data objects used by each Line are defined within its PublicationDelivery. However, in order to avoid issues with overwriting and ensure good data update/deletion management, it is strongly recommended that only complete datasets containing all lines are exchanged. Data objects used by multiple Lines can be defined in a separate "common" XML-file (must be prefixed with an underscore, e.g. "_common.xml") to avoid redundancy of unique objects.

Cette structuration est d'ailleurs attendue par le validateur NeTEx norvégien disponible ici https://github.com/entur/netex-validator-java#netex-validator-java:

Qui dit structuration commune, dit validation homogène plus facile etc etc.

It expects the dataset to follow the packaging and naming conventions stated in the Nordic NeTEx profile (dataset packaged as a zip file, one NeTEx Line per XML file, shared file prefixed with '_', ...)

Il est intéressant de voir que la Norvège a choisi d'intégrer ces règles pratiques directement dans son profil !

À discuter 😄

[TuThoThai]

Ce que je trouve le plus intéressant dans cette discussion (merci @albanpeignier) est aussi la possiblité de se rapprocher de l'outil de validation développé par Entur. Sans parler de la "simplification" perçue par les producteurs de données

[prhod]

Relance du sujet

De mon côté, je constate également le fait que le manque de structure explicite des exports est un frein à l'adoption de la mise en place du Netex. Il me semble primordial de spécifier et documenter cette partie

Nouvelle spec Vs profil Nordic

J'avoue que j'ai été pas mal séduit par l'idée de reprendre les spécifications du profil Nordic pour tous les avantages listés plus haut.
En essayant de lire la doc, j'ai trouvé que ce n'était pas si simple. La notion de réseau est dans le même fichier que la ligne si le réseau n'est pas partagé (exemple sur github), mais peut être mis dans le fichier "_common.xml" s'il est partagé par plusieurs lignes.

J'avoue avoir une préférence pour la proposition initiale d' @albanpeignier (discuté avec lui le 07/06). Quelques remarques sur la proposition initiale :

• je ne suis pas fan des fichiers avec un nom au singulier alors qu'il y a plusieurs objets dedans
• Extraire les réseaux, opérateurs et groupes de lignes dans un fichier à part (ça permet comme pour le STOP.xml d'avoir une entrée plus facile pour grouper des objets communs par définition et faciliter la compréhention du Netex)
• Il semble que certaines restrictions de FRAME ne soient pas adaptées :
  • NETEX_LIGNE a des restrictions listées (sur cette page)[https://normes.transport.data.gouv.fr/normes/netex/elements_communs/#typeofframe-types-sp%C3%A9cifiques]
  • NETEX_N_LIGNES est-il utilisé ? Je pense qu'il ajoute une complexité potentiellement inutile

Sur les points listés comme "encore non résolues"

Unicité de l'id des Frames LIGNE

L'objectif de pouvoir cibler une Frame avec un ID unique semble interessante, donc je suis d'accord avec l'idée de mettre un ID unique sur les Frame. Mais j'ai un doute sur la proposition. A creuser.

Ou mettre ?

• Pour le Network, le mettre dans un fichier spécifique NETWORK.xml par exemple
• TARIFF ZONE: le mettre soit dans FARE soit dans NETWORK
• SITE CONNECTION: comme d'autres objets dans la Frame NETEX_ RESEAU, le lien entre des arrêts, des POIs ou d'autres notions semble étonnant. Si on mets les arrets dans ARRET et les POIs dans POI, autant mettre cette notion dans RESSOURCES (même si on ne change pas les contraintes des Frame)
• ROUTING CONSTRAINT ZONE: si c'est partagé, autant les mettre dans les RESSOURCE.xml
• autres questions de placement : je propose que si on ne sait pas, on met tout dans RESSOURCE.xml

Autres

• Pas de specs pour la CompositeFrame de RESOURCE => je n'ai pas vérifier s'il y a besoin de préciser/modifier les specs actuelles, mais avoir une précision (document complémentaire + XSD ?) me semble important.
• Le name sur la CompositeFrame, c'est pas très utile et très contraignant : je n'ai pas creusé ce point
• Pas de specs pour la localisation des Points Of Interest : il me semble que j'en ai trouvé une : ça hérite de SITE, qui est une extention de AddressablePlace_VersionStructure qui est une extention de Place_VersionStructure qui étend Zone_VersionStructure avec PlaceGroup qui contient un Centroid

  => on pourrait se faire un XSD simplifié d'un profil France ?

A dispo pour faire avancer le sujet !

[albanpeignier]

Suite aux différentes discussions, j'ai modifié la proposition de la structure du fichier avec les changements qui paraissaient évidents :

• la GeneralFrame HORAIRE oubliée est maintenant bien décrite 🤦
• la CompositeFrame des fichiers LINE a maintenant un id et un TypeOfFrame, tel que décrit (cf Elements Communs - TypeOfFrame : types spécifiques):

Le champ Name des CompositeFrame de type NETEX_LIGNE contient le nom de la ligne.

[TuThoThai]

Je viens rajouter qu'à la suite d'un webinaire dédié à l'accessibilité, la région Auvergne Rhône Alpes souhaite participer aux discussions pour bien structurer leurs fichiers NeTEx.

[thbar]

Grain à moudre que je peux apporter: dans le cadre d'autres travaux (indexation des fichiers, dont NeTEx, dans notre moteur de recherche v2 sur transport.data.gouv.fr, jusqu'au niveau arrêts) et suite à etalab/transport-site#3757, j'ai été amené à télécharger et dézipper la totalité des fichiers NeTEx actuellement répertoriés.

Je partagerai leur "layout physique" (noms des fichiers) ainsi que des bizarreries détectées (il existe des zips contenant des zips) qu'il faudra à mon avis interdire explicitement (même travail plus ou moins que ce que j'ai fait ici sur le GTFS google/transit#379), pour simplifier la vie des réutilisateurs.

[fxpicavet]

Je trouve le découpage par ligne intéressant car au moins on a l’ensemble des concepts associés a celle-ci, plus de problème d’elements isolés. Par contre, il sera tres compliqué d'avoir l'unicité d'objets par fichier... car il y en aura toujours en double dans certain fichier (course couplée, ...)

Cependant, avec ce mode de modélisation :
• il est nécessaire de connaitre en amont l’ensemble des id de lignes pour télécharger le bon fichier.
• On a aussi des consommateurs qui se limitent au réseau de la ligne (route, pattern, …) et télécharger aussi l’offre a chaque fois ca va râler. (donc contenu de Netex_Horaire facultatif ?)

Remarques sur le contenu du fichier ligne :
• Pourquoi le référentiel des véhicules (TRAIN, VEHICLE TYPE, …) serait dans le fichier ligne sachant qu’un véhicule peut etre utilisé sur plusieurs lignes, pour moi ça devrait etre un fichier à part.
• Dans Netex-ligne, manque pour moi PRESENTATION, TRANSPORTMODE, TYPEOFLINE, ….
• Tout ce qui est connection (SiteConnection) ce n’est pas pour une ligne pour moi, ca aurait plus de sens dans arret.
• Apres pour ce qui est du scheduledstoppoint, on a des réseaux ou le meme scheduledstoppoint est utilisé pour plusieurs lignes. (dupliqué dans les différents fichiers?)
• L’accessilibté de la ligne serait mise ailleurs ?

Concernant les arrêts, tout ce qui est accessibilité des quais sera mis ailleurs ?

Où placer les données d’organisation (operateur, network, organisationunit, ….) car c’est des notions importantes pour une ligne par ex.

Je vois aussi un type de données qui nous ait demandé souvent et pas enumérée ici, c’est le référentiel des équipements. (nous on fait souvent des SIV, et on a besoin de ca). Ca serait dans accessibilité?

Attention aussi a la taille des fichiers generés, ca rebute souvent du monde de parser des fichiers de taille trop importante. ca necessite des ressource trop importante. (ok il existe des parseur type Sax), mais ce n'est pas ceux utilisés le plus souvent pas nos différents consommateurs.

[nlehuby]

Il y a quelques éléments utilisés pour la description de l'accessibilité qui n'ont pas encore été repris ici. Voici quelques propositions :

pour le fichier STOP.xml

• ajouter ENTRANCE (usage similaire à STOP PLACE ENTRANCE)

pour le fichier POI.xml

• ajouter POINT OF INTEREST ENTRANCE et POINT OF INTEREST CLASSIFICATION

pour le fichier ACCESSIBILITY.xml

• SITE PATH LINK
• tous les équipements : à la fois les équipements d'accès (CROSSING EQUIPMENT, ESCALATOR EQUIPMENT, etc) et les équipements de lieu (SANITARY EQUIPMENT, TICKETING EQUIPMENT, etc)
• PATH JUNCTION

pour le fichier RESOURCE.xml ?

• ajouter DATA SOURCE

[prhod]

Petite remarque sur le message de @fxpicavet

Cependant, avec ce mode de modélisation :
• il est nécessaire de connaitre en amont l’ensemble des id de lignes pour télécharger le bon fichier.
• On a aussi des consommateurs qui se limitent au réseau de la ligne (route, pattern, …) et télécharger aussi l’offre a chaque fois ca va râler. (donc contenu de Netex_Horaire facultatif ?)

Pour le premier point, si un utilisateur n'est intéressé que par une seule ligne, oui il doit connaitre son ID ou tout parser. Il en va de même pour un utilisateur qui ne serait intéressé que par les lignes de Tram. C'est le même problème que pour un GTFS.
Il y aura toujours des cas d'usages d'utilisateurs à qui le format ne conviendra pas. A mon avis, l'enjeu est définir un export qui permette aux réseaux / AOM de fournir leurs données de manière univoque et simple et qui permette une réutilisation "standard".
#MyTwoCents

Et pour les propositions d'ajouts de notions des 2 messages, je regarde asap 👍

[thbar]

Question transverse qui pointe de partout à la fois, c'est le traitement de la donnée d'accessibilité, effectivement.

Re @TuThoThai

Je viens rajouter qu'à la suite d'un webinaire dédié à l'accessibilité, la région Auvergne Rhône Alpes souhaite participer aux discussions pour bien structurer leurs fichiers NeTEx.

Et @nlehuby

#56 (comment)

La question qui revient c'est: si j'utilise AccèslibreMobilités, qu'est-ce qui est produit en sortie, à quel point il faut le retravailler pour avoir une donnée qui pourra suivre les recommendations qu'on va faire ici, à quel point c'est redondant ou pas avec un fichier d'arrêts etc.

[nlehuby]

#56 (comment)

La question qui revient c'est: si j'utilise AccèslibreMobilités, qu'est-ce qui est produit en sortie, à quel point il faut le retravailler pour avoir une donnée qui pourra suivre les recommendations qu'on va faire ici, à quel point c'est redondant ou pas avec un fichier d'arrêts etc.

Aujourd'hui, AccèsLibre Mobilités produit un unique fichier xml, contenant un GeneralFrame NETEX_ACCESSIBILITE avec tous les objets manipulés.
Bien qu'il n'ait pas été vraiment généré avec AccèsLibre Mobilités, le fichier des cheminements de Paris publié sur le PAN est assez représentatif de ce qui est produit.

Il y plusieurs types d'objets qui ne sont pas gérés dans la proposition actuelle (cf mon dernier message), mais à part ça je ne vois pas d'impossibilité technique, il s'agira principalement pour nous de répartir les objets dans plusieurs fichiers (STOP.xml, PARKING.xml, POI.xml, ACCESSIBILITY.xml et RESOURCE.xml) au lieu d'un. Nous pourrons l'implémenter quand ça sera validé.

[albanpeignier]

Autre information qui ne trouve pas de place dans les frames telles que définies actuellement. Nous travaillons sur une meilleure gestion des ServiceFacilitySets notamment en essayant d'optimiser les exports de courses avec des services à bord.

Pour ce faire, il faut pouvoir définir les ServiceFacilitySets et les référencer dans les courses.

<ServiceJourney>
  <!-- ... -->
  <facilities>
    <ServiceFacilitySetRef version="any" ref="bbd:svcfc_general"/>
    <ServiceFacilitySetRef version="any" ref="bbd:svcfc_first"/>
  </facilities>
</ServiceJourney>

<ServiceFacilitySet id="bbd:svcfc_general">
  <!-- ... -->
</ServiceFacilitySet>

C'est normalement possible dans les TimetableFrames (quand elles sont utilisées). Il faudrait qu'une frame accepte (gentillement) dans le profil France ce type de resources, dans RESOURCE.xml ou ACCESSIBILITY.xml par exemple.

[ptitfred]

Vous trouverez dans cette feuille de calcul partagée un extrait des fichiers présents dans les ressources NeTEx publiées sur le PAN.

Le tableau contient les colonnes suivantes :

• resource : l'url de la ressource sur le PAN
• title : son titre tel que choisit par l'AOM lors de la publication sur data.gouv.fr
• url : la source de l'archive NeTEx (généralement hébergée par le partenaire)
• file : le chemin d'un fichier présent dans l'archive, répété pour tous les fichiers d'une même ressource
• hierarchy : à quelle profondeur dans l'archive ce fichier est présent : 1 pour la racine, 2 pour dans un dossier, et ainsi de suite selon l'imbrication

Extrait fait depuis les données présentes dans la nuit du 15 au 16 octobre 2024.

[TuThoThai]

Ticket clos en faveur de #121