-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Structure des fichiers - Accessibilité #118
Comments
Proposition faite par @nlehuby le 13 juin 2024 dans le ticket originel Contient
|
A discuter : différenciation des cas où
Important à prendre en compte : la non-duplication de ressources existantes telle que mentionnées dans #112 |
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é :
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 :
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 |
Il n'est pas toujours possible de mettre les cheminements et équipements dans les fichiers des arrêts et des POIs : on peut en effet avoir des cheminements piétons en voirie qui ne sont raccrochés ni à un arrêt ni à un POI. Mais ma proposition était plutôt de ne pas exporter les arrêts et les POIs dans le fichier ACCESSIBILITY.xml, mais uniquement les éléments que j'ai listés (SitePathLink, PathJunction et équipements de tout type), avec des références vers les arrêts et POIs si nécessaires. Dans la pratique, ça ne change pas grand chose par rapport à ce que tu décris :
et dans le fichier ACCESSIBILITY.xml, tu mets des références vers le fichier STOP.xml
soit, si tu as peu de données ou qu'elles sont très simples, tu renseignes tout dans l'arborescence des objets déjà présents dans le fichier STOP.xml
|
Entrée ZIP:
ACCESSIBILITY.xml
Travail en cours
The text was updated successfully, but these errors were encountered: