Question concernant le profil SIRI, pour GetEstimatedTimetable. Quelle est la requête appropriée pour filtrer selon une seule ligne ? Faut-il avoir Lines > LineDirection > LineRef ou uniquement Lines > LineRef ?

Sur le site actuellement, il me semble qu'on indique uniquement Lines > LineRef.

Côté EnRoute cc @albanpeignier, la requête fait apparaitre ceci.

<sw:GetEstimatedTimetable xmlns:sw="http://wsdl.siri.org.uk" xmlns:siri="http://www.siri.org.uk/siri">
    <ServiceRequestInfo>
        <siri:RequestTimestamp>{{current_time}}</siri:RequestTimestamp>
        <siri:RequestorRef>{{partner_token}}</siri:RequestorRef>
        <siri:MessageIdentifier>Test:Message::{{$randomUUID}}:LOC</siri:MessageIdentifier>
    </ServiceRequestInfo>
    <Request version="2.0:FR-IDF-2.4">
        <siri:RequestTimestamp>{{current_time}}</siri:RequestTimestamp>
        <siri:MessageIdentifier>Test:Message::{{$randomUUID}}:LOC</siri:MessageIdentifier>
        <siri:Lines>
          <siri:LineRef>{{line_identifier}}</siri:LineRef>
      </siri:Lines>
  </Request>
  <RequestExtension />
</sw:GetEstimatedTimetable>

Côté CEN 🇪🇺, il y a un wrap LineDirection qui est présent.

cc @Aurige

Le profil SIRI France devrait mettre en avant quelques exemples de l'utilisation des situtations versus publishingAction afin d'éviter les multiples interprétations possibles.

1/Pour la définition des messages textuels liés à l'évenement, dans le profil il est mis que l'on peut utiliser les elements "description" et "summary". En paralèlle, on a les publishingAction qui sont destinés à cela.
Quels sont les bonnes pratiques?

2/Pour des événements (SX) ou il est nécessaire de définir des situtations temporalités différentes. (Définir les action post événement, événement, retour à la normale).
Décrire quelles sont les bonnes pratiques à appliquer. une situtation par état, via les publishing action, ....

3/Expliquer comment une publishingAction peut faire référence à une consequence d'une situtation.

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 version="any">
      <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_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

En réunion ce jour ont été actés les points suivants:

• le profil SIRI va être gelé dans son état actuel docx
• nous travaillerons sur une regénération (manuelle / automatique comme on peut) du markdown à partir de cette version gelée
• pendant ces travaux, le document docx ne bougera pas, les commentaires et remarques seront centralisés sur le rédacteur "maître" actuel du profil
• j'essayerai d'itérer graduellement en privé jusqu'à avoir une version suffisamment bonne du document pour un passage en ligne
• le docx sera archivé ici pour mémoire
• les commentaires / remarques seront remontées ici sous forme d'issues dans un premier temps
• nous travaillerons avec le rédacteur du profil pour voir comment créer des pull-requests (sans outil tiers)
• une fois que le workflow sera bien rodé, on pourra envisager de tester des outils comme gitbook éventuellement pour simplifier les contributions, mais uniquement si cela n'apporte pas plus de problèmes techniques que de bénéfices

@Aurige Je propose que nous nous servions de cette issue pour discuter des possibilités que nous trouvons pour collaborer sur les documents de normes.

Ce qui est actuellement possible :

• copier un lien depuis l'article en faisant apparaître l'ancre
  
  Puis ouvrir une issue et expliquer ce qui ne va pas.

ou bien

• cliquer en haut de l'article sur "proposer une modification"
  
  Ce qui ouvre le contenu de la page.
  Puis cliquer sur "display the source blob"
  
  trouver l'endroit qui nous intéresse avec une recherche textuelle, puis cliquer sur le numéro de la ligne, puis reference in new issue
  
  ce qui va créer une issue avec un lien vers la passage en question.

ou bien

• ... à venir :)

Bonjour,

Nous travaillons sur plusieurs cas de données client qui contiennent des quais multimodaux : pour un même quai, avec la même géolocalisation, 2 modes de transport passent.

Est-ce autorisé dans la norme NeTex version France ?
et version générale européenne ?
Si oui, comment peut on mettre cela en place ?

Merci

Profil d’échange pour la description des horaires de transport en commun | Normes de TC

NeTEx - Profil Français pour les horaires
Avant-propos L’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :
pour l’usager, aux fins d’une présentation homogène et compréhensible de l’offre de transport et de l’engagement sous-jacent des organisateurs (autorités organisatrices et opérateurs de transports) ;
pour les AOT, de manière à fédérer des informations homogènes venant de chacun des opérateurs de transports qui travaillent pour elle.

https://elegant-carson-e21034.netlify.app/posts/netex/

Le profil SIRI France met en avant l'attribut ScopeType dans les Situations:

Mais le profil ne décrit pas son rôle. Il n'est pas non plus précisé si une cohérence est attendue ou non par rapport à la structure Affects qui associe précisément la Situation à des lignes, arrêts, etc.

Cet attribut n'est pas exemple pas présence dans d'autres profils comme le profil Nordique (https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370605/SIRI-SX#SIRI-SX-PtSituationElement).

Qu'elle est la différence ou l'utilité de ces 2 champs dans une réponse GeneralMessage ? Ils semblent très similaires.

Côté CEN 🇪🇺 je ne vois pas d'attribut ItemIdentifier.

Le profil SIRI France met en avant l'attribut PtSituationElement/Publication:

Statut de publication. L'un d'un ensemble spécifié de sous-états auxquels une SITUATION peut être attribuée.

<siri:PtSituationElement>
  <siri:Progress>open</siri:Progress>
  <siri:Publication>meuh</siri:Publication>
  <siri:ValidityPeriod><!-- ... --></siri:ValidityPeriod>
</siri:PtSituationElement>

Mais cet attribut n'a pas de définition très précise dans la norme ou la XSD:

<xsd:simpleType name="PublicationStatusType">
  <xsd:annotation>
    <xsd:documentation>Type for Publication status.</xsd:documentation>
  </xsd:annotation>
<xsd:restriction base="xsd:NMTOKEN"/>
</xsd:simpleType>

Le profil parking NeTEx m'a été communiqué par @Aurige. C'est un profil validé par la CN03.

Si j'ai compris (à confirmer) il va être à intégrer directement ici, comme sous-partie du profil NeTEx France.

C'est un document Word qu'il faudra retranscrire.

Je crée le ticket, et un de mes collègues va se lancer dessus (poke @vdegove), je lui transmettrai le mode opératoire utilisé pour la dernière retranscription.

@Aurige question complémentaire : combien de documents reste-t-il à intégrer, hormis celui-ci ? Je cherche à évaluer la charge de notre côté en termes de retranscription, et aussi à faire figurer ça sur le projet GitHub.

EDIT @thbar: le lien vers le doc est ici sauf erreur:

• https://github.com/etalab/transport-normes/files/14095152/NF_Profil.NeTEx.pour.les.Parkings.F.-.v1.2a.docx

Le profil accessibilité mentionne l'élément CycleParkingEquipment (parcs à vélos) : https://normes.transport.data.gouv.fr/posts/netex/accessibilit%C3%A9/#parking-equipment

Je n'ai pas réussi à trouver sa définition dans le XSD de Netex.

À noter qu'il existe en revanche un CycleStorageEquipment, qui semble avoir la même définition (Specialisation of PLACE EQUIPMENT for cycle storage.)

Pour éviter toute ambiguïté, le profil SIRI France devrait préciser que la structure Affects dans le PtSituationElement est obligatoire.

Exemple

<siri:PtSituationElement>
  <!-- ... -->

  <siri:Summary>...</siri:Summary>
  <siri:Description>...</siri:Description>

  <siri:Affects>
    <siri:Networks>
      <siri:AffectedNetwork>
        <siri:AffectedLine>
          <siri:LineRef>00673</siri:LineRef>
          <siri:PublishedLineName xml:lang="fr">103</siri:PublishedLineName>
        </siri:AffectedLine>
      </siri:AffectedNetwork>
    </siri:Networks>
  </siri:Affects>
</siri:PtSituationElement>

Il serait pratique d'avoir un site de preview lorsqu'on fait une PR sur le contenu d'un document.
C'est d'habitude fait automatiquement par Netlify, mais ici on a séparé le contenu du code permettant de générer le site statique, donc la fonctionnalité n'est pas présente pour une PR sur le contenu.

J'ai posé la question sur un forum Netlify https://answers.netlify.com/t/directory-chaining-and-repository-dependencies-for-pr-previews/19690, sans réponse pour le moment.

J'imagine qu'on peut faire le truc à la main, en se servant des github actions et de l'api Netlify, mais j'ai peur que ce soit un peu compliqué à mettre en place.

Sujet à creuser.

Le profil SIRI France devrait prendre en compte le besoin d'associer une structure Affects à chaque Consequence:

Chaque Consequence au sein d'une PtSituationElement peut avoir une structure Affects pour préciser l'impact sur le réseau de cette conséquence.

Exemple

<siri:PtSituationElement>
  <!-- ... -->

  <siri:Summary xml:lang="fr">...</siri:Summary>
  <siri:Description xml:lang="fr">...</siri:Description>

  <siri:Affects>
    <siri:StopPoints>
      <siri:AffectedStopPoint>
        <siri:StopPointRef>Quay1</siri:StopPointRef>
      </siri:AffectedStopPoint>
    </siri:AffectedStopPoint>
  </siri:Affects>

  <siri:Consequences>
    <siri:Consequence>
      <!-- .. -->
      <siri:Affects>
        <siri:Networks>
          <siri:AffectedNetwork>
            <siri:AffectedLine>
              <siri:LineRef>LineA</siri:LineRef>
            </siri:AffectedLine>
          </siri:AffectedNetwork>
        </siri:Networks>
      </siri:Affects>
    </siri:Consequence>

    <siri:Consequence>
      <!-- .. -->
      <siri:Affects>
        <siri:Networks>
          <siri:AffectedNetwork>
            <siri:AffectedLine>
              <siri:LineRef>LineB</siri:LineRef>
            </siri:AffectedLine>
          </siri:AffectedNetwork>
        </siri:Networks>
      </siri:Affects>
    </siri:Consequence>
  </siri:Consequences>
</siri:PtSituationElement>

Le document NeTEx - Profil France - Éléments communs fait cette assertion dans la définition du Point:

| Location | 1:1 | Localisation du POINT (obligatoire dans le profil) |

Dans certaines utilisations, notamment quand la structure POINT est utilisée en tant que telle, la présence de l'attribute Location semble tout à fait requise.

En revanche, comme l'élément POINT est le parent de très nombreuses structures NeTEx, la présence obligatoire de l'attribut Location semble contre-productif dans certaines de ces situations.

Par exemple pour les définitions des ScheduledStopPoints, l'obligation d'une Location créé/créerait une duplication d'information. Cette valeur ne serait la plupart du temps d'une copie du Quay/StopPlace lié:

<ScheduledStopPoint id="A" version="any"/>

<PassengerStopAssignment id="..." version="any" order="0">
   <ScheduledStopPointRef ref="A" version="any"/>
   <QuayRef ref="sample"/>
</PassengerStopAssignment>

<Quay id="sample" version="any">
  <Name>Example de Zone d'embarquement</Name>
  <Centroid version="any">
    <Location>
      <Longitude>-116.784582</Longitude>
      <Latitude>36.868446</Latitude>
    </Location>
  </Centroid>
</Quay>

Cette nuance est présente dans le profil Nordic par exemple (Nordic NeTEx Profile - framework - Point):

Location is mandatory unless it is implicit based on the projection of the Point, or the subordinate objects have explicit references to geographic points/areas

Proposition

L'obligation sur l'attribut Location pourrait être plus nuancée dans NeTEx - Profil France - Éléments communs:

| Location | 0:1 | Localisation du POINT. Obligatoire sauf si les structures héritées ont des références explicites à des points/zones géographiques |

Bonjour,
Un producteur nous envoie un Netex dont la version simplifiée est ci-dessous :

   <ServiceJourney id="FR:ServiceJourney::SJ1" version="any" status="active">
	     <JourneyPatternRef ref="FR:ServiceJourneyPattern::JP:" />
             <LineRef ref="FR:Line::A:" version="any" />             
   </ServiceJourney>
    
   <ServiceJourneyPattern id="FR:ServiceJourneyPattern::JP:" version="any" >
             <RouteRef ref="FR:Route::R1:" />
   </ServiceJourneyPattern>
            
   <Route id="FR:Route::R1:" version="any">
           <LineRef ref="FR:Line::B:" />
   </Route>

Le ServiceJouney SJ1 est rattaché à la ligne FR:Line:A via la balise LineRef.

Mais si l'on remonte la hiérarchie par son journey pattern (FR:ServiceJourneyPattern::JP:) qui est rattaché à la route FR:Route::R1:, on peut voir que cette route appartient à la ligne FR:Line::B:

Nous considérons que ce fichier n'est pas correct. Car la balise LineRef du ServiceJourney doit correspondre à la ligne définie dans la route. Mais notre producteur pense que c'est correct.

Pouvez-vous nous confirmer que ce fichier est erroné , et que si la route appartient à la ligne FR:Line::B: alors la balise LineRef du ServiceJourney doit être FR:Line::B: svp?

Merci pour votre aide.

La ressource NeTEx SiteComponent (par héritage Quay) est définie avec l'attribut SiteRef obligatoire:

Pourtant lorsqu'un Quay est défini directement dans le StopPlace parent, l'attribut SiteRef n'est pas nécessaire (voire interdit):

<StopPlace id="parent">  
  <!-- -->
  <quays>
    <Quay id="child1">
      <!-- -->
    </Quay>
    <Quay id="child2">
      <!-- -->
    </Quay>
  </quays>
</StopPlace>

Le profil NeTEx France pourrait utiliser une phrase plus conditionnelle:

Pour une ZONE D'EMBARQUEMENT, il s'agit de l'identifiant du LIEU D'ARRÊT MONOMODAL dont dépend la ZONE D'EMBARQUEMENT.
Pour un ACCÈS il s'agit de l'identifiant du LIEU D'ARRÊT MONOMODAL, POLE MONOMODAL ou LIEU D'ARRÊT MULTIMODAL auquel mène l'ACCÈS.
Cet attribut est obligatoire dans le cadre du profil quand la ressource n'est pas définie directement au sein de la ressource parente.

Les structures "Reasons" (UnknownReason, MiscellaneousReason, PersonnelReason, EquipmentReason, EnvironmentReason, etc) sont obsolètes selon la XSD SIRI: https://github.com/SIRI-CEN/SIRI/blob/ce377ce9a860ac5758a99a159e78716ad74982aa/xsd/siri_model/siri_situationReasons.xsd#L65

(since SIRI 2.1) Replaced separate ReasonEnumerations by AlertCauseEnumeration (TPEG2).

Le profil SIRI France devrait mettre en avant l'utilisation de l'attribut AlertCause: https://github.com/SIRI-CEN/SIRI/blob/ce377ce9a860ac5758a99a159e78716ad74982aa/xsd/siri_model/siri_situationReasons.xsd#L159

Exemple

<siri:PtSituationElement>
  <!-- ... -->
  <siri:AlertCause>awaitingOncomingVehicle</siri:AlertCause>

  <siri:Summary xml:lang="fr">Arrêt La Poitevine non desservi</siri:Summary>
  <siri:Description xml:lang="fr">L'arrêt La Poitevine n'est pas desservi en direction de Paul Fort.</siri:Description>            
  <!-- ... -->
</siri:PtSituationElement>

          Le voila [NF_Profil NeTEx pour les Tarifs(F) - v1.3.docx](https://github.com/etalab/transport-normes/files/14087618/NF_Profil.NeTEx.pour.les.Tarifs.F.-.v1.3.docx)

Originally posted by @Aurige in #62 (comment)

Edit @thbar - je remets le lien communiqué par @Aurige directement dans l'issue ici:

• https://github.com/etalab/transport-normes/files/14087618/NF_Profil.NeTEx.pour.les.Tarifs.F.-.v1.3.docx

Le profil SIRI France laisse entendre que des contenus HTML (et d'autres formats non texte brutes) est possible dans les attributs des Situations (dans un exemple de message dans le paragraphe "Cas de la compatibilité avec le service General Message du profil SIRI ‘Ile de France’": https://normes.transport.data.gouv.fr/normes/siri/profil-france/#situation-exchange).

Plusieurs questions se posent autour de ce besoin avéré mais comportant des risques:

Support ou non ?

Le profil SIRI France doit clairement définir si le support de contenus HTML est possible. Et si c'est le cas, spécifier le moyen technique, les contraintes autour de cet usage, etc.

En l'état, les interprétations sont multiples.

Besoin(s) réel(s)

Le besoin est réel, notamment dans les échanges entre gestionnaires de Situations et les interfaces d'affichage pour les voyageurs. Ce besoin est d'ailleurs plus identifié au niveau des PublishingActions que dans les attributs de la PtSituationElement (Summary, etc).

Ce besoin est peut-être différent quand le type d'acteurs change. En Open Data par exemple, ni les Producteurs ni les Consommateurs ne s'attendent à des échanges de contenu HTML très fins et complexes (incluant par exemple des images, des couleurs, du javascript, etc, etc).

Prise en compte des problématiques de sécurité

L'intégration de contenu HTML dans une API nécessite de nombreuses précautions.

Le profil SIRI France régissant notamment les échanges en Open Data, il doit prendre en compte ces contraintes de sécurité pour permettre à tous de fournir dans de bonnes conditions de sécurité l'information temps-réel.

Sans consigne claire, chaque consommateur de la donnée SIRI risque de devoir tronquer/transformer les potentiels contenus HTML pour se protéger. Ce qui annulerait dans les faits le réel support de contenu HTML.

Evolution SIRI ?

Tout comme la langue est prise en compte comme une variante utile des attributs textuels, le type de contenu pourrait être une déclinaison possible des attributs:

<siri:Prompt xml:lang="EN">S74 and S78 buses detoured</siri:Prompt>
<siri:Prompt xml:lang="FR">Les bus S74 et S78 buses sont dévies</siri:Prompt>

<siri:Prompt xml:lang="EN" content-type="text/html">CDATA[<b>S74</b> and <b>S78</b> buses detoured due to the Water Main Reconstruction]</siri:Prompt>
<siri:Prompt xml:lang="FR" content-type="text/html">..</siri:Prompt>

En l'état se trouvent au 1er niveau des dossiers correspondant à différents profils NeTEx France et un dossier SIRI qui contiendra le profil SIRI France. Il faudrait faire apparaitre à mon avis un Niveau "Profils NeTEx France" contenant tous les profils NeTEx FR déjà présents et au même Niveau un Dossier Profil SIRI France

Le profil SIRI France pourrait recommander l'utilisation de l'attribut ReportType notamment pour permettre de différencier les Situations qui relèvent des perturbations pour le voyageur (ReportType incident) des Situations qui relèvent de l'information pour le voyageur (ReportType general).

C'est notamment le cas dans le profil Nordic: https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370605/SIRI-SX#SIRI-SX-PtSituationElement ou l'attribut est même obligatoire:

<!-- 
Type of situation report. The field is required in order to differentiate general information from incidents.

Possible values:
  - general (used for public information not impacting the actual operation of the PT-service. eg. "No food service on this journey")
  - incident (used for public information impacting the operation of the PT-service. eg. "expect delays due to road construction work") 
-->
<siri:ReportType>incident</siri:ReportType>

Les resources NeTEx Route héritent de LinkSequence:

Le LinkSequence définit Distance comme obligatoire:

Donc l'attribut Route/Distance peut être vu comme obligatoire.

Le profil SIRI France devrait préciser l'interprétation que doit faire un serveur SIRI des attributs de SituationNetworkFilterGroup.

Par exemple, si une requête ou un abonnement SIRI Situation Exchange définit un filtre les Situations selon une ligne donnée, le serveur SIRI interrogé devrait fournir également les Situations non explicitement associées à cette ligne mais aux arrêts desservis par cette ligne.

Sans cette approche, les consommateurs de données doivent requêter/s'abonner à tous les arrêts de la ligne .. et donc en pratique n'utilisent pas de filtre SIRI mais filtrent la donnée une fois reçue. Au final, les attributs de SituationNetworkFilterGroup ne sont pas utilisés.

Avec une approche plus intelligente/moins stricte, les attributs de SituationNetworkFilterGroup sont utiles, mais leur interprétation doit être précisée.

Bonjour,

Je souhaite modéliser au mieux les alertes reçues dans un flux GTFS-RT dans le flux SIRI SX.

En entrée, j'ai :
"informed_entity": [
{
"route_id": "13",
"stop_id": "quai11"
},
{
"route_id": "13",
"stop_id": "quai12"
}
]
Pour la route 13, 2 quais sont impactés, quai11 et quai12. Cependant, dans la norme SIRI, je n'ai pas l'impression que l'on puisse associer des quais à des lignes impactées, ou alors des lignes à des stop point affectés.
Comment modéliser au mieux le "ET" logique ?
Faut-il partir du principe que c'est un "ET" logique entre tous les éléments affectés et donc créer plusieurs Situation Exchange Elements pour plusieurs éléments impactés (OU logique) ?
Merci

Pour définir la période de validité des données décrites par le fichier au profil NeTEx France, une proposition (inspirée des autres profils NeTEx) est d'utiliser une structure ValidBetween dans la première Frame de chaque/toute PublicationDelivery.

<?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>
    <XxxFrame id=".." version="any">
      <ValidBetween>
        <FromDate>2030-01-01T00:00:00</FromDate>
        <ToDate>2030-03-31T23:59:59</ToDate>
      </ValidBetween>
      
      <!-- Contenu -->     

    </XxxFrame>
  </dataObjects>
</PublicationDelivery>

Dans un même fichier ZIP, la période doit être la même dans l'ensemble des fichiers.

Le profil SIRI France devrait mettre en avant quelques exemples de structures Affects pour montrer le bon usage de cette structure dans les cas métier principaux.

En effet, les possibilités offertent sont nombreuses et peuvent conduire rapidement à des incompréhensions/incompatibilités entre producteurs et consommateurs de Situations SIRI.

Quelques propositions d'exemples:

Association avec un ou plusieurs zones d'embarquement

<siri:Affects>
  <siri:StopPoints>
    <siri:AffectedStopPoint>
      <siri:StopPointRef>3534:</siri:StopPointRef>
    </siri:AffectedStopPoint>
    <siri:AffectedStopPoint>
      <siri:StopPointRef>3535</siri:StopPointRef>
    </siri:AffectedStopPoint>
  </siri:StopPoints>
</siri:Affects>

Association avec un ou plusieurs lieux d'arrêts

<siri:Affects>
  <siri:StopPlaces>
    <siri:AffectedStopPlace>
      <siri:StopPlaceRef>3534</siri:StopPlaceRef>
    </siri:AffectedStopPlace>
    <siri:AffectedStopPlace>
      <siri:StopPlaceRef>3535</siri:StopPlaceRef>
    </siri:AffectedStopPlace>
  </siri:StopPoints>
</siri:Affects>

Question: est-ce que ce type d'Affects est vraiment requis/utilisé ?

Association avec une zone d'embarquement mais seulement pour une/des ligne(s) donnée(s)

<siri:Affects>
  <siri:StopPoints>
    <siri:AffectedStopPoint>
      <siri:StopPointRef>3534</siri:StopPointRef>

      <siri:Lines>
        <siri:AffectedLine>
          <siri:LineRef>00673</siri:LineRef>
        </siri:AffectedLine>
      </siri:Lines>
    </siri:AffectedStopPoint>
  </siri:StopPoints>
</siri:Affects>

Association avec une ou plusieurs lignes

</siri:AffectedNetwork>
  <siri:AffectedLine>
    <siri:LineRef>00673</siri:LineRef>
  </siri:AffectedLine>
  <siri:AffectedLine>
    <siri:LineRef>89121</siri:LineRef>
  </siri:AffectedLine>
</siri:AffectedNetwork>

Ce ticket reprend ce que j'ai proposé en terme de structuration technique/de travail au GT7 pour gérer tout ce qui va apparaître à terme sur https://normes.transport.data.gouv.fr.

Je ne suis pas membre du GT7, toutefois le PAN (https://transport.data.gouv.fr/) dont je fais partie a été mandaté pour épauler techniquement cette "migration" du processus de travail depuis des documents Word en "comité non accessible au public", au profit d'un travail sur des profils Markdown dans un mode collaboratif visible du public, pour faciliter autant la lecture des profils par le public, que le travail collaboratif ou encore la remontée de soucis permettant d'améliorer les rédactions etc.

Normes/profils/standards concernés

J'ai pour l'instant identifié 5 éléments qui doivent être gérés et versionnés de façon indépendante:

1. https://github.com/etalab/transport-normes/tree/main/NeTEx (profil NeTEx France)
2. https://github.com/etalab/transport-normes/tree/main/SIRI (profil SIRI France)
3. "Page Chapeau Standard MAS" (https://pad.fabmob.io/qj_8AQ8KS_6LL8tw37loGQ?both#)
4. "Standard Covoiturage - Open Carpooling Service Standard (OCSS)" (https://pad.fabmob.io/bSf2II5DQEOCS3xmycAzZQ?both#)
5. "Standard Compte Mobilité Standardisé (pour le PAN)" (https://pad.fabmob.io/gcVLMNiATbyyZfnX5YfDBQ?both#)

Le GT7 gère les deux premiers sujets. Les trois autres sujets sont gérés par d'autres entités.

Le PAN souhaite pouvoir évidemment gérer cette multiplicité de façon "homogène" tant que possible, pour ne pas réinventer la roue!

N'apparaissent pas ici la partie "tarifs" et la partie "parking" du profil NeTEx France, mais qui seront a priori intégrés et versionés conjointement au profil lui-même, de la même façon que les annexes au profil.

Ce ticket matérialise les idées que j'avais décrite dans le ticket suivant:

• #35 (que je vais clôturer)

Modèle de "découpe"

On aura 1 "repository" GitHub par "ensemble de documents versionnés ensemble" (typiquement, la totalité du profil NeTEx France sera versionné d'une seule voix).

Tout "commit" sur les branches master/main sera intégré dans la prochaine release (voir plus bas). Cela n'empêchera pas de "revenir en arrière" avant une release si on se rend compte qu'il y a un souci (incompatibilité entre les arrêts et autre chose, qui n'auraient pas avancé à la bonne vitesse etc).

=> à tout moment (idéalement), cohérence générale du repository, pour être capable de livrer (ou en tout cas, cohérence avant de faire la livraison)

Questions:

• Est-ce que cela va fonctionner pour le GT7 ? -> réponse OUI en réunion
• 1 version pour SIRI, 1 version pour NeTEx ? -> réponse OUI en réunion, travailler avec un numéro unique pour la totalité de NeTEx France, même si cela impose un peu de rigueur et de synchronisation avant les releases et pendant le travail, est préférable en terme de cohérence et aussi de compréhension des réutilisateurs (il serait compliqué d'avoir des versions différentes pour les arrêts vs les horaires, il faudrait alors une matrice de compatibilité etc)
• Si pas, quel est le bon modèle ?

=> ✅ Principe général validé par le GT7 en session

Retours GT7

=> "acceptable mais il faut que les sous-profils soient cohérents 2 à 2" (ce que j'avais prévu)
=> "Je préfèrerai transport-profil-netex car il ne s'agit pas de normes" (on va voter un nommage précis, peut-être intégrer le -fr dedans pour pouvoir transposer à l'Europe après)
=> "[Question technique] est-ce que hugo (l'outil qui gènere le site web normes...) pourra être utilisé avec un seul repository (netex ou siri) quand on travaille en local ? Réponse -> oui avec un peu d'ajustements

Mes suggestions additionnelles venues en cours de route:

• inspiration https://github.com/NeTEx-CEN/NeTEx (releases)
• gestion par milestones pour organiser le travail sur une release, utile autant pour les contributeurs que pour le public
• ne pas hésiter à noter "il faudra corriger les arrêts avant la prochaine release" etc (créer des tickets pour ne rien oublier)
• bien normer les numéros de versions pour "calculer" facilement quelle est la dernière version
• preview facile "d'une branche donnée" SVP
• les sous-profils ont des versions disjointes, il "suffira" de choisir un numéro de version commune, ET de communiquer dessus (idéalement une numérotation clairement "au dessus" pour homogénéiser)

Notes:

• PR avec commentaires -> auto-changelog

Tâches nécessaires

Attention - "ordonnancement non contractuel"

• (PAN) Déplacer le contenu SIRI vers un autre repository
  • Pourquoi ? Car l'activité du repository (hormis la PR) concerne largement le NeTEx, donc il est plus simple de ne pas déplacer le NeTEx
  • Finaliser #32
    • (GT7) Validation
    • (PAN) modifications techniques (css)
    • (PAN) Publication en l'état
• Création d'une "release" GitHub (tag/release) sur ce nouveau repo pour marquer la v1.7
• Renommage de "transport-normes" en "transport-normes-netex"
• Création d'une "release" pour marquer la version actuelle du NeTEx

Puis:

• (PAN) Préparer une évolution du site capable de:
  • Récupérer la dernière "release" de NeTEx
  • Récupérer la dernière "release" de SIRI
  • Publier les deux ensemble

Puis:

• (GT7) définir le workflow souhaité sur chaque repository (combien d'approvals? etc) - pour les merges mais aussi pour les releases
• (GT7) Définir les personnes : Thierry, Christophe, Alban, Tu-tho, Noémie
• (PAN) aider à mettre en place ces contraintes techniques

Puis:

• Déterminer le niveau d'urgence sur les 3 pads, et fixer un plan similaire

Puis:

• Mettre en place une solution technique permettant d'afficher la "version en cours de travail" de chaque profil (via le site idéalement, ou via des "previews", à définir)
• Idem pour les anciennes versions
• Il est souhaitable d'avoir quelque chose qui fonctionne automatiquement à chaque PR

Le profil NeTEx France met en avant l'utilisation des UicOperatingPeriod:

En revanche, le profil ne précise pas:

• s'il est obligatoire de conserver la définition des périodes, des jours de la semaine, des jours exclus ou inclus auquels l'attibut ValidDayBits s'ajoute
• ou si les UicOperatingPeriods peuvent être utilisés seuls.

Exemple avec description complète

<DayType id="daytype-1">
  <Name>Sample</Name>
  <properties>
    <PropertyOfDay>
      <DaysOfWeek>Tuesday Friday</DaysOfWeek>
    </PropertyOfDay>
  </properties>
</DayType>

<DayTypeAssignment id="assigment-1">
  <OperatingPeriodRef ref="period-1"/>
  <DayTypeRef ref="daytype-1"/>
</DayTypeAssignment>

<DayTypeAssignment id="assigment-2">
  <Date>2030-01-15</Date>
  <DayTypeRef ref="daytype-1"/>
  <isAvailable>true</isAvailable>
</DayTypeAssignment>

<UicOperatingPeriod id="period-1">
  <FromDate>2030-01-01T00:00:00</FromDate>
  <ToDate>2030-01-10T00:00:00</ToDate>
  <ValidDayBits>1001....</ValidDayBits>
</OperatingPeriod>

Exemple avec UicOperatingPeriod seul

<DayType id="daytype-1">
  <Name>Sample</Name>
</DayType>

<DayTypeAssignment id="assigment-1">
  <OperatingPeriodRef ref="period-1"/>
  <DayTypeRef ref="daytype-1"/>
</DayTypeAssignment>

<UicOperatingPeriod id="period-1">
  <FromDate>2030-01-01T00:00:00</FromDate>
  <ValidDayBits>1001....</ValidDayBits>
</OperatingPeriod>

NeTEx - Profil France - Éléments communs | Normes des données de transport

Avant-propos
L’harmonisation des pratiques dans l’échange des données relatives aux offres de transport est essentielle :
pour l’usager, aux fins d’une présentation homogène et compréhensible de l’offre de transport et de l’engagement sous-jacent des organisateurs (autorités organisatrices et opérateurs de transports) ;
pour les AO, de manière à fédérer des informations homogènes venant de chacun des opérateurs de transports qui travaillent pour elle. L’harmonisation des échanges, et en particulier le présent profil, pourra le cas échéant être imposé par voie contractuelle.

https://normes.transport.data.gouv.fr/normes/netex/elements_communs/

Dans une PublishedAction, le profil SIRI France décrit la structure ActionData et notamment son attribut Name.

Mais les attributs Type et Value sont obligatoires dans la XSD SIRI et ne sont pas décrits dans le profil:

response.xml:752:0: ERROR: Element '{http://www.siri.org.uk/siri}Value': This element is not expected. Expected is ( {http://www.siri.org.uk/siri}Type ).
response.xml:754:0: ERROR: Element '{http://www.siri.org.uk/siri}Prompt': This element is not expected. Expected is ( {http://www.siri.org.uk/siri}Value ).

Dans les premiers échanges autour de cette structure PublishedAction/ActionData, les attributs Type et Prompt trouvent une utilitée. En revanche, les attributs Name et Value semblent inutiles.

<siri:PtSituationElement>
  <siri:PublishingActions>
    <siri:PublishToWebAction>
      <!-- ... -->
      <siri:ActionData>
        <siri:Name>useless</siri:Name>

        <siri:Type>short</siri:Type>
        <siri:Value>useless</siri:Value>

        <siri:Prompt xml:lang="NO">Toget vil bytte togmateriell på Dovre. Du må dessverre bytte tog på denne stasjonen.</siri:Prompt>

      </siri:ActionData>
    </siri:PublishToWebAction>
  </siri:PublishingActions>
</siri:PtSituationElement>

En l'état, le profil SIRI France ne liste pas les valeurs verySlight et verySevere dans la description de l'attribut Severity: https://normes.transport.data.gouv.fr/normes/siri/profil-france/#desription-de-lenum-severity

Ils sont pourtant présente dans la XSD.

<!-- 
    How severely the situation affects public transport services.
    
    Possible values:
    - noImpact
    - verySlight
    - slight
    - normal (default)
    - severe
    - verySevere 
-->

En lien avec:

• https://github.com/etalab/transport-normes-site
• #8

Je fais le constat suivant:

• Si on gère les "releases" de chaque profil avec GitHub (voir doc), il faudra placer chaque "unité de travail" (profil SIRI, profil Netex, etc) chacune dans son propre repository GitHub. Sans cela, la création d'une release SIRI (par exemple) englobera automatiquement les changements non encore finalisés (version en cours de travail main/master) du Netex, etc.
• On va ajouter d'autres normes sur ce même système, et ce point deviendra encore plus important
• Je pense que c'est une bonne idée d'utiliser les releases GitHub pour gérer les versions des profils (c'est très pratique, et "idiomatique" dans l'usage de l'outil)
• Il faudra modifier le système de publication du site pour aller chercher "la dernière release" de chaque profil, consolider le tout, et publier l'ensemble
• Il sera nécessaire de disposer d'une "preview" pour chaque profil au cas par cas (par PR etc)
• Il faut viser à terme à être capable de présenter, pour le visiteur, toutes les versions existantes de chaque profil, car c'est très important pour travailler (comparer ce qui a changé, ou manuellement ou automatiquement)

On va d'abord finaliser:

• #32

puis aborder ce travail.

Actuellement les valeurs de TypeOfFuel sont les suivantes

• petrol : essence
• diesel: diesel
• naturalGas : gaz
• biodiesel : diesel bio
• electricity : électrique
• other : autre

La spécification GTFS Vehicles définit d'autres valeurs, permettant une granularité différente.

1 - Gasoline
2 - Diesel
3 - Natural gas
4 - Diesel-electric hybrid
5 - Natural gas hybrid
6 - Battery electric
7 - Fuel cell
8 - Hydrogen

Cet énuméré est-il figé ? Est-il envisagé de revoir/ajouter des valeurs ?

Similaire à etalab/transport-site#2512

Le profil NeTEx France définit comme obligatoire l'attribut OrganisationType d'une Organisation:

Le profil NeTEx France devrait préciser qu'une ressource héritant d'Organisation ne devrait pas à avoir à préciser, par défaut, son type quand celui-ci est explicite.

Par exemple, un Operator ou une Authority sont valides selon la XSD même sans cet attribut:

<Operator id="1" version="any">
  <Name>Operator Sample</Name>
</Operator>

<Authority id="1" version="any">
  <Name>Authority sample</Name>
</Authority>