Cadre commun d interopérabilité routier

Transcription

1 service d É tudes techniques des routes et autoroutes les études Cadre commun d interopérabilité routier Guide pour les échanges de données routières - version 1 s de situations d échange 23 décembre 2004 ministère de l'équipement des Transports de l'aménagement du territoire du Tourisme et

2

3 Sommaire 1 : Intégration de données recueillies automatiquement par le gestionnaire d un réseau routier (I) : Récupération de données de trafic RD par le gestionnaire RN (E) : Réalisation d un référentiel métier à partir du référentiel de base (I) : Remontées des mouvements du réseau routier national (I) : Traitement commun de données RN et RD sur un département (E) : Récupération de données géographiques (I) : Conservation de données en vue de leur réutilisation ultérieure (I) : Transfert de données SICRE à un Conseil Général (E) : Publication de cartes interactives sur Internet/Intranet (I) a : Géocodage linéaire de données (I) b : Accès à un service en ligne de géocodage (I) : Exploitation de données par un logiciel spécialisé (I) a : Production d un référentiel RIU RD (E) b : Production d un référentiel RES (I) a : Agrégation au siège du Conseil Général de données de subdivisions (I) b : Agrégation au Conseil Général de données de subdivisions (I) : Importation sous Visage de données au format tableur (I) La lettre I ou E indiquée entre parenthèses à la fin du titre de chaque situation d échange signifie : I : l échange de données est interne à un système d information routier E : l échange de données se fait entre deux systèmes d information routiers (par exemple entre le SIR RD d un CG et le SIR RN d une DDE) Ce document détaille le chapitre 6.1 du guide pour les échanges de données routières. CETE Méditerranée - Département de l informatique / service ETER 3/39

4 CETE Méditerranée - Département de l informatique / service ETER 4/39

5 1) Intégration de données recueillies automatiquement par le gestionnaire d un réseau routier ( I ) Description de la situation d échange Objet Un gestionnaire de réseau routier commande la collecte de dégradations sur son réseau. Les données seront ensuite intégrées dans la base de données Visage du gestionnaire. Ces dégradations sont collectées par un opérateur muni d un système d acquisition embarqué dans un véhicule équipé d un compteur métrique étalonné. Collecte de données avec l appareil de saisie DESY. Illustration 1 er échange :Transmission des éléments du référentiel de localisation 2ème échange : Fourniture des dégradations recueillies sur le terrain Référentiel de localisation recueillies Difficultés Exploitation Le fournisseur est l opérateur qui va effectuer la collecte de données. Afin de localiser les données collectées de façon cohérente avec le référentiel du gestionnaire, il utilise le référentiel fourni par ce dernier. Le client est un gestionnaire de réseau RN ou RD utilisant l application Visage. Les données sont recueillies et localisées en PR+abscisse par rapport au référentiel de localisation transmis à l opérateur. Ces données sont livrées au client au format PRA de Visage. L intégration du fichier dans la base Visage est soumise à différents contrôles permettant d en assurer l intégrité. Le client intègre les données dans Visage pour appliquer les règles de gestion permettant de mettre en évidence les sections de routes dégradées qui seront prioritaires à l entretien. Des cartes à l attention des décideurs sont alors produites pour faciliter la lecture des sections dégradées et pour permettre un «lissage» compatible avec des sections de travaux. Une commande peu claire, peu précise, notamment au sujet des données à collecter (précision, pas de mesure ) et des sections de routes, ne permettront pas d obtenir les résultats escomptés quant aux choix des sections de routes à entretenir en priorité. Quand la saisie est commencée, il n est plus possible de modifier la commande! Le bornage dans la base Visage, dit «référent», sera utilisé par le fournisseur des données. S il n est pas à jour, il y aura un grand nombre de sections de routes rejetées et une perte de temps. Un bornage sur le terrain déficient (absence de borne, incertitudes sur les origines et extrémités des routes, baïonnettes floues) ne facilitera pas la collecte des données. Le référentiel cartographique sera utilisé pour produire les cartes de l état des routes. S il n est pas à jour il ne sert à rien. La localisation des données recueillies avec le système DESY se fait en PR+abscisse. s de données : Déformations, Fissures transversales, Fissures longitudinales, Glaçage, Ressuage, Réparations de règle de gestion : SI Déflexion > 100 ET Fissures longitudinales importantes ET Déformations en rives importantes ALORS note de priorité = 1 CETE Méditerranée - Département de l informatique / service ETER 5/39

6 Solutions recommandées Solutions actuelles Recommandations pour le long terme 1/ Préparation de la campagne La préparation de la campagne de collecte doit être rigoureuse : Un bilan préalable de l état du bornage de la base de données est indispensable. En cas d incertitude, la commande doit prévoir une nouvelle mesure du bornage, La liste des routes à collecter doit être établie avec soin. Elle doit faire l objet d une analyse fine afin d écarter les sections sur lesquelles des travaux sont déjà prévus et qui risquent de rendre obsolète les mesures, Des cartes au 1/ ème doivent être communiquées aux équipes de mesure. Les routes seront soulignées et les PR dessinés avec leur numéro. Ces cartes seront d un format adéquat pour être utilisées dans le véhicule lors de la saisie. Le catalogue des rubriques à collecter est établi en cohérence avec la politique d entretien retenue, Privilégier des saisies sur des PR entiers. 2/ Bornage référent Le client extrait de sa base Visage le bornage référent, pour l adresser au collecteur de données dans un format prévu à l avance (par exemple tableur). Par mesure de sécurité, le collecteur des données doit saisir le bornage sur le terrain en même temps que les dégradations. Le collecteur comparera le bornage relevé in situ avec ce bornage référent. Des éventuelles incohérences portant sur les noms des routes, les numéros des PR et les distances interpr seront alors mis en évidence et présentés sur un tableau des écarts. 3/ Réception des données dans Visage Le tableau des écarts doit faire l objet d une sérieuse analyse. Les données localisées sur des PR présentant des différences importantes de l ordre de 3 % soit 30 m pour 1000 m, feront l objet d une étude par l administrateur de la base pour prendre la décision de les intégrer ou non dans la base. Une différence importante peut cacher des anomalies (erreur de route lors des mesures, mesure incorrecte, bornage référent pas à jour, PR déplacé). L administrateur intègre les données dans Visage et procède à une analyse permettant de déceler des sections dont les mesures sont obsolètes en regard de travaux postérieurs à la saisie. Cette opération banale de collecte de données montre l importance du bornage. S il est incohérent avec la réalité du terrain, des données seront perdues. La mise à jour du référentiel doit toujours être un préliminaire à toute saisie. Des outils de contrôles doivent être développés par les éditeurs de logiciels. Par ailleurs, la commande de collecte de données doit être cohérente avec la politique d entretien locale. Si cette politique n est pas écrite, ne pas lancer de collecte car la commande sera imprécise et risquera de ne pas permettre les exploitations désirées. Gérer et administrer une base de données routière requiert beaucoup d attention et de professionnalisme. L administrateur doit planifier en amont les actions à mener pour répondre à une politique routière clairement exprimée. Les maîtrises d ouvrage nationales doivent mettre en place des formations d administrateur de base de données routières. CETE Méditerranée - Département de l informatique / service ETER 6/39

7 2) Récupération de données de trafic RD par le gestionnaire RN ( E ) Description de la situation d échange Objet Il s agit de récupérer les données de trafic sur les routes départementales pour les intégrer dans une base de données comprenant à la fois des données RN et RD. Une DDE veut produire une carte des trafics sur les routes principales du département. Pour cela, elle gère une base de données sous Visage, le conseil général quant à lui utilise un autre progiciel du marché. Illustration RD Difficultés Exploitation Le fournisseur est le gestionnaire d un réseau routier départemental (Conseil Général) qui utilise un système de gestion qui lui est propre. Le client de l échange est un gestionnaire départemental (DDE) du réseau national. Les données sont localisées en PR+abscisse et en abscisse cumulée. Selon que la DDE dispose ou non du référentiel RD, la procédure d échange peut-être différente. Le client vérifie les données de trafic reçues et les intègre dans sa base départementale. Une fois cette intégration réalisée, il peut effectuer les traitements prévus. Les difficultés habituellement rencontrées concernent : le respect du format d échange, la fourniture de la date des données, l intégrité des données, la qualité du référentiel du client et sa cohérence avec celui du fournisseur. Les données sont fournies au format PRA, format d échange de Visage. Les données suivantes sont fournies : Bornage, Année de saisie du trafic, TMJA dans les deux sens, Nombre de poids lourds, % de poids lourds, Classement T0 à T5. La DDE intègre les données dans Visage et produit la carte départementale des trafics en utilisant le logiciel Carten. CETE Méditerranée - Département de l informatique / service ETER 7/39

8 Solutions recommandées Solutions actuelles La commande doit être très précise en terme de description des données et de dates de recueil de ces données. Cas 1 : le client dispose du référentiel RD En plus des données de trafic, il est conseillé au client de demander au fournisseur son référentiel (bornage et géographie des routes) pour le comparer à celui dont il dispose. En cas d écart, une analyse conjointe permettra de lever les ambiguïtés : La comparaison des bornages peut se faire simplement sur un tableur, La comparaison de la géographie des routes ne peut généralement pas être automatisée totalement. Elle peut être réalisée avec l aide d un progiciel SIG par des requêtes (liste des routes, longueurs des tracés de routes ) et avec une analyse visuelle. Cas 2 : le client ne dispose pas du référentiel RD Le fournisseur transmet son référentiel au client. Ce dernier doit alors intégrer le référentiel RD dans son propre référentiel, ce qui peut être complexe si les logiciels utilisés ne sont pas les mêmes. Avec Visage, il est possible de créer une carte à partir de plusieurs bases. Pour simplifier l agrégation des données RN et RD, cette solution est préférable à l intégration des données RD dans la base RN. Ceci règle le problème de l agrégation des deux fichiers de bornage. En revanche, pour la géographie des routes, elle doit être commune aux deux réseaux RN et RD. Pour les données de trafic, elles doivent être fournies comme dans le cas 1 au format PRA. Recommandations pour le long terme Normalisation des descriptions des données routières L agrégation des données RN et RD suppose qu elles soient homogènes. Il est donc indispensable de normaliser les données de trafic de façon consensuelle entre les différents gestionnaires. Conception des logiciels de traitement routiers Il est recommandé aux concepteurs de logiciels de minimiser les contraintes en matière de référentiel afin d éviter d imposer aux clients des échanges un effort important de constitution d un référentiel (cf. recommandations du guide pour les échanges de données routières). CETE Méditerranée - Département de l informatique / service ETER 8/39

9 3) Réalisation d un référentiel métier à partir du référentiel de base ( I ) Description de la situation d échange Objet Les métiers liés à la route ont en général besoin de s appuyer sur un référentiel pour localiser leurs données et les exploiter. Lorsqu il existe, le référentiel d origine est souvent dénaturé afin d en simplifier l organisation et l usage pour le métier concerné. Lorsqu il n existe pas ou que l utilisateur n en a pas connaissance, le référentiel métier doit être construit de toutes pièces. Toute évolution du réseau nécessite la synchronisation régulière de ce référentiel métier par rapport à la réalité du terrain afin de garantir la cohérence des données entre plusieurs métiers. Sections de comptage utilisées en ingénierie du trafic. Autres exemples : Sections à délester pour les Plans de Gestion de Trafic (PGT), Réseau Alert C, Ouvrages d Art, Hiérarchisation d un réseau. Illustration 1 2 Référentiel de base Référentiel de base Référentiel métier Le fournisseur 1 est l administrateur du référentiel de base. Le fournisseur 2 est le service métier. Gestionnaire du réseau RN et/ou RD (fournisseur 1), CDES (fournisseur 2). Difficultés Exploitation Le client est le service producteur de données routières. Il doit construire son référentiel métier en s appuyant sur les données référentielles dont il dispose. Les données référentielles extraites ne représentent bien souvent qu une partie du référentiel de base (liste des routes avec le bornage, cartographie ). Il s agit de construire, à partir des éléments métier, un référentiel métier cohérent avec le référentiel de base. Pour cela, les éléments métier doivent donc être localisés sur le référentiel de base. Les démarches de construction de référentiels métiers ne sont pas très solides. Le lot de données du référentiel métier ne représentant qu une partie du référentiel de base, deux types d anomalies peuvent être introduits : Les informations échangées peuvent être incomplètes, L interprétation au niveau du client peut être erronée sans qu il ait moyen de s en rendre compte. Le référentiel de base et les éléments métier ne sont pas synchronisés sur la même date. Il est difficile de savoir quelles évolutions du référentiel de base influent sur le référentiel métier. Cellule d exploitation du trafic de la DDE. Fourniture de la liste des carrefours aux fins de définition des sections de comptage. Modification des localisations (en PR+abscisse) portées par les sections de comptage. Les demandes d actualisation ne sont pas systématiques. L information faisant l objet de l échange (carrefours) est partielle et incertaine. L utilisation de cette seule information peut générer des erreurs imprévisibles. Les réseaux RN et RD peuvent être disjoints, ce qui est une source d erreur supplémentaire. CETE Méditerranée - Département de l informatique / service ETER 9/39

10 Solutions recommandées Solutions actuelles Recommandations pour le long terme Les principes qui suivent sont classés par ordre de facilité de mise en œuvre : Chaque mise à jour du référentiel métier doit faire l objet par le client d une demande d extraction du lot de données référentielles auprès du gestionnaire du réseau en précisant la date de validité attendue du référentiel, Les besoins du client doivent être spécifiés avec précision et rappelés à chaque demande d extraction. L usage des données du référentiel de base (issues de l extraction) doit également être précisé car cela peut influer sur l extraction, Le lot de données mis à disposition du client doit être accompagné d éléments complémentaires permettant au client de juger de la cohérence des informations, Le nouveau référentiel métier doit être soumis au gestionnaire afin qu il le qualifie. Les référentiels métiers aujourd hui disponibles ne prennent pas toujours en compte l existence récente des référentiels géographiques (ou les prennent en compte uniquement au niveau de la restitution). L utilisation de ces référentiels géographiques peut être utilement exploitée de plusieurs façons : Gérer les éléments du référentiel métier autant que possible dans leur mode de localisation géographique. Ceci permet une exploitation autonome par rapport au référentiel métier, Intégrer la visualisation cartographique des données, Prévoir la gestion de l historique des référentiels métiers, Intégrer directement les éléments du référentiel de base dans le référentiel métier, Faire évoluer les outils en ce sens. Mélodie, Arpège. CETE Méditerranée - Département de l informatique / service ETER 10/39

11 4) Remontées des mouvements du réseau routier national ( I ) Description de la situation d échange Objet Tous les ans, les DDE envoient au Sétra un dossier constitué avec l'aide des CETE et validé par ces derniers. Ce dossier contient : les modifications du référentiel routier (routes nationales et autoroutes non concédées) de l'année en cours, le noyau dur Visage de l année N. Le Sétra met à jour certaines rubriques du référentiel SICRE à partir du noyau dur. s de modifications d un référentiel : Déclassement d'une route, Création d'une route nouvelle, Modification de tracé. s de rubriques du noyau dur : Rub02 : N2000 N9000 Rub21 : calibrage N-1 Illustration Noyau dur N Référentiel N-1 N Mouvement Référentiel N Référentiel N Difficultés Exploitation Le fournisseur de données est la DDE, aidée par le CETE si nécessaire. Le Sétra reçoit également les données des Autoroutes concédées de la part de RCA, mais cet échange n est pas pris en compte ici. Le client est le Sétra dont le rôle consiste à produire un référentiel France entière des RN et Autoroutes et fournir à la DR des éléments pour calculer la dotation. Noyau dur N : données de l'année N envoyées pas la DDE. Mouvements de référentiel N : descriptions des modifications. N-1 : base de données France entière de l'année N-1. Référentiel N-1 : Référentiel France entière du réseau à l'année N-1. N : données N-1 mises à jour avec les données du noyau dur N. Référentiel N : Référentiel France entière mis à jour à partir du référentiel N-1 et des mouvements du référentiel de l'année N. Les données sont exploitées par le biais de l'infocentre du Sétra. Les modifications du référentiel sont transmises à l'ign, et le référentiel est utilisé par les applications et pour la création de cartes au Sétra. Les données peuvent être croisées entre elles grâce au référentiel et l'historique du référentiel est stocké annuellement. de qualité inégale d'un département à l'autre. Les procédures préconisées par le Sétra ne sont pas respectées (guide des procédures d'identification). CETE Méditerranée - Département de l informatique / service ETER 11/39

12 Solutions recommandées Solutions actuelles Recommandations pour le long terme Faire agir le maître d'ouvrage (DR en l'occurrence) de façon à obtenir des DDE qu elles fournissent leurs données en temps et en heure voulus. Effectuer des contrôles sur les données aux CETE, puis au Sétra (normalement, une seule étape de contrôle devrait suffire). On peut imaginer une manière de fonctionner de façon plus "automatique" : par exemple, une base centralisée ainsi qu'une homogénéisation des pratiques de remontées de modifications de référentiels. Le fond du problème n'est pas l'outil, mais l'implication des acteurs. Il est préférable d'être en contact régulier et d'aider les différents acteurs (création d'une communauté), que de fournir des outils qui seront mal utilisés si ces acteurs n'ont à s'en servir qu'une ou deux fois par an. CETE Méditerranée - Département de l informatique / service ETER 12/39

13 5) Traitement commun de données RN et RD sur un département ( E ) Description de la situation d échange Objet Certains traitements de données routières, à l échelon du département, concernent à la fois le réseau routier national et le réseau routier départemental. Le traitement commun de ces données peut, dans un certain nombre de cas (géocodage, analyse linéaire ), nécessiter de disposer d un référentiel de localisation commun. L étude des accidents avec Concerto nécessite l agrégation des données d accidents RN et RD du département. Autre exemple : la recherche d itinéraires de délestage nécessite la connaissance des RN et des RD (largeur des chaussées, gabarit des ouvrages ). Illustration 1 er échange : Fourniture des données RD par le Conseil Général 2ème échange : Fourniture des données RN par la DDE de de données RD RD de de données RN RN Lot de données RD Lot de données RN Difficultés Exploitation Les fournisseurs de données sont les gestionnaires des réseaux (le Conseil Général pour les RD et la DDE pour les RN). Ils extraient les données demandées par le client et sont parfois amenés à fournir également les éléments qui permettront de composer un référentiel commun de localisation. Le client est un chargé d étude en DDE, en Conseil Général, en DRE ou en CETE. Il doit déterminer, en fonction des traitements qu il envisage de réaliser et des contraintes du logiciel qu il utilisera, le référentiel de localisation le mieux adapté, c est à dire le plus simple à produire. Les données RN et RD comprennent les données métier à traiter ainsi que les éléments du référentiel. Le client prépare tout d abord le référentiel de localisation nécessaire. Ensuite, il homogénéise, si nécessaire les données en provenance des deux fournisseurs de façon à pouvoir ensuite les traiter globalement. Il est alors en situation de réaliser les traitements envisagés. Le prétraitement d homogénéisation des données (à la charge du client) peut être délicat voire impossible : absence de correspondance entre les données RN et RD. Il peut conduire à appauvrir sensiblement les données. Si le traitement envisagé nécessite la présence du référentiel de localisation (visualisation cartographique, analyse linéaire ), la constitution d un référentiel global à partir des référentiels des différents réseaux peut s avérer très complexe et parfois difficilement justifiable pour les seuls besoins d une étude. Si les données d accidents sont normalisées au modèle du BAAC, il n en est pas de même des référentiels de localisation. Les DDE disposent généralement du RIU alors que les Conseils Généraux utilisent des référentiels propres à leurs logiciels de gestion des routes. Concerto s appuyant sur un référentiel de localisation sur le modèle du RIU, le client doit donc réaliser un RIU mixte RN-RD. L expérience des pôles SIR montre que la fabrication d un RIU RN-RD représente une charge de travail élevée. Si les deux référentiels de départ ne partagent pas les mêmes concepts ou les mêmes règles de fabrication, ce travail peut même s avérer impossible en pratique. CETE Méditerranée - Département de l informatique / service ETER 13/39

14 Solutions recommandées Solutions actuelles Recommandations pour le long terme En fonction des traitements envisagés, il faut déterminer les propriétés attendues des données à récupérer et les modes de localisation nécessaires. A partir de ces besoins, le client peut préciser aux différents gestionnaires les caractéristiques des données qu il souhaite récupérer (référentiel y compris). Description des données S il existe une description normalisée des données, le client a intérêt à s en rapprocher le plus possible et à demander aux gestionnaires la fourniture correspondante. Si un traitement d homogénéisation doit être réalisé, il est possible que les gestionnaires puissent le faciliter et acceptent de faire une partie du travail. Localisation des données Il est conseillé au client, pour des questions évidentes de coût de fabrication, de minimiser les besoins en matière de référentiel, en respectant les préconisations suivantes : Si le traitement comprend une visualisation cartographique, il est recommandé de demander aux gestionnaires de fournir les données métier avec leur localisation géographique (en X/Y), ce qui évitera de transmettre un référentiel de localisation pour ce seul besoin de visualisation. Si le traitement nécessite une analyse linéaire telle que le calcul de la distance entre deux objets sur la route (ex. : distance entre deux accidents), la fourniture de l abscisse cumulée avec les données métier peut s avérer suffisante pour réaliser ces traitements sans nécessiter de référentiel de localisation. Contraintes dues au logiciel de traitement Le logiciel de traitement peut également introduire ses propres contraintes en matière de référentiel de localisation ou de structuration des données à traiter. Normalisation des descriptions de données routières Les gestionnaires doivent utiliser chaque fois qu elles existent les descriptions normalisées des données routières. L élaboration de ces descriptions normalisées au plan national doit donc être engagée avec la participation des gestionnaires de réseaux qui seront ensuite les premiers concernés. Conception des logiciels de traitement des données routières Il est recommandé aux concepteurs de logiciels de traitement des données routières de minimiser les contraintes en matière de référentiel afin d éviter d imposer aux utilisateurs (le client, en l occurrence) un effort important de constitution d un référentiel. Le guide pour les échanges de données routières propose une démarche en ce sens aux éditeurs de logiciels routiers. Il est conseillé de s y référer. Pour l étude des accidents, le logiciel Concerto apporte des fonctions d analyses statistiques et spatiales très élaborées. Si les deux gestionnaires disposent d un référentiel de localisation de type RIU, ce logiciel peut être utilisé efficacement sans un travail préalable lourd de production d un référentiel RN-RD. Dans le cas contraire, deux solutions peuvent s envisager : Production préalable d un RIU RN-RD de manière à pouvoir ensuite exploiter les possibilités d analyse de Concerto, Utilisation de logiciels d analyse (progiciel statistique, par exemple) n imposant pas de référentiel de localisation. La visualisation des accidents sur un fond de carte courant (ex. : Bdcarto, Route500 ) reste possible si les accidents disposent d une localisation en X-Y. Le calcul de distance (ex. : recherche de zone d accumulation) peut également être possible si les accidents disposent d une localisation en abscisse curviligne. Dans le domaine des accidents, la refonte de l application Concerto sur un référentiel plus léger et plus ouvert que le RIU devrait être envisagée par le maître d ouvrage concerné. Cette nouvelle version serait ainsi beaucoup plus attractive et beaucoup plus simple d emploi. CETE Méditerranée - Département de l informatique / service ETER 14/39

15 6) Récupération de données géographiques ( I ) Description de la situation d échange Objet Il s agit de récupérer des données géographiques pour les combiner avec des données routières sous un logiciel (tel que Mapinfo ou Carten) permettant la représentation cartographique.. Illustration géographiques Difficultés Exploitation Le fournisseur peut être un vendeur de bases de données géographiques, un gestionnaire de réseau routier, un dessinateur du service, un cabinet de géomètres ou encore l utilisateur même de l outil ; dans ce cas le fournisseur est également le client. Le client est un gestionnaire de réseau routier ou un service général assurant la mise à disposition des données pour une DDE ou un Conseil Général. De type vecteur ou de type raster, les données sont diverses. On trouve toute la gamme des données utilisées sous un SIG : zones, lignes, point et textes. Le client intègre les données cartographiques dans son SIG pour les utiliser de différentes manières selon leurs richesses attributaires : Soit pour produire une carte descriptive, Soit pour produire des analyses thématiques, alphanumériques ou cartographiques. Les difficultés rencontrées sont liées : Aux systèmes de projection connus ou inconnus, Les données sont localisées de trois manières possibles : dans un système de projection connu, dans un système de projection inconnu ou dans le système de projection dit «non-terrestre». La non-maîtrise du système de projection entraîne des difficultés, A l utilisation de référentiels routiers géographiques différents, A l intégrité des données, A la date des données pas toujours connue, Aux différences de précision souvent liées aux échelles différentes utilisées pour la production des données du fournisseur et du client, Aux règles des droits et copyright peu connues, qui ne facilitent pas la diffusion, En moindre mesure, au format des données. CETE Méditerranée - Département de l informatique / service ETER 15/39

16 Solutions recommandées Solutions actuelles Le lot de données géographiques doit correspondre à une commande précise faite par le client au fournisseur. Cette commande doit toujours préciser les points suivants : Projection, Dates des données, Pour un référentiel routier ou des données préalablement géocodées, date et origine du référentiel routier utilisé, Copyright des données pour les utiliser et les diffuser, Échelle de production des données, Format attendu, on privilégiera les formats MIF-MID, DWG, SHP ou DXF binaire. Le client sauvegarde les données brutes, puis les «charge» dans son SIG pour les mettre au format et au système de projection souhaité. Éventuellement, il les catalogue, puis les exploite et/ou les mets à disposition des utilisateurs en rappelant les règles d utilisation. Recommandations pour le long terme Les données qui ne sont pas localisées en PR+abscisse, mais en X-Y, par exemple une aire de repos située à proximité de la route ou un abri bus, doivent être structurées de manière à être rattachées à la route porteuse. Toutes les données géographiques devront pouvoir être transposées dans le système PR+abscisse ou distances cumulées, par projection sur le référentiel. Toutes les données géocodées, localisées en PR+abscisse devront pouvoir être transposées en X-Y. Une sensibilisation des acteurs routiers est à organiser sur les systèmes de projection et sur les conditions dans lesquelles les données routières (référentiel y compris) peuvent être intégrées dans les progiciels SIG. CETE Méditerranée - Département de l informatique / service ETER 16/39

17 7) Conservation de données en vue de leur réutilisation ultérieure ( I ) Objet Illustration Description de la situation d échange Un ensemble de données routières a été produit par un service de gestion de la route et il est susceptible d être utilisé ultérieurement soit par le service lui-même, soit par d autres services ou d autres partenaires. Il est donc nécessaire d en assurer le stockage de manière à faciliter la réutilisation de ces données. Cette préoccupation peut se rencontrer aussi bien dans un service gestionnaire que dans un organisme central tel que le SETRA. 1 er échange : remise du lot de données à l administrateur de données de de données RD Lot de données brut Administrateur de de données L analyse de l évolution de l état des chaussées nécessite de comparer les dégradations relevées tous les ans et stockées dans l entrepôt de données. Autres exemples : évolution des trafics ou des accidents. 2ème échange : recherche et récupération d un lot de données Lot de données diffusées Difficultés Exploitation Le fournisseur, en l occurrence un gestionnaire de réseau routier, remet le lot de données brut à l administrateur de données du service. Ce dernier transforme éventuellement le lot (ex. : changement de format ou de mode de localisation), le stocke dans l entrepôt de données et organise sa mise à disposition. Le client (par exemple, un chargé d étude de DDE) recherche dans le catalogue de l entrepôt, le lot qui l intéresse. Lorsqu il l a identifié, il le récupère selon une procédure qui dépend du degré d automatisation de l entrepôt (demande à l administrateur ou au producteur du lot, téléchargement ). Le lot de données brut est le lot tel que le fournisseur l a produit. Le lot de données diffusé résulte de transformations du lot de données brut par l administrateur de manière à en faciliter la réutilisation par le client. Le client peut intégrer le lot dans son système d information. Il peut également l utiliser pour réaliser une étude de l évolution dans le temps d un phénomène. Le recalage du lot sur le référentiel d exploitation devra dans de nombreux cas être envisagé. La réutilisation des données routières peut présenter plusieurs difficultés telles que : Le choix des données qui composeront le lot. Comment connaître à l avance les données qui seront demandées dans plusieurs années? Faut-il réaliser au départ certains traitements pour en faciliter la réutilisation? Le manque de clarté dans la description du lot. Ceci peut amener le client à sélectionner des lots qui en fait ne l intéressent pas ou, plus grave, à utiliser des données qui ne sont pas valides pour l utilisation envisagée, La nécessité, pour le client, de disposer d un référentiel très précis alors que l utilisation prévue ne l impose pas. C est le cas, par exemple, de données localisées uniquement en PR+abscisse et dont le client ne souhaite finalement qu une visualisation cartographique, Le choix du format de stockage du lot. L évolution des logiciels et des formats ne garantit pas toujours la possibilité de relire un lot produit plusieurs années auparavant. Le lot de données contient les dégradations recueillies et localisées en PR+abscisse. Le chargé d étude doit rendre les données compatibles entre elles en fonction des traitements qu il envisage. CETE Méditerranée - Département de l informatique / service ETER 17/39

18 Solutions recommandées Solutions actuelles Recommandations pour le long terme Il est recommandé à chaque organisme d administrer les données qu il produit et plus généralement les données qu il possède, y compris les référentiels de localisation. Cela revient à : Cataloguer les lots de données. Tout lot de données routières administré (et donc échangé) doit être décrit précisément et ses limites d usage doivent être explicitées. L application Reports permet de réaliser ce catalogage, Accompagner chaque lot de données des éléments nécessaires à sa mise en œuvre. Cela concerne la spécification des données (leur description), les lexiques (les valeurs prises par les attributs) et leur localisation (les référentiels). Il est conseillé d utiliser, chaque fois qu il en existe, les spécifications et les lexiques définis au plan national, Minimiser les contraintes d exploitation des données administrées. Le choix du mode de localisation au sein d un lot de données a des conséquences pour l exploitation de ce lot. Ainsi, le mode de localisation linéaire (PR+abscisse) peut être pratique pour des traitements linéaires (ex. : calcul de distance entre deux objets routiers sur une même route). En revanche, pour une visualisation cartographique, ce mode ne permettra pas de visualiser directement les objets sur une carte, les objets devant être au préalable géocodés. Pour éviter au client d alourdir ses traitements avec un référentiel de localisation, il convient dans la plupart des cas de lui proposer des lots utilisant le mode de localisation géographique, Organiser et stocker les lots de données dans un entrepôt local. Il est conseillé d informatiser sur un serveur local le stockage des lots de données, Assurer la mise à disposition des lots de données auprès des populations concernées. Cette mise à disposition peut être partiellement ou totalement automatisée. La mise en ligne du catalogue des lots peut être assurée par l application Reports. Des progrès devraient intervenir sur plusieurs plans : Normalisation des données. Les besoins d échange entre les différents acteurs du domaine routier devraient conduire à la mise au point de spécifications et de lexiques communs, ce qui devrait permettre d alléger la gestion d un entrepôt de données, Maîtrise des problèmes liés à la localisation. L amélioration des référentiels de localisation prenant en compte leur évolution dans le temps devrait conduire à simplifier les méthodes de recalage des données. En particulier, la mise en œuvre des logiciels d analyse devrait être assouplie vis-à-vis de ces problèmes, Consolidation des outils d administration et d échange des lots de données. Les solutions logicielles de gestion d un entrepôt de données, d échange entre entrepôts et de mise à disposition de données sont en pleine évolution et devraient faciliter la tâche des administrateurs de données. Si l analyse des dégradations consiste simplement à comparer les linéaires de chaussées dégradées pour les différentes années, alors le mode de localisation à privilégier pour le stockage dans l entrepôt est le PR+abscisse, l abscisse cumulée ou plus simplement la longueur des portions de routes dégradées. Si, au contraire, l analyse est cartographique, le mode géographique (X-Y) devra être préféré pour le stockage dans l entrepôt. Dans les deux cas, le recalage sur une même version du référentiel de localisation peut s avérer nécessaire. Il est également important que le codage des dégradations soit stable au fil des années ou que l on puisse passer d un codage à un autre selon des règles simples : s de codages différents d un attribut «gravité de la dégradation» : en 1995, trois valeurs : faible, moyen, fort en 2000,cinq valeurs : 0, 1, 2, 3 et 4 Si les règles de correspondance entre les deux codages ne sont pas définies, il sera impossible de comparer les données. CETE Méditerranée - Département de l informatique / service ETER 18/39

19 8) Transfert de données SICRE à un Conseil Général ( E ) Description de la situation d échange Objet La DDE doit fournir au Conseil Général les données SICRE de certaines routes nationales. A l occasion d un déclassement, les données relatives aux routes déclassées sont nécessaires au Conseil Général. Illustration SICRE Le service de gestion des routes nationales de la DDE est le fournisseur des données. Le service de gestion des routes du Conseil Général est le client de l échange. Les données à transmettre sont à définir entre les deux parties. Elles concernent à minima : Les données du noyau dur, Les éléments de référentiel. En fonction des besoins du Conseil Général, elles peuvent comprendre également les rubriques optionnelles du SICRE et les rubriques libres. Les données sont fournies par la DDE dans les formats proposés par les applications de la gamme Visage (.PRA et CSV) et dans le format du RIU. Les données à transmettre sont : Dossiers d identification des 5 dernières années, Rubriques du noyau dur, Rubriques optionnelles, Autres données : accidents, trafic, ouvrages d art, dégradations des chaussées et notes IQRN. Exploitation Difficultés Il revient au Conseil Général d intégrer ces données dans ses applications. Deux cas d utilisation de ces données sont possibles : Le Conseil Général veut intégrer ces données dans sa base de données routière départementale en vue d un traitement homogène avec les données départementales, Le Conseil Général veut simplement intégrer dans certaines de ses applications les données du réseau national en tant que données d environnement. Il n y a pas forcément une homogénéité de description entre les données de SICRE et celles de la base des routes départementales. Un travail d homogénéisation peut être alors à envisager. De la même façon, l intégration des éléments de référentiel peut présenter des difficultés liées à des différences de modélisation ou de règles d identification des routes. Intégration dans l application Visage ou dans un progiciel du marché. CETE Méditerranée - Département de l informatique / service ETER 19/39

20 Solutions recommandées Solutions actuelles Recommandations pour le long terme La concertation définissant les caractéristiques de l échange doit être extrêmement précise. Selon le cas d utilisation des données, les solutions seront sensiblement différentes. Le respect de la nomenclature SICRE (pour le noyau dur au moins) facilitera l intégration des données. L intégration du référentiel pourra se faire simplement si les deux partenaires utilisent tous les deux l application Visage. Dans les autres cas de figure, les modalités de cette intégration seront à définir au cas par cas. Homogénéiser les descriptions des données. Promotion du catalogue SICRE, Mettre au point un protocole d échange des éléments du référentiel de façon à en faciliter l intégration dans le référentiel RD, Utiliser les formats les plus standards pour échanger les données de SICRE. Vérifier l homogénéité des référentiels pour pouvoir intégrer les routes déclassées dans le référentiel des routes départementales. Utilisation du format FEOR. CETE Méditerranée - Département de l informatique / service ETER 20/39

21 9) Publication de cartes interactives sur Internet/Intranet ( I ) Description de la situation d échange Objet Il s agit de publier des cartes interactives sur un site Internet ou sur un site Intranet. Une carte interactive est une carte publiée sur Internet/Intranet sur laquelle des informations supplémentaires à l affichage initial peuvent être obtenus sur un objet routier au passage de la souris. Par exemple, lorsque la souris désigne le tracé d une route, le nom de cette route peut apparaître dans une info bulle. Cette façon de faire évite de saturer la carte avec des informations qui ne sont pas toujours utiles. Le Sétra veut mettre à disposition une carte des trafics sur internet. Illustration Carte interactive Le service qui a réalisé une carte et qui la met à disposition d'utilisateurs divers. Le Sétra Le client est un utilisateur qui consulte son micro-ordinateur avec un navigateur Internet La carte interactive comprend des données attributaires ainsi qu'une localisation X-Y. Toute autre localisation serait attributaire (par exemple, les PR peuvent être ajoutés comme attributs). En option : récupération des données et du référentiel par téléchargement du fichier ayant servi à faire la carte Une Société de transports, par exemple, peut vouloir connaître les trafics dans sa zone d'action. Un chargé d'études ou un décideur veut consulter une carte routière. Trafic tous véhicules, trafics poids lourds, représentés sur une carte de France des routes nationales et autoroutes Exploitation Difficultés Consultation et interrogation de la carte. Problèmes d'échelle : choix et rendu chez le client. Temps de préparation de la carte : mise au bon format, formatage des champs en vue de l'affichage sur la carte. Récupération des trafics sur un itinéraire particulier. CETE Méditerranée - Département de l informatique / service ETER 21/39

22 Solutions recommandées Solutions actuelles Les solutions à mettre en œuvre ne sont pas spécifiquement routières. Chaque organisme utilise des outils géomatiques plus ou moins performants pour publier des cartes. La publication de cartes statiques (sans affichage d informations supplémentaires) se fait avec des solutions simples, par exemple en utilisant le format PDF d Adobe. La publication de cartes interactives fait appel à des solutions plus élaborées s appuyant sur des progiciels commerciaux (éditeurs SIG) ou sur des produits libres. Recommandations pour le long terme Pour éviter un travail récurrent de la part du producteur, les cartes pourront s'appuyer sur des modèles prédéfinis. Au sein du ministère de l Équipement, la publication des cartes interactives s appuiera sur des solutions respectant les protocoles OpenGIS et ISO en matières d'échanges de données géographiques pour permettre une interopérabilité. Pour que le client puisse travailler les données, il convient de proposer en téléchargement un format courant ou facilement convertible. CETE Méditerranée - Département de l informatique / service ETER 22/39

23 10a) Géocodage linéaire de données ( I ) Description de la situation d échange Objet Le géocodage de données routières (ponctuelles ou linéaires) consiste à calculer, à l aide du référentiel de localisation, les coordonnées géographiques à partir de la localisation en PR+abscisse. Ces données peuvent être latéralisées sur la carte par rapport au sens du bornage de la route. Dans le cadre d une étude phytosanitaire, on souhaite représenter (par espèce) sur une carte, les arbres localisés ponctuellement en PR + abs. Illustration localisées en PR +abscisse géocodées (XY) Service de de géocodage Le fournisseur est souvent un technicien (interne ou externe) capable de réaliser le géocodage à la demande du client. Le client est un gestionnaire de réseau routier ou un chargé d étude Technicien de la cellule de gestion des routes. Chargé d étude Intégration Difficultés Le lot de données source est un fichier comprenant les données dont les extrémités (une pour un objet ponctuel et deux pour un objet linéaire) sont localisées dans le système PR+abscisse ou en distances cumulées. Le lot de données résultat comprend les localisations géographiques des objets. Il peut être accompagné d une représentation cartographique. Un compte rendu du géocodage précise les objets qui n ont pu être géocodés. Les données à géocoder doivent être formatées conformément au logiciel de géocodage. Le référentiel en vigueur est utilisé pour géocoder. Les difficultés sont liées : Aux incohérences entre la localisation en PR+abscisse des objets et le référentiel, À l utilisation d un référentiel périmé, Au formatage des données. Le tableau localisant les arbres ponctuellement en PR+abscisse est fourni sous Excel par le gestionnaire de la base. Les arbres sont géocodés avec Vsmap, sous Mapinfo, en utilisant un RIU. Un code «Droit ou Gauche» permettra de latéraliser la représentation des arbres sur la carte. CETE Méditerranée - Département de l informatique / service ETER 23/39

24 Solutions recommandées Solutions actuelles La saisie des événements sur les routes doit être faite en s appuyant sur le référentiel afin de donner les noms des routes justes et des localisations cohérentes. Nota : La latéralisation sur la carte des données relevées ponctuellement, peut entraîner - en fonction du logiciel utilisé - un traitement particulier pour obtenir une représentation latéralisée (cas de Vsmap). La saisie sur le terrain des arbres doit être préparée en bureau afin de s appuyer sur le référentiel en vigueur. Cette méthode permet d éviter les erreurs de : numéro de route, de PR, et de distance inter-pr. Un arbre saisi au PR m impose que la distance inter-pr entre le 5 et le 6 soit égale ou supérieure à 1001 m Recommandations pour le long terme Permettre que les logiciels de géocodage produisent une analyse de cohérence des données à géocoder avec le référentiel. Cette analyse peut être préalable au géocodage ou postérieure, mais elle doit toujours assurer la production de messages clairs indiquant le nombre de rejets et leurs causes. Ces messages peuvent éventuellement être mis à profit pour mettre à jour le référentiel. Généralisation du service en ligne avec le Robot de Géocodage Routier (RoGeR) hébergé au Sétra. CETE Méditerranée - Département de l informatique / service ETER 24/39

25 10b) Accès à un service en ligne de géocodage ( I ) Description de la situation d échange Objet Un utilisateur dispose de données localisées sur la route en PR+abscisse, et il désire en faire une carte (X-Y). Il se connecte alors à un robot de géocodage, auquel il envoie ses données à géocoder. Ce dernier lui retourne ses données géocodées. RoGeR : Robot de Géocodage Routier hébergé au Sétra. Illustration localisées en PR +abscisse géocodées (XY) Service de de géocodage Le fournisseur est le centre serveur où est hébergé le service de géocodage. Le fournisseur possède un référentiel de localisation géographique faisant le lien entre les données PR et les données X-Y. Le client est un utilisateur quelconque disposant d'un accès au robot de géocodage. Centre serveur du Sétra Un utilisateur quelconque ayant accès au réseau i² du ministère de l Équipement. Exploitation Difficultés localisées en PR : ce sont les données que possède l'utilisateur, et qu'il souhaite positionner sur une carte. Pour cela, elles doivent au moins comprendre le localisant PR unique du référentiel permettant le géocodage. Référentiel du fournisseur : le robot de géocodage possède un référentiel qui fait le lien entre plusieurs systèmes de localisation (identifiant de la route, bornage, géométrie ). géocodées : une fois que le robot a traité les données, celles-ci sont retournées vers le client, sous la forme d'un fichier SIG, comprenant les éléments envoyés par le client, ainsi que la géométrie. Les données récupérées sous un logiciel SIG, peuvent être utilisées comme n'importe quelle table SIG (analyse spatiale ou thématique par exemple). Les données doivent être fournies par le client au bon format. De plus, les données doivent être localisées en PR sur la même année que le référentiel utilisé par le robot de géocodage. Les modifications de référentiels sont une source d'erreurs de géocodages (ce qui est d'autant plus gênant que parfois, le géocodage se fait, mais au mauvais endroit). Pour le géocodage sur RRN du Sétra, le localisant PR est défini par : Numéro du département, Nom de la route, PR de début de section, Abscisse de début de section, PR de fin de section, Abscisse de fin de section, Code de concession. Ces données doivent être envoyées au format XLS (le format FEOR sera intégré ultérieurement). Le robot de géocodage du Sétra propose également un habillage (RRN, grandes villes, etc.). Il faut, pour le robot de géocodage du Sétra, savoir si la route est concédée ou non, alors que dans la majorité des cas, il n'y a pas de risque de confusion sans cette information. CETE Méditerranée - Département de l informatique / service ETER 25/39

26 Solutions recommandées Solutions actuelles Pour le format : permettre différents formats de données. Au sens informatique : xls, txt, etc, mais aussi au sens sémantique pour les noms des éléments d'identification. Pour les sections ne rentrant pas exactement dans le référentiel du fournisseur, une correction automatique (dans certaines limites prédéfinies) est possible. Une route pourra s'appeler N1 ou N0001 ou RN1. Correction de l'abscisse du fichier à géocoder si elle dépasse la distance inter-pr. Correction du code de concession si une section du type concédé (resp. non concédé) n'existe pas dans le référentiel alors que la même section existe mais de type non concédé (resp. concédé) Recommandations pour le long terme Utilisation d'un format d'échange standard. Dater les données et donner des limites de validité aux sections. Utilisation du FEOR CETE Méditerranée - Département de l informatique / service ETER 26/39