Structure des fichiers - Questions encore non résolues

[TuThoThai]

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

Originally posted by @albanpeignier in #56 (comment)

[TuThoThai]

Commentaires de @prhod le 10 juin 2024 dans le ticket originel

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 ?

[TuThoThai]

Commentaire de @fxpicavet le 13 juin 2024 dans le ticket originel

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.

[TuThoThai]

Commentaire de @prhod le 14 juin 2024 dans le ticket originel

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 👍

[TuThoThai]

Commentaire de @albanpeignier le 18 septembre 2024 dans le ticket originel

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.

[prhod]

Nouvelle quesition à traiter :
Discussion autour de la notion de trie (entre les différents types d'objets et dans un type d'objets).
Cette discussion a été lancée lors de la proposition d'ajouter un rappel sur le fait qu'il n'y a pas d'ordre des balises dans les GeneralFrames
Est-il possible d'avoir :

ROUTE
LINE
ROUTE
=> Ajouter une contrainte ? une bonnes pratiques ?
=> au sujet des tries des objets de même type dans un fichier, retour sur le fait qu'il est difficile de se mettre d'accord sur un critère de tri.