Objet du marché Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales Agence française pour l'information multimodale et la billettique projet Chouette Note Technique NT-A130306-Proposition de reformulation des tests de conformité V 1.0 14/06/2013 Version Date de révision du document Rédacteur V1 14/06/13 M. Etienne CITYWAY
VALIDATION Rédacteur Vérificateur Approbateur Nom M. ETIENNE Nom Nom Fonction Chef de projet Fonction Fonction Date 14/06/2013 Date Date Visa Visa Visa HISTORIQUE DES VERSIONS Version Chapitres Date Etablie par Vérifiée par Description modification 21/05/13 31/05/13 P. GENDRE remarques 1.0 14/06/2013 M. ETIENNE Création du document DOCUMENTS APPLICABLES Date Etablie par Titre Référence 22/04/2013 M Etienne NT-A130306 [R1] Etat des lieux sur les tests de conformité 02/05/2013 M Etienne NT-A130306 [R2] Synthèse des remarques et réponses sur les tests de conformité DIFFUSION Diffusion Élargie : Noms Organisme Tout utilisateur de Chouette et du format d'échange Neptune
Table des matières Table des matières 1Introduction...4 2Organisation des tests...4 2.1.Catégorie 1...5 2.2.Catégorie 2...5 2.3.Catégorie 3...5 2.4.Proposition de catégorie 4...6 3Modèles de données selon les formats...6 3.1.Modèle interne...7 3.2.Modèle Neptune...7 Vue de la racine du modèle : ChouettePTNetwork...8 Vue des relations autour des arrêts...9 Vue des composants et relations d'une ligne...10 Vue du détail d'une séquence d'arrêts...10 Vue sur les équipements...11 3.3.Modèle CSV (profil Chouette)...12 3.4.Modèle GTFS...12 3.5.Modèle NeTEx (profil Neptune)...12 4Définition des tests...12 5Matrice de traçabilité...12
1 Introduction Ce document reprend reformule les tests de conformité NEPTUNE par rapport à ceux définis par le projet Bateri et implémentés dans la fonction de validation Chouette depuis la V1.7. Le détail des tests est dans le fichier XLSX accompagnant : NT-A130306-Définition des tests de conformité.xlsx A l'origine, ces tests ont été conçus pour valider le format d'échange de données Trident/Chouette (devenu Neptune ensuite). Or il apparaît que ce besoin est restrictif aujourd'hui avec l'apparition d'autres formats : NeTEx et GTFS. Il devient donc intéressant de reclasser et de redéfinir les tests afin de séparer les problématiques liées au format d'échange des problématiques liées à la qualité et la complétude de l'offre de transport. Une analyse de l'existant a été effectuée [R1] et diffusée afin de récolter l'avis du plus grand nombre d'acteurs. Une synthèse des remarques et réponses a été diffusée par la suite [R2] Ce document reprend donc la description des tests de conformité que devra réaliser le logiciel Chouette à partir des résultats issus des documents pré-cités. Note : dans cette version, seul le format Neptune est détaillé, mais le document prévoit déjà l'emplacement des tests sur les formats CSV, GTFS et NeTEx 2 Organisation des tests Les tests sont séparés en 3 catégories: catégorie 1 : conformité par rapport à la syntaxe des formats d'échange catégorie 2 : complétude des données échangées
catégorie 3 : qualité de l'offre de transport Les catégories 1 et 2 s'appliquent uniquement à des données fournies sous forme de fichiers. La catégorie 3 s'applique aussi bien à des fichiers qu'au contenu d'un espace de donnée dans la BD Chouette. Certains tests peuvent être bloquants, d'autres non (occasionnant un avertissement / warning). 2.1.Catégorie 1 La catégorie 1 se limite à s'assurer que les fichiers échangés respectent les règles de format des données - organisation (CSV, XML, ) - éventuellement : nommage des fichiers - contraintes complémentaires quand le mécanisme de description du format est informatisé (exemple XSD) Lorsque les tests de catégorie 1 passent, un logiciel d'import des données ne doit pas rencontrer d'erreur de format lors de la lecture des fichiers. 2.2.Catégorie 2 La catégorie 2 apporte une analyse de la complétude des données échangées, assurant les contrôles que la catégorie 1 ne saurait pas identifier par des règles formalisées dans un langage de description de format tel que les XSD pour le XML. Lorsque les tests de catégorie 2 passent, un logiciel d'import des données ne doit pas rencontrer d'incomplétude dans ses données (exemple : référence à des objets manquants requis). 2.3.Catégorie 3 La catégorie 3 apporte une analyse de la complétude des données pour que celles-ci soient exploitables opérationnellement, par exemple par un calculateur d'itinéraires. Les points de contrôle sont plus «métier» que techniques, comme par exemple la vitesse d'un véhicule pour parcourir l'intervalle entre 2 arrêts, ou la présence d'au moins une course par ligne et par arrêt.
2.4.Proposition de catégorie 4 Il est proposé d'ajouter une catégorie 4 pour définir des tests trop longs ou trop contextuels pour être exécutés globalement, sur la totalité d un jeu de données : Par exemple : 1- identifier les courses d'une même séquence d'arrêts trop proches dans le temps et circulant un même jour 2- identifier des courses identiques : - si celles-ci ne circulent pas sur les mêmes calendriers, proposer de les fusionner en ajoutant les calendriers ; - si elles circulent déjà sur les mêmes calendriers : signaler l'erreur Ces tests pourront être appliqués en sélectionnant une ligne ou un groupe de lignes et une plage calendaire à étudier. 3- proposer des correspondances autour d'arrêts Le test pourra être appliqué sur un arrêt en cours d'élaboration. 4- identifier des calendriers en doublon 5- vérifier que le nombre de passages à un arrêt sélectionné est conforme au niveau de service attendu Ce test est relatif à un arrêt, à une date calendaire et à une ligne. Ce test peut aussi être ciblé plus précisément sur un itinéraire particulier de la ligne, ou bien sur une direction, une mission, etc. Le niveau de service correspond à un intervalle : nombre de passages minimum, nombre de passages maximum 3 Modèles de données selon les formats Actuellement, Chouette gère en import 4 formats de données (NEPTUNE, CSV, GTFS, NETEX) et un modèle interne (base de données) Chacun de ces formats a des contraintes spécifiques et les tests de niveau 1 et 2 ne peuvent pas se formuler de la même façon selon le format. À l'issue de l'analyse des formats d'import, le modèle sera converti en modèle interne afin de subir les tests de niveau 3, quelle que soit son origine.
3.1.Modèle interne Le modèle interne de la BD Chouette est représenté selon le schéma suivant : 3.2.Modèle Neptune Le modèle Neptune est issu du standard Trident et est défini par la XSD Norme AFNOR : PR NF P99-506 Il est composé des éléments de modèles présentés dans les planches qui suivent. Se référer au document AFNOR pour le détail de ces objets.
Vue de la racine du modèle : ChouettePTNetwork
Vue des relations autour des arrêts Note : les objets de type : Quay BoardingPosition CommercialStopPoint StopPlace ITL sont tous des objets de type StopArea, avec un attribut areatype correspondant à leur type.
Vue des composants et relations d'une ligne Vue du détail d'une séquence d'arrêts
Vue sur les équipements
3.3.Modèle CSV (profil Chouette) Rédaction ultérieure 3.4.Modèle GTFS Rédaction ultérieure 3.5.Modèle NeTEx (profil Neptune) Rédaction ultérieure 4 Définition des tests Le détail des tests est dans le fichier XLSX accompagnant : NT-A130306-Définition des tests de conformité.xlsx 5 Matrice de traçabilité Dans le tableau ci-dessous, sont présentés les tests de validation actuels issus de Bateri et leur correspondance avec les tests définis dans le document présent. Faire référence au document CALC Neptune Catégorie 1 Bateri Nouveau test Note 1.1.1 1-XML-1 1.2.1 1-XML-2
Neptune Catégorie 2 Bateri Nouveau test Note 2.1.1 2-NEPTUNE-Network-1 2.1.2 1-XML-2 2.2.1 2-NEPTUNE-GroupOfLine-1 2.3.1 2-NEPTUNE-StopArea-1 2.4.1a abandonné Voir note n 2 dans le test 2- NEPTUNE-ConnectionLink-1 2.4.1b 2-NEPTUNE-ConnectionLink- 1 2.5.1 2-NEPTUNE-Timetable-1 Le test se limite à vérifier que parmi les VehicleJourneyId présents dans la liste du Timetable, au moins un est présent dans le fichier contrôlé 2.5.2 2-NEPTUNE-Timetable-2 2.6.1 1-XML-2 2.6.2 2-NEPTUNE-Line-1 2.7.1 2-NEPTUNE-Line-2 2.8.1 2-NEPTUNE-Route-4 2.8.2 2-NEPTUNE-Route-4 2.8.3a 2.8.3b 2.8.3c 2.8.3d 2-NEPTUNE-Route-7 2-NEPTUNE-Route-2 2-NEPTUNE-Route-1 2-NEPTUNE-Route-4 2.9.1 2-NEPTUNE-Route-8
2.10.1 1-XML-2 2.11.1 1-XML-2 2.12.1 2-NEPTUNE-StopArea-6 2.13.1 1-XML-2 2.14.1a 2.14.1b 2-NEPTUNE-Route-2 2-NEPTUNE-Route-1 2.14.2 2-NEPTUNE-Route-3 2.15.1 2-NEPTUNE-Route-7 2.15.2 2-NEPTUNE-Route-7 2.16.1 1-XML-2 2.17.1 1-XML-2 2.18.1 1-XML-2 2.18.2a 2.18.2b 2-NEPTUNE-VehicleJourneyAtStop-1 2-NEPTUNE-VehicleJourneyAtStop-1 2.19.1 1-XML-2 2.20.1 1-XML-2 2.21.1 1-XML-2 2.22.1 1-XML-2 2.23.1 1-XML-2 2.24.1 2-NEPTUNE-VehicleJourney- 1 2.25.1a 2.25.1b 2-NEPTUNE-AccessPoint-3 2-NEPTUNE-AccessPoint-3
2.26.1 2-NEPTUNE-AccessPoint-1 2.27.1 1-XML-2 La norme Neptune contient une coquille sur le champ containedin : 2.28.1 1-XML-2 2.28.2 1-XML-2 2.28.3 1-XML-2 2.28.4 1-XML-2 L'identifiant «objectid» de la zone d'arrêt «StopArea» contenant cet arrêt sur itinéraire. Tout arrêt sur itinéraire est contenu à une et une seule zone d'arrêt. En remplaçant 'arrêt sur itinéraire' par équipement, le test peut être appliqué dans la XSD
rêts sur parcours. 3.7.1 3-Route-3 3.8.1a 3.8.1b 3.8.1c 3.8.1d 3-ConnectionLink-1 3-ConnectionLink-1 3-ConnectionLink-1 3-ConnectionLink-1 3.9.1 3-VehicleJourney-3 3.10.1a 3.10.1b 2-NEPTUNE-Route-2 2-NEPTUNE-Route-2 3.10.2 3-Route-1 3.10.3 3-Route-3 3.11.1 2-NEPTUNE-Route-6 3.15.1 3-VehicleJourney-2 3-VehicleJourney-3 3.16.1 3-VehicleJourney-4 3.16.2 3-VehicleJourney-5 3.16.3a 3.16.3b 3-VehicleJourney-3 3-VehicleJourney-2 3.17.1 2-NEPTUNE-AccessPoint-4 3.18.1a 3.18.1b 2-NEPTUNE-AccessPoint-4 3-AccessPoint-3 + 3-StopArea-4 3.19.1 2-NEPTUNE-Facility-1
3.20.1a 3.20.1b 3.21.1a 3.21.1b 3.21.1c 3.21.1d 2-NEPTUNE-Facility-1 3-Facility-2 3-AccessLink-3 3-AccessLink-3 3-AccessLink-3 3-AccessLink-3