search

etalab / transport-profil-netex-fr

Le contenu des normes des données de transport présentes sur le site https://normes.transport.data.gouv.fr.
https://normes.transport.data.gouv.fr
12 stars 9 forks source link

Structure des fichiers - Questions encore non résolues #120

Open TuThoThai opened 3 weeks ago

TuThoThai commented 3 weeks ago

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 ?

Autres

Originally posted by @albanpeignier in https://github.com/etalab/transport-profil-netex-fr/issues/56#issuecomment-1906033324

TuThoThai commented 3 weeks ago

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 ?

Autres

TuThoThai commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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.