Structure des fichiers - Accessibilité

[TuThoThai]

Entrée ZIP: ACCESSIBILITY.xml

Travail en cours

[TuThoThai]

Proposition faite par @nlehuby le 13 juin 2024 dans le ticket originel

Contient

• 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

[TuThoThai]

A discuter : différenciation des cas où

• l'accessibilité est décrite dans une offre existante (via les éléments STOPS.xml ou POI.XML ou autre)
• l'accessibilité ne se raccroche pas à des arrêts existants (ex. description cheminement)

Important à prendre en compte : la non-duplication de ressources existantes telle que mentionnées dans #112

[albanpeignier]

Je voudrais partager notre réflexion sur les cases d'usage de ce fichier ACCESSIBILITY.xml

Le fichier ACCESSIBILITY.xml permet aux outils dédiés de fournir simplement l'ensemble des informations d'accessibilité concernant des ressources qui sont définies par ailleurs dans un fichier complet.

Mais que se passe-t-il quand l'ensemble des fichiers sont utilisés ? C'est-à-dire quand le fichier des arrêts, le fichier des points d'intérêt sont présents ?

D'un côté, un fichier "principal" à qui on demande de définir une ressource (ex : un arrêt). De l'autre un fichier ACCESSIBILITY.xml à qui on demande de définir l'accessibilité de cette même ressource.

Spoiler: cela devient vite problématique. Rien n'empêche les différents fichiers de se marcher sur les pieds. Dans les quelques fichiers ACCESSIBILITY.xml que nous avons croisés, les ressources (StopPlace, PointOfInterest) sont définies en intégrant bien d'autres informations que l'accessibilité :

 <StopPlace id="Yukaimaps:StopPlace_water:n-678944:LOC" version="any">
  <keyList>
    <KeyValue typeOfKey="WDM_tag">
      <Key>Ref:Import:Id</Key>
      <Value>n1558653713</Value>
    </KeyValue>
    <KeyValue typeOfKey="WDM_tag">
      <Key>Ref:Import:Source</Key>
      <Value>OpenStreetMap</Value>
    </KeyValue>
    <KeyValue typeOfKey="WDM_tag">
      <Key>Ref:Import:Version</Key>
      <Value>6</Value>
    </KeyValue>
  </keyList>
  <Name>Corentin Cariou</Name>
  <Centroid>
    <Location id="n-678944">
      <Longitude>2.3835451</Longitude>
      <Latitude>48.8967651</Latitude>
    </Location>
  </Centroid>
  <placeTypes>
    <TypeOfPlaceRef ref="monomodalStopPlace"/>
  </placeTypes>
  <facilities>
    <SiteFacilitySet id="Yukaimaps:SiteFacilitySet:132176:" version="any">
      <MobilityFacilityList>unknown</MobilityFacilityList>
    </SiteFacilitySet>
  </facilities>
  <TransportMode>water</TransportMode>
  <StopPlaceType>ferryPort</StopPlaceType>
</StopPlace>

Quand le fichier d'arrêt défini le même arrêt… il doit (pour être lui-même valide) venir avec toute une partie de ces mêmes attributs. Qui dit que les valeurs seront identiques ? Comment un consommateur de données peut comprendre ce que se trame ? Et plus généralement, cela contrevient à la règle globale de non-duplication des ressources.

Même soucis pour les PointOfInterests, etc.

Face à ce dilemme, nous travaillons actuellement avec cette approche :

• le fichier ACCESSIBILITY.xml peut être importé, seul, pour compléter les données d'arrêts, points d'intérêt, etc
• quand les données sont publiées au profil NeTEx France, les ressources et tous leurs attributs sont exportés dans le fichier principal (STOP.xml, POI.xml, etc).
• pour l'heure, nous préférerions mettre les cheminements et équipements dans les fichiers principaux (STOP.xml, POI.xml). Notamment parce qu'il existe beaucoup de situations où ils n'ont pas (encore) d'information d'accessibilité

En gros, cela rend le fichier ACCESSIBILITY.xml optionnel, quand les informations d'accessibilité sont déjà portées par les resources dans les fichiers principaux (STOP.xml, POI.xml, etc). Le consommateur du fichier n'a pas à se poser de questions.

Je ne vois malheureusement pas d'autres approches qui ne rendent pas le fichier ZIP très fragile / difficile à lire.

cc @nlehuby