Open albanpeignier opened 5 months ago
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.
NETWORK
ne peuvent être stockés dans le fichier de ligne sans être dupliqué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…ServiceLinks
(pour gérer des tracés associés aux Service Patterns) ?CompositeFrame
de RESOURCE
CompositeFrame
NETEX_LIGNE
, ce n'est pas très utile et très contraignantCette proposition a servi de base pour organiser les fichiers NeTEx créés par conversion par transport.data.gouv.fr/. Donc les exemples sont nombreux.
Je partage ici ce que fait la Norvège (poke @gonzalezsuitt & @TuThoThai qui seront intéressés):
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 :smile:
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
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
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 :
STOP.xml
d'avoir une entrée plus facile pour grouper des objets communs par définition et faciliter la compréhention du Netex)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 inutileL'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.
NETWORK.xml
par exempleAddressablePlace_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 !
Suite aux différentes discussions, j'ai modifié la proposition de la structure du fichier avec les changements qui paraissaient évidents :
GeneralFrame
HORAIRE oubliée est maintenant bien décrite 🤦 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.
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.
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 à https://github.com/etalab/transport-site/issues/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 https://github.com/google/transit/pull/379), pour simplifier la vie des réutilisateurs.
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.
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
pour le fichier POI.xml
pour le fichier ACCESSIBILITY.xml
pour le fichier RESOURCE.xml ?
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".
Et pour les propositions d'ajouts de notions des 2 messages, je regarde asap 👍
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
https://github.com/etalab/transport-profil-netex-fr/issues/56#issuecomment-2165977784
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.
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é.
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.References
Données associées aux arrêts
Entrée ZIP:
STOP.xml
References
Données associées aux points d'intérêt
Entrée ZIP:
POI.xml
References
Aucune :(
Données communes
Entrée ZIP:
RESOURCE.xml
References
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