MASTER SIG ET GESTION DE L ESPACE

Transcription

1 Université Jean Monnet 06 rue Basse des Rives SAINT-ETIENNE Ecole Nationale d Ingénieurs de Saint-Etienne 58 rue Jean Parot SAINT-ETIENNE MASTER SIG ET GESTION DE L ESPACE Imberdis Laetitia : Rapport de stage Participation à la réalisation d un projet SIG : Mise en place et paramétrage d une nouvelle application métier dédiée à la gestion d un réseau routier Structure d accueil du stage : Poste de Commandement et de Circulation - cellule SIG Direction des Routes Conseil Général de l Isère 9 rue Jean Bocq GRENOBLE Durée du stage : 06 mars août 2006 Responsable du stage : M. O. Latouille Soutenance : 13 septembre 2006 Lieu : Salle de réunion du CRENAM Université Jean Monnet Master SIG et Gestion de l Espace - Année universitaire Parcours professionnel

2 REMERCIEMENTS Je remercie le service PCC/SIG et la Direction des routes du Conseil général de l Isère pour m avoir donné l occasion de participer à un projet SIG ainsi que l ensemble des personnes qui m ont aidée au cours de ce stage et pour la réalisation de ce rapport, et plus particulièrement M. Olivier Latouille et Robert Seignemartin du service PCC-SIG, Mme Andrée Buisson et M. Didier Gonzales de la Direction des Systèmes d Information, ainsi que l Equipe Geomap.

3 SOMMAIRE Int roduc tion p.5 Partie 1 : Environnement du stage Le Conseil Général de l Isère p.6 Historique d un Conseil général p.6 Fonc tionnement du Conseil général p.6 Ses compétences p.6 Organisation de l administration dépar tementale p.7 Quelques chif fres p.7 La gestion des routes au niveau départemental p.8 La Direc tion des routes p.8 Le ser vice PCC/SIG p.8 Le réseau routier dépar temental p.10 La banque de donné es routières p.12 Composition de la BDR p.12 Solution logicielle et organisationnelle ac tuelle p.16 Partie 2 : Phase préalable à la mise en oeuvre du projet Phase de définition p.17 Analyse de l existant et définition des besoins p.17 Définition des objec tifs généraux et attentes p.18 Les objectifs principaux Les sous-objectifs Les objec tifs humains p.20 Les enjeux p.20 Définition et prise en compte des contraintes p.20 Instances nécessaires à la conduite de projet p.21 Phase préparatoire à la mise en oeuvre p.22 Le choix de la solution logicielle p.22 L étude technique détaillée p.23 Les besoins en ressources p.24 Phase de planification et stratégie de mise en oeuvre p.25 Planification p.25 Stratégie de mise en œuvre p.26 3

4 Partie 3 : Phase de mise en œuvre P hase d instal lation : Conception fonc tionnel l e p.27 Les briques logicielles p.27 Oracle Locator 10g MapInfo Geomap GIS Routes Autodesk MapGuide Réseaux nécessaires Architec ture fonc tionnelle p.31 Décomposition des briques Installation logicielle Phase de reprise de données p.33 Les données à reprendre p.33 Réalisation du MPD p.33 Méthodologie de reprise p.34 Format géométrique de la nouvelle BDR p.35 Phase de verification d aptitudes p.38 Vérification de la reprise des données p.38 Vérification des fonc tionnalités p.39 P hase de paramét rage p.40 Paramétrage de l inter face p.40 Organisation Possibilités de paramétrage de la base de données Administration de la BDR p.42 Listing des utilisateurs Outils de gestion des droits Attribution des droits Phase opérationnelle : déploiement et perspective p.45 Conc lusion p.46 Bibliog raphie p.47 Annexes p.48 4

5 Développés pour la gestion de l information spatialisée, les Systèmes d Information Géographique en tant qu outils logiciels doivent permettre de traiter tous types de données spatiales de quelque nature qu elles soient. La diversité de leurs thématiques d application est une des preuves de leur acclimatation. Cependant, cette capacité de traitement de l information spatialisée en générale, si elle est un atout pour le développement des SIG constitue parfois un frein par manque d adaptation et de pertinences face aux spécificités de certaines thématiques d application. En ce sens, la gestion d un réseau routier constitue un domaine particulier d application des SIG pour lequel les possibilités de gestion et d exploitation de l information basées sur une modélisation du réseau n apportent pas une réponse complète face aux attentes et exigences des professionnels. De plus, à l heure de la communication et de la diffusion de l information parallèlement au développement des Nouvelles Technologies de l Information et de la Communication, les Systèmes d Information en général prennent une dimension organisationnelle et structurante importante dans le partage des données en plus de leur rôle de gestion et d exploitation. Ces deux dimensions justifient d autant plus leurs utilisations dans les collectivités locales dans une phase de décentralisation et de modernisation des administrations territoriales. Dans ce contexte, le service Poste de Commandement-Circulation du Conseil général de l Isère en charge du Système d Information Géographique dédié aux routes a décidé de revoir son Système d information Routier afin d optimiser son rôle au sein de la collectivité. D une application monobrique logicielle standard, il s oriente vers une installation plus complexe basée sur l ajout d une couche «application métier Routes» : Geomap GIS Routes, tout en intégrant l utilisation d un Système de Gestion de Bases de Données. Cette architecture logicielle devra permettre de répondre aux attentes fonctionnelles particulières à la gestion d un réseau linéaire routier, tout en intégrant les nouvelles technologies telles que les technologies Web afin d apporter une solution en terme de partage et de communication de l information. Cette refonte des outils logiciels ainsi que de l ensemble du Système d Information Routier est donc réalisée sous forme d une conduite de projet SIG. Mon intervention dans le cadre du Master SIG et Gestion de l Espace se place dans le déroulement de ce projet SIG, au sein du service Poste de Commandement-Circulation. Pour profiter pleinement de cette expérience et bien que ma participation dans le projet se centre essentiellement sur la partie mise en oeuvre, il m a semblé nécessaire de revenir sur les étapes précédentes afin de mieux cerner le contexte de déroulement du projet, ses enjeux, et d avoir une première vision globale du déroulement d un projet SIG dans le cadre de cette première expérience professionnelle. Ce rapport présente l intégralité du projet selon une méthodologie de conduite de projet SIG. Après avoir présenté le contexte de déroulement du stage et à partir duquel démarre le projet, une partie reprendra la phase de définition du projet, puis sa phase de mise en oeuvre. 5

6 Environnement et contexte du stage Le Conseil général de l Isère Historique d un Conseil général Créés à la fin du XIIIème siècle, les départements français sont avant tout des circonscriptions administratives placées sous l autorité du Préfet, représentant direct du chef de l Etat. En tant que Collectivité Locale, chaque département est régit par un Conseil général, lequel constitue l assemblée délibérante du département. Les Conseils Généraux ont pris leur véritable place au sein de l organisation administrative en France depuis 1982, année de l Acte I de la décentralisation amené par les Lois Defferre. En 2004, sous le gouvernement Raffarin fut arrêté l Acte II de la décentralisation qui accroît encore les compétences des départements sur leur territoire. Fonc tionnement du Conseil général Le Conseil général s articule autour de 2 organes principaux : 1.l organe exécutif, composé : - du président du Conseil général, - des vice-présidents, - des conseillés généraux délégués. 2.l organe délibérant comprenant : - l assemblée départementale composée des conseillers généraux (un par canton) : elle définit les politiques et actions à mettre en œuvre, vote le budget - la commission permanente : elle assiste et seconde l assemblée départementale, notamment dans les domaines d actions pour lesquels l assemblée départementale lui a délégué ses compétences. - les commissions thématiques ; 13 en Isère, composées de conseillers généraux : rôle d expertise en amont de l assemblée délibérante et de la commission départementale. Ses compétences L acte I de la décentralisation transfère un certain nombre de compétences de l État vers les départements, leur donnant ainsi un véritable pouvoir de décision. La «loi du 13 août 2004 relative aux libertés et responsabilités locales» dit «Acte II de la décentralisation» renforce les compétences des conseils généraux : - voirie : transfert d une partie des routes nationales; - transport : organisation des transports scolaires, - action sociale : aide aux personnes âgées et aux jeunes, financement du R.M.I., mise en oeuvre de la loi Handicap; - logement : gestion du fonds de solidarité pour le logement et du fonds d aide à l énergie; - éducation : recrutement et gestion des personnels techniques, ouvriers et de services (ATOS), gestion et entretien des collèges ; - culture : transferts de certains domaines patrimoniaux. Environnement et contexte du stage 6

7 Parallèlement au transfert de compétences et de subventions, le Conseil général intègre au sein de ses services une partie des agents déconcentrés de l Etat D autre part, afin d assurer les nouvelles missions qui lui sont confiées, c est l organisation territoriale du département qui est refondée : ainsi, aux 24 subdivisions iséroises se substituent les 13 nouveaux «Territoires de l Isère», recentrés sur 13 «Maisons du Département». Organisation de l administration dépar tementale Au-delà de l organisation spécifique à chaque majorité départementale, c est l administration départementale placée sous la responsabilité du Directeur Général des Services, qui est chargée de mettre en œuvre les politiques et actions décidées par la majorité départementale. L administration départementale se structure autour de 3 types de Directions au sein desquels travaillent les agents départementaux :. Les Directions centrales opérationnelles : routes, transport, aménagement du territoire,.... Les Directions centrales fonctionnelles : Direction des systèmes d information, ressources humaines,... Chaque Direction s organise en plusieurs services.. Les Directions Territoriales regroupant les agents départementaux de chaque «nouveau Territoire». Chaque Direction territoriale comprend au minimum trois services : A l intérieur même de son territoire, chaque Direction dispose d antennes territoriales dont chacune comporte un centre médico-social, un centre d entretien routier et une équipe de gestion des collèges. Quelques chif fres Le département de l Isère Le département de l Isère est constitué de : 3 arrondissements 58 cantons 533 communes Superficie : km² (10ème rang national) Population : 1,1 millions d habitants Conseil Général de l Isère Budget du Conseil général : 1,2 milliards d euros pour l année 2006 Répartition des agents départementaux Nombre d agents : près de 3000 agents auxquels vont s ajouter quelques 1500 nouveaux agents issus de la décentralisation filière culturelle Repartition des agents départementaux >> filière technique filière admlinistrative filière sociale Environnement et contexte du stage 7

8 La gestion des routes au niveau départemental SI Routier - CG38 Le stage s est déroulé au sein du service Poste de Commandement et de Circulation (PCC) de la Direction des Routes. La Direction des routes La Direction des routes fait partie des directions centrales opérationnelles du Conseil général (CG). Elle a pour missions l entretien, la viabilité et l amélioration du réseau routier départemental. Elle se divise en 7 services : - service poste de commandement et de circulation : service PCC/SIG qui forme également la cellule SIG de la Direction, - service des grands projets, - service entretien routier, - service maîtrise d ouvrage, - service maîtrise d œuvre, - service expertise, - pôle ressources «routes». Le ser vice PCC/SIG La principale mission du service est d assurer la gestion de la circulation sur le réseau départemental : - gestion du trafic et maintien de la viabilité, - mise en oeuvre d un nouveau poste de commandement et d information des usagers de la route, - mise en oeuvre de nouveaux équipements de recueil d information et de communication auprès des usagers ; Au delà de sa mission de gestion de circulation, le PCC doit assurer en interne : - la mise en œuvre de l application routière SIG, - la gestion de la base de données routières, - la production de documents cartographiques, - l interopérabilité avec le SIG départemental ; Le service PCC correspond à la cellule SIG de la Direction des routes. Il est chargé de la gestion de la Banque de Données Routières (BDR) : - mise à jour régulière de la BDR par des informations récentes ramenées du terrain ou des divers acteurs concernés, - mise en cohérence des informations relatives à l ensemble du réseau routier sur l ensemble de la BDR, - réalisations cartographiques nécessaires à l ensemble de la Direction, - mise à disposition des informations de la BDR, Il travaille notamment en partenariat avec le service entretien routier de la Direction des routes, lequel a pour mission : - la définition de la politique routière (chaussées, assainissement de plate-forme, équipements de la route, entretien des dépendances, viabilité hivernale, surveillance du réseau, pistes cyclables) Environnement et contexte du stage 8

9 - le suivi du programme d acquisition du matériel Parc - la programmation annuelle des travaux d entretien - la gestion du domaine public (instruction des autorisations de voirie, classement/ déclassement) - la gestion des saisonniers de viabilité hivernale. Depuis 2004, le service a reçu comme compétence la gestion du trafic. Actuellement, cette dernière est déléguée au CIGT38 : Centre d Ingénierie et de Gestion du Trafic de la DDE de l Isère. Ce n est qu une fois la restructuration du CG38 effectuée avec l intégration des nouveaux agents que cette compétence sera réalisée en interne. Composition actuelle du service PCC : - un chef de service ingénieur territorial, - un technicien territorial. Evolution du service parallèlement à la restructuration du CG dans le cadre de l acte II de la décentralisation Dans le cadre du second volet de la décentralisation, le Conseil général doit prendre une partie des routes nationales (RN) à sa charge ainsi qu une partie des agents de la DDE, soit environ 500 agents qui se répartiront entre le site central du CG (dans les services et directions existantes qui seront réorganisées en conséquence) ou dans les services déconcentrés par la création des Maisons du Département qui remplaceront les anciennes subdivisions. Pour assurer la gestion du réseau routier, la Direction des routes ainsi que le service PCC placés en site central travailleront en collaboration avec les Maisons du Département. En tant que siège, la Direction des routes aura en charge de définir la politique routière et d assurer la maîtrise d oeuvre des grands projets, la gestion financière, les services d expertise relatifs à l exploitation et à la sécurité routière. Chaque territoire sera chargé d assurer entre autres : l entretien et la viabilité de son réseau, la maîtrise d oeuvre et la conduite d opérations à son niveau... Avec l intégration des nouveaux agents, l effectif du service PCC passera de 2 postes permanents à plus d une dizaine. Cette restructuration va de paire avec la mise en place d un nouveau système d information routier dédié à la gestion du trafic ainsi qu une gestion multimodale des déplacements. Ce projet s inscrit dans une transversalité totale entre tous les acteurs départementaux concernés par les déplacements : - la gendarmerie, - La DDE, - Le SDIS (Service Départemental d Incendie et de Secours), - La Ville de Grenoble, - La communauté d agglomération de Grenoble Métropole, - La Direction des transports du CG38 - La Direction des routes du CG38, L ensemble des exploitants des réseaux de l agglomération grenobloise seront regroupés au sein d un même bâtiment multiexploitant. L objectif est de mettre en place un système centralisé capable de réagir et d intervenir en temps réel sur l ensemble du trafic départemental. Cela nécessite de pouvoir récolter de l «information terrain» sur le trafic par divers systèmes (capteurs, stations de comptage, caméras), de pouvoir centraliser et traiter ces informations, et d agir en conséquence par des moyens Environnement et contexte du stage 9

10 matériels adéquats (panneaux à messages variables, radio infotrafic..) pour diriger les usagers de la route et des transports en commun afin d optimiser l utilisation des réseaux par de meilleurs flux. L accompagnement des usagers de la route pourra se faire en amont, pendant et après le voyage par l intermédiaire d un site internet ou d une centrale de mobilité. >> Nouvelle division territoriale administrative de l Isère Le réseau routier dépar temental Quelques chiffres : - environ 4600 km de voirie départementale nouveaux km supplémentaires dus aux routes nationales transférées A l image du département, le réseau routier se scinde en deux parties bien distinctes : - la moitié Nord-Ouest, avec un réseau plus maillé : longues routes de plaine qui irriguent tout le territoire avec de nombreuses intersections ; peu d espaces «vides», présence de grands axes traversant ; - la moitié Sud-Est : réseau non maillé contraint par la géographie alpine, beaucoup plus concentré dans des «couloirs» comme les vallées ; quelques grands axes qui reprennent la structure géographique du département (délimitation des massifs montagneux) : réseau de Montagne, accès aux stations de sport d hiver, itinéraires de transit vers le Sud de la France... Environnement et contexte du stage 10

11

12 La Banque de Donné es Routières Comme tout système d information géographique, le Système d Information Routier (SIR) du Conseil général se structure selon, trois composantes : - la composante humaine : des personnes pour l utilisation du système d information, autant en amont (préparation, paramétrage de la BDR), que pour son utilisation entant que «client», - La composante «logiciel» : le Conseil général de l Isère est équipé du logiciel SIG MapInfo, - La composante «données» : il s agit de la Banque de Données Routières décrite ci-après. Composition de la BDR La BDR se compose de deux types de bases bien distinctes : - d une part, la BDR actuelle héritée du «système traditionnel français» de gestion des données routières : la base VISAGE datant des années 90 ; - La «nouvelle base de données» élaborée en interne et fondée essentiellement sur la BD Carto provenant de l Institut de Géographie National : cette base a été achetée par le CG38. La base VISAGE Cette base a été développée pour les besoins des services de l Etat compétents dans la gestion routière tels que les DDE. Il s agit d une base de données alphanumériques au format DBASE fonctionnant sur une application MSDOS. Le «logiciel» VISAGE fait suite à une première version «SAGER» en y apportant une interface plus ergonomique ainsi que des fonctionnalités plus avancées : - visualisation de profils en long ou synoptiques, - module de réalisation cartographiques, - outil de gestion par la simulation d entretiens routiers : prise en compte de critères (budget, attributs sur l état de la route) ; La base se fonde sur une description de la localisation des événements en PR + abscisses : les PR ou Points de Repère correspondant aux bornes disposées le long des routes afin de bénéficier de points de repères fiables le long du tracé de chaque route. Cela permet d une part, d effectuer des calculs de longueurs en se basant sur les longueurs réelles inter-pr, et d autre part d améliorer la ROUTE PR Début Abscisse Abscisse Abscisses Abscisses PR Fin début fin cumulées début cumulées fin AGGLOMERATION N BOURGOIN JALLIEU N NIVOLAS VERMELLE N LA COMBE LES EPARRES N LE GRAND CHEMIN N BADINIERES N ECLOSE Environnement et contexte du stage 12

13 représentation graphique sous forme de synoptique. Une cinquantaine de rubriques relatives aux données routières est ainsi renseignée par des attributs portant sur une portion de route délimitée en PR + abscisses ou en abscisses cumulées. La base offre la possibilité d interroger et d effectuer des requêtes multicritères comme toute autre base alphanumérique. >> Extrait de synoptique issu de la base Visage-Sillage (source : CG38 - service PCC-SIG) Environnement et contexte du stage 13

14 Le nombre important de rubriques et l inutilité de certaines données n ont pas incitées à maintenir à jour la base dans son intégralité. Seules les rubriques les plus importantes au vu des besoins des agents chargés de l entretien des routes ont été et sont encore mises à jour régulièrement. D autre part, le manque de personnel formé à l utilisation de Visage et son interface peu attrayant font qu aujourd hui la base Visage n est consultable que depuis un seul poste en local. L utilitaire VSMAP développé autour du logiciel MapInfo permet de cartographier les données de la base VISAGE. La base format MapInfo Le Conseil général s est équipé du logiciel MapInfo depuis une dizaine d année environ. La BD Carto achetée à l IGN est une modélisation du réseau routier. On retrouve dans cette base les trois types d objets utilisés dans les SIG sont présents dans la BDR : objets de type linéaire, ponctuel ou surfacique. Les données de type linéaire sont essentiellement les données de structure du réseau routier : - les routes départementales, - routes nationales, - voies communales, - le réseau autoroutier, - les échangeurs. Chaque type de routes (départementales, nationales...) forme une table au format MapInfo ; les tables fondamentales (routes départementales, nationales et autoroutes) dans la modélisation du réseau possèdent quasiment la même structure attributaire, laquelle a été élaborée en complément de la base Visage. >> Extrait de la table de données attributaires issu de la table «RD38» : table MapInfo représentant le réseau routier départemental de l Isère. (source : CG38 - service PCC-SIG) Des données routières de type ponctuel : - les PR ou Points de Repère : provenant de Visage, ils ont été intégrés dans MapInfo, - localisation d évènements ponctuels tels que les ponts, tunnels ou autres «ouvrages d art», - localisation d entrées-sorties d agglomérations, - localisation d instruments de mesures, de surveillance et de gestion du réseau routier : Environnement et contexte du stage 14

15 station de comptage... Des données nécessaires à la gestion des routes, de type surfacique : - simulation d entretiens routiers : logiciel de gestion et d entretiens des routes dans le temps avec prise en compte de divers critères (budget, attributs sur l état de la route) - limites de compétences de brigades de gendarmerie,... Autres types de données : il s agit principalement de données d habillage de cartes : - données d occupation du sol : bâti, forêt, réseau hydrographique,... - données de relief : MNT, - BDORTHO, Scans de l IGN... Ces données sont partagées au sein du Conseil général. Le fond cartographique La Direction possède un fond cartographique relativement important réalisé sous le logiciel MapInfo au format de projet.wor. Ce fond contient : - des cartes génériques d informations sur le réseau routier départemental, à différentes échelles, et selon différents découpages administratifs (cantons, subdivisions, territoires ), cartes de localisation des équipements de gestion du réseau routier - des cartes thématiques destinées à des usages ou bien à des domaines de gestions bien particuliers : cartes de niveaux de services relatifs à la viabilité hivernale, cartes des circuits de déneigement, cartes de signalisation horizontale >> Extrait d une carte de gestion routière (source : CG38 - service PCC-SIG) Environnement et contexte du stage 15

16 Solution logicielle et organisationnelle ac tuelle Organisation des données et mises à disposition sur le réseau du CG L installation logicielle actuelle se base sur une architecture de type serveur de fichiers couplé avec l utilisation du logiciel MapInfo. Ainsi, la banque de données routières est simplement stockée sur le réseau du Conseil général. Ce réseau est partagé en différents «lecteurs» organisés selon des niveaux à l image des directions et services. La banque de données routières est donc mise à disposition de l ensemble de la Direction des routes. Sur le plan organisationnel, aucun outil dédié n est présent. Seule une structure organisationnelle pertinente en répertoires et dossiers des données garantit une accessibilité aisée aux données. Bien qu une organisation efficace ait été mise en place par stockage sur le réseau, ce système présente tout de même une faiblesse majeure : la réorganisation régulière des directions et services du Conseil général faisant suivre une réorganisation du réseau interne, les chemins de fichiers enregistrés dans les projets MapInfo par exemple sont faussés. Bilan et perspective La solution logicielle actuelle s est construite par ajout successif de modules (en terme de logiciels mais également de données), sans véritable homogénéisation des données notamment entre Visage et MapInfo. Son hétérogénéité en fait un outil lourd à gérer qui manque d efficacité opérationnelle et ne permet pas une mutualisation des données. Si l utilisation de cette solution est réelle au sein du PCC, sa pérennisation au niveau du service et de la Direction n est pas assurée. Environnement et contexte du stage 16

17 Phase préalable à la mise en œuvre du projet La Direction des routes du Conseil général de l Isère ambitionne de renouveler son système de gestion du réseau routier afin d optimiser son utilisation. La réussite d un projet SIG tient en grande partie dans la méthodologie de mise en place. La formalisation de ce projet passe par une phase préparatoire qui donne lieu à un diagnostic de l existant et à une formalisation des besoins et exigences d une nouvelle solution. Phase de définition Analyse de l existant et définition des besoins Pour préparer le lancement du projet concernant la BDR, une analyse de la solution actuelle a été réalisée faisant ressortir ses lacunes et ses points faibles. C est à partir de ce diagnostic qu ont pu être définies les attentes d une nouvelle solution et les contraintes de la solution actuelle. En effet, la mise en place de cette solution SIG vient s inscrire dans une plate-forme SIG préexistante qu il est nécessaire de prendre en compte. La BDR actuelle est un héritage de plusieurs bases de données hétérogènes, lesquelles n ont pas toutes été mises à jour régulièrement. Bien qu elle soit consultable par nombre d acteurs concernés, la gestion et l exploitation de la BDR actuelle, y compris la production de cartes ou de simples documents techniques informatifs sont essentiellement réalisées au sein du PCC/SIG. L abandon partiel de la banque de données actuelle et notamment du support logiciel VISAGE se justifie par divers arguments : - la technologie de support est dépassée : son évolution et sa pérennisation ne sont plus assurées (annonce des services de l Etat de l arrêt du développement et de l évolution de cette base), - opérations d intégrations, d interrogations et de visualisation des données fastidieuses par rapport aux technologies actuelles, interface peu ergonomique et attrayante, - difficulté quant à la compatibilité de cette base avec la base MapInfo, - impossibilité pour des acteurs externes d accéder à cette base, - peu de personnel formé à l utilisation de l application VISAGE. Phase préalable à la mise en oeuvre du projet 17

18 Définition des objec tifs généraux et attentes Les objectifs principaux Dans un contexte de décentralisation qui allie réorganisation des services internes au Conseil général par l arrivée de nouveaux agents, et réorganisation administrative à l échelle départementale, la Direction des routes représentée par le service PCC souhaite revoir la solution actuelle afin de mettre en place un nouveau Système d Information Routier (SIR) qui réponde de manière plus efficace aux besoins des agents en charge du réseau. La motivation à s équiper d une nouvelle application SIG s appuie également sur la perspective d évolution du service tant sur le plan organisationnel (nouveau personnel), que par rapport à ses compétences. L objectif se porte sur une solution complète comprenant des fonctionnalités poussées depuis l amont (facilité d installation, module de gestion, de paramétrage et d administration), vers l aval (fonctionnalités d application métier évoluées). La BDR intégrée dans cette nouvelle solution devra répondre complètement à leurs besoins, à savoir : - disposer d un fond de données de modélisation du réseau, - disposer de données attributaires nécessaires à l exploitation et à la gestion du réseau routier, ainsi que des documents et produits cartographiques déjà réalisés. Sur le plan technique, il apparaît nécessaire de se baser sur des technologies Web permettant des applications externes et du travail à distance. L emploi de ces technologies nouvellement développées dans les systèmes d information géographique doit permettre d assurer une «relative pérennisation et une évolution de la solution» parallèlement à l évolution du marché des SIG qui s appuient et se développent de plus en plus autour d Internet. En utilisant une nouvelle architecture logicielle et des supports technologiques en réseau adaptés à des applications Web, le PCC assure au SIR une meilleure diffusion et communication auprès des acteurs. De plus, ce type de solution implique de se baser sur des formats de données adaptés tels que le SVG (Scalable Vector Graphics) qui, si ils sont avalisés par l OGC1 assurent une interopérabilité des données. L emploi de tels formats a un double impact : - s affranchir du format propriétaire MapInfo qui restreint actuellement la diffusion et le partage des données entre les services du Conseil général, - possibilité de formaliser une norme d échange des données avec d autres partenaires. Les sous-objectifs La définition et la formalisation des attentes et objectifs selon les grands domaines fonctionnels sont nécessaires dans toute étude préalable à la mise en œuvre d un projet. Cette phase permet de mieux cibler et de faciliter le choix de la solution à adopter. Les attentes organisationnelles : La définition des attentes organisationnelles de la solution est indispensable à la réussite d un projet : elle permet de définir le rôle de l application SIG dans l ensemble du système d information. Objectifs organisationnels : - la solution SIG doit être fédératrice de l ensemble du SIR et de tous les acteurs concernés, - elle doit prévoir une gestion multi-utilisateurs en interne et à distance, avec possibilité d intervention sur la base à distance, Phase préalable à la mise en oeuvre du projet 18

19 - elle doit permettre une mutualisation des données afin de disposer d un seul référentiel routier unique pour tout le Conseil général, - un module organisationnel doit être intégré afin de pouvoir contrôler et gérer l accès multiutilisateurs ; Les attentes sur le plan technologique : En dehors des applications fonctionnelles attendues par l arrivée d un nouvel outil SIG, les aspects technologiques utilisés détiennent une grande part quant à la réussite à long terme du projet. L emploi de technologies déjà caduques ou non-évolutives peut figer et réduire ainsi considérablement la durée de vie de l application, empêchant son évolution parallèlement aux besoins des utilisateurs. Les objectifs technologiques : - architecture client/serveur avec possibilité de connexion multi-utilisateurs, - connexion et intervention à distance et déploiement possible dans des sites déconcentrés, - utilisation des technologies Web et connexion via l Intranet du Conseil général,... Les attentes fonctionnelles : En terme de fonctionnalités, la solution doit répondre aux besoins spécifiques au domaine d application concerné, c est-à-dire à la gestion du réseau routier. L expérience des deux bases de données utilisées jusqu alors au Conseil général ainsi que la connaissance de nouveaux produits du marché ont permis de mieux définir les besoins fonctionnels. Pour des raisons historiques, la gestion du domaine routier se base essentiellement sur une localisation par axe calculée en PR+abscisses ou abscisses cumulées, tel que le gère l application VISAGE. Pour des raisons pratiques, il apparaît évident que la gestion des rubriques attributaires puisse se faire en coordonnées curvilignes dans la continuation du logiciel VISAGE. En effet, ce système de coordonnées est employé quotidiennement par les acteurs en charge du réseau routier en dehors de toute application SIG, que ce soit par les agents internes au Conseil général, externes comme ceux de la DDE ou bien par les prestataires privés contractés pour des travaux d entretien routier. Pour des raisons historiques, techniques et humaines, il apparaît nécessaire de conserver ce système de coordonnées. Objectifs fonctionnels : - gestion des coordonnées curvilignes en PR+abscisses et gestion de coordonnées géographiques, - segmentation dynamique, - affichage sous forme de synoptique, - procédures de mise à jour simplifiées, - mise à jour possible depuis le synoptique, - gestion de rubriques linéaires et ponctuelles, - conception et calcul d itinéraires, - gestion des générations et de l historique, - contrôle de saisie par différentes interfaces ; Outre les fonctionnalités communes de l application logicielle accessibles depuis les postes clients distants, le Conseil général envisage également à plus long terme d équiper des clients nomades terminaux type PDA ou Pocket PC leur permettant ainsi de saisir des données directement sur le terrain. La solution logicielle devra donc intégrer cette possibilité. Phase préalable à la mise en oeuvre du projet 19

20 Les objec tifs humains Bien que les structures impliquées à terme par ce projet ne soient pas encore en place, une première liste des acteurs concernés a été établie afin d envisager le déploiement de l application en sites distants notamment. Une vingtaine d utilisateurs répartis en site central et sites distants : En site central : - le service PCC/SIG, - le service entretien, - le service expertise, En sites distants : - des clients dans chaque Maison du département du Conseil général. Les enjeux Le fondement du projet vise à mettre en place un outil de gestion du réseau routier départemental accessible et consultable par tous les agents concernés, que ce soit en interne au Conseil général ou en sites distants dans les Maisons du Département. Un premier enjeu de nature informationnel ressort de ce projet puisque la nouvelle banque de données routière devra permettre de ne conserver qu un seul référentiel routier entre le Conseil général et ses relais territoriaux ; ce graphe devra alors satisfaire l ensemble de ces acteurs en charge de l entretien du réseau routier notamment. En plus de la technologie informatique nécessaire à la mise en place d une telle application, l enjeu principal est de nature humaine : au-delà d une installation réussie, le projet pourra se révéler être un échec si chaque agent concerné ne s implique pas dans la gestion et mise à jour des données. Sans une participation et une intégration réussies de tout le personnel concerné, c est la dynamique du système d information qui sera alors «nulle», lui faisant ainsi perdre son rôle «fédérateur». Cet enjeu relève d une difficulté à la fois humaine et technique. La difficulté humaine peut s expliquer par le fait que ces derniers ne connaissent pas les technologies SIG et n ont jamais été impliqués dans la mise à jour d une base de données. Ce refus peut également relever de la complexité dans l utilisation de l outil. Cette difficulté devra être palliée par le fait que l outil mis à disposition sera adapté à des «nouveaux utilisateurs SIG» : interfaces ergonomiques, fonctionnalités relativement faciles et simples d utilisations. Définition et prise en compte des contraintes La prise en compte d une plate-forme SIG préexistante constitue une condition sine qua non à la réussite du projet : les expériences de méthodologie de conduite de projet montrent qu il est risqué de bouleverser totalement un environnement de travail, d autant plus qu un tel changement va généralement de paire avec une perte de données, de savoir-faire et d expériences. Ainsi, le contenu informationnel et notamment cartographique résultant de plusieurs années d exploitation de la base de données ne doit pas être mis de côté lors de l élaboration et de la mise en place du projet. La définition du projet devra donc prendre en compte : - des données hétérogènes présentes sous divers formats (MapInfo, Visage), - des documents cartographiques actuellement au format propriétaire MapInfo (.WOR), Phase préalable à la mise en oeuvre du projet 20

21 - un outil logiciel SIG existant et connu de certains agents de la Direction, - des solutions logicielles déjà en place au Conseil général et pouvant aisément être intégrées et réutilisées pour la nouvelle application routière : Oracle comme Système de Gestion de Bases de Données, et Autodesk MapGuide comme moteur cartographique pour la diffusion Intranet. La participation de la Direction des Systèmes d Information (DSI) va dans ce sens puisqu elle tient un rôle «normalisateur» dans le choix des architectures logicielles de projets informatiques, La prise en compte de ce contexte conditionne également la bonne conduite du projet puisqu elle permettra de respecter certains critères recommandés voire imposés par la collectivité locale : - critère d ordre économique : le Conseil général de l Isère est déjà équipé dans une solution logicielle SIG : le choix d un autre logiciel et l abandon de MapInfo au sein de la Direction des routes serait une solution coûteuse et se positionnerait à l encontre d une homogénéisation et d une transversalité du SIG général du Conseil général, - critère d ordre humain : il est préférable de ne pas refaire complètement l environnement de travail mais de reprendre l interface homme/machine déjà présent : MapInfo, - critère d ordre réglementaire : l acquisition d une nouvelle application logicielle doit respecter le Code des Marchés Publics : une procédure particulière «Marché à Procédure Adaptée (MAPA)» a du être déclenchée. Instances nécessaires à la conduite de projet La complexité du projet et la solution complète vers laquelle amène le résultat de la définition des objectifs nécessite un support ainsi qu une organisation matérielle et logicielle informatique poussés, dépassant le cadre des logiciels SIG. La DSI a donc été intégrée dans la conduite de projet afin d intervenir sur les aspects relatifs aux supports matériels et aux logiciels du projet. Une instance a été mise en place pour la conduite de projet : le comité de pilotage qui réunit un représentant de chaque partie concernée : le chef de projet utilisateur issu de la Direction des routes, le chef de projet informatique de la DSI ainsi que le chef de projet fournisseur représentant de la société en charge de l installation et de la fourniture de la solution. Pour le lancement de la procédure et de la mise en concurrence, un CCTP (Cahier des Clauses Techniques Particulières) a été rédigé par les chefs de projet du CG (Service PCC/SIG et DSI) afin de préciser les attentes du Conseil général et les critères auxquels devaient répondre les éventuelles solutions. Phase préalable à la mise en oeuvre du projet 21

22 Phase préparatoire à la mise en oeuvre Le choix de la solution logicielle Bien que plusieurs propositions aient été étudiées suite aux réponses de l appel d offre, le choix s est porté sur un progiciel proposant des applications métiers dédiées à la gestion de linéaire et plus particulièrement à la gestion des réseaux routiers : Geomap GIS Routes développé et distribué par la société Geomap : société de service informatique spécialisée dans le développement d outils métiers SIG. Geomap GIS Routes n est que la spécialité «métier Routes» de la suite logicielle Geomap GIS : système d information alliant des technologies «objet», architectures client/serveur et s appuyant sur des technologies Web. Ce module a principalement été développé autour de technologies informatiques et solutions logicielles reconnues comme Autodesk ou Oracle spatial. L application métier se superpose au logiciel MapInfo. Geomap GIS comprend également un module de paramétrage et d administration. De plus, elle intègre la gestion multi-utilisateurs par son fonctionnement en architecture client/ serveur. Ce progiciel apporte des fonctionnalités supplémentaires dans la gestion et la structuration des données ainsi que dans les fonctions d exploitations graphiques, mais ne dispose pas lui-même d un support de stockage de l information géocodée, ni d un SGBD ou d une interface pour le traitement et l exploitation des données graphiques. Le choix de la solution Geomap GIS repose sur : - une expérience reconnue chez de nombreux utilisateurs, et notamment du module route : l application : Geomap GIS Routes existe depuis plusieurs années sur le marché des SIG bien que fondé sur le logiciel Autodesk Map ; - réutilisation des briques logicielles existantes du Conseil général de l Isère : logiciel SIG de gestion des routes MapInfo, SGBD Oracle, Moteur cartographique Autodesk MapGuide, - la réponse en terme de fonctionnalités métiers et de possibilités de paramétrage : Geomap GIS Routes offre une certaine complémentarité répondant spécifiquement à la gestion du linéaire routier, mais également pour permettre son déploiement et son accessibilité via un réseau Intranet, - une technologie basée sur un fonctionnement Intranet/Extranet, - une gestion centralisée des données dans un SGBD reconnu : Oracle. Malgré ces avantages, l application Geomap GIS Routes sur support MapInfo est relativement jeune : elle ne bénéficie donc pas encore d une expérience reconnue. Phase préalable à la mise en oeuvre du projet 22

23 L étude technique détaillée Une fois la solution logicielle choisie, une étude technique plus détaillée peut être menée : elle permet de poser de manière plus précise les changements apportés par cette nouvelle application, que ce soit en terme d équipements technologiques et informatiques nécessaires, d architecture logicielle ou de fonctionnalités. La DSI en partenariat avec la société fournisseuse peut alors définir précisément l architecture logicielle future, en faisant état des lieux des briques déjà en place et des investissements nécessaires. D autre part, les contraintes d installation (supports et capacités informatiques requises pour l installation des divers composants : client Geomap, serveur Geomap, SGBD ) afin de faire ressortir les compatibilités entre les équipements du Conseil général et les nouveaux éléments logiciels à intégrer. Exemples de contraintes techniques et financières à intégrer dans lors de la mise en oeuvre du projet : - l application n est compatible qu avec Internet Explorer comme navigateur alors que le Conseil général de l Isère utilise le navigateur Mozilla, - le fonctionnement basé sur le SGBD Oracle nécessite l achat de licences supplémentaires pour les futurs utilisateurs. De plus, la documentation relative au produit en phase d acquisition permet de faire un état des lieux sur les réponses apportées par l application métier choisie en terme de fonctionnalités. Fonctionnalités proposées par le progiciel Geomap GIS Routes : 1 Gestion intégrale du réseau routier en coordonnées curvilignes (PR + abscisse) 2 Gestion des rubriques linéaires et ponctuelles 3 Gestion des latéralisations (fossés, accotements, assainissements ) 4 Gestion des générations et de l historique (couches de voiries superposées) 5 Mise à jour du graphe routier (tracé, classement ) 6 Segmentation dynamique : Cartographier dynamiquement des évènements en PR + Abscisses contenus dans la base de données ou provenant de fichiers externes (EXCEL). A chaque requête, le logiciel recalcule dynamiquement les positions des points et des lignes en fonction du graphe. A chaque modification du référentiel graphique, tous les objets sont automatiquement repositionnés. 7 Accès dynamique aux informations d un tronçon 8 Création d un synoptique sur une route ou un itinéraire : permet d afficher une vue schématique de tous les évènements d un axe ou d in itinéraire (voir exemple en annexe) 9 Mise à jour de la base de données à partir du synoptique 10 Liens avec des fichiers externes : tout objet doit pouvoir être associé à un fichier externe (photo, plan AutoCad, fichier texte ) tous les formats de fichier supportés devront être listés. 11 Possibilité de concevoir des itinéraires (circuits de déneigements, circuits de surveillance du réseau, itinéraires cyclables, ramassage scolaire ) Utilisation du SGBD Oracle Locator 10g : - Centralisation de toutes les données dans un seul véritable SGBD-R, - Gestion des images et des formats dédiés à l Intranet (XML) permettant un déploiement via Intranet et une interopérabilité des données. Phase préalable à la mise en oeuvre du projet 23

24 Les besoins en ressources La mise en œuvre d un projet nécessite des ressources particulières qu il convient de définir le plus tôt possible afin de les intégrer dans le budget prévisionnel ainsi que dans le calendrier de mise en oeuvre. 1.Le matériel informatique : Bien que les agents concernés soient déjà équipés de postes informatiques, il est préférable de s équiper d au moins un poste informatique dédié à l utilisation de Geomap, notamment pendant les premiers mois de mise en œuvre lesquels vont servir de test. D autre part, l architecture client serveur nécessite plusieurs serveurs informatiques : un pour la base de données notamment, un autre pour l installation du serveur Internet et du serveur cartographique. Certains de ces produits étant déjà installés au Conseil général, il n apparaît pas nécessaire a priori de s équiper dans de nouveaux matériels informatiques. De plus, étant donnée l importance de la structure telle qu une collectivité départementale, la Direction des systèmes d information dispose par avance de serveurs pouvant être mis à disposition des besoins des différents services. 2.Les données Les données sont celles déjà utilisées dans le SIR ; elles devront donc être reprises et transférées dans la nouvelle application. Leur intégration dans un nouveau système de gestion de base de données va donc nécessiter une migration des données du format Visage ou MapInfo au format Oracle. 3.Les ressources humaines La mise en œuvre d un projet comprend un important travail de préparation avant de pouvoir être réellement fonctionnel. La mise à disposition d un personnel adapté aux besoins du projet est un critère déterminant dans la réussite du projet. La mise en place d une nouvelle application nécessite un travail de reprise et de préparation à la fois des données et de la couche logicielle qui servira d interface aux utilisateurs. Si les ressources en personnel sont insuffisantes, c est le calendrier ou la qualité du système d information qui risque de s en faire ressentir. 4.Les équipements Le déploiement prévu pour le Système d Information Routier se base notamment sur un fonctionnement via Intranet : il s appuie donc sur des technologies dont le département de l Isère est déjà équipé permettant la connexion au réseau Intranet : technologie Numérique, ADSL ou fibre optique. L application devra pouvoir être déployée par l utilisation de ces multiples supports de connexion afin de pouvoir se connecter au relais les plus éloignés lesquels ne sont pas tous équipés en technologies haut-débit type ADSL. Au moment de l élaboration du CCTP, tous les sites distants n étaient pas encore opérationnels notamment les «nouveaux relais territoriaux» ; il était alors impossible de connaître le type de connexion utilisé par ces structures. Phase préalable à la mise en oeuvre du projet 24

25 Phase de planification et stratégie de mise en oeuvre Planification La phase de planification doit intégrer toutes les prestations à réalisées, que ce soit les prestations attendues par le titulaire ou bien l acquisition des équipements nécessaires dans le délai imparti. Doivent être prises en compte : - l acquisition du matériel informatique adéquat tel que précisé dans la définition des ressources, - les installations logicielles nécessaires par le titulaire mais également par le Conseil général, - les formations d accompagnements de la mise en place de l application (formation utilisateur, administrateur ou bien formation sur l installation des composants dans un souci d indépendance pour le déploiement futur de l application ), - les phases officielles de mise en œuvre : phase de test, validation, Mise en Ordre de Marche (MOM), passage en phase de production - fourniture des données et éléments nécessaires de la part du CG à la société en charge de les «préparer», - préparation et travail en interne des données (migration, réalisation du Modèle Physique de Données), - remise au Conseil général ; Le CCTP prévoit la réalisation du projet selon deux tranches : une première tranche ferme suivie d une tranche conditionnelle. Selon cette base, un planning de mise en œuvre a été établi par la société en charge de réalisé la fourniture et l installation de l application : GEOMAP sous forme d un diagramme de GANTT (confère annexe p.49-50). La tranche ferme inclut toutes les étapes de mise en place et d installation préalables à l exploitation de l application : installation des composantes, migration et préparation des données, paramétrage de l application La tranche conditionnelle fait suite à la tranche ferme : elle concerne notamment le déploiement de l application vers les clients distants. Le phasage du projet prévoyait initialement comme objectifs : - septembre 2006 pour la mise en œuvre de l application en interne à la Direction des routes, - Janvier 2007 : pour son déploiement dans les sites distants. Phase préalable à la mise en oeuvre du projet 25

26 Stratégie de mise en œuvre Pour faciliter la réalisation et la mise en oeuvre de la nouvelle solution SIG, un environnement test sera créé avant de se placer dans l environnement de production accessible à tous les clients. Cet environnement test comprend un serveur de test mis à disposition par la DSI, un poste client localisé au service PCC-SIG de la Direction des routes ainsi qu un poste dédié au paramétrage et à l administration de l application, lequel sera conservé dans l environnement de production. Il servira pour toutes les étapes nécessaires à la préparation de l application. De plus, il devra permettre de tester cette dernière tout en simulant les différents types de clients qui devront être intégrés a posteriori. Cette simulation devra prendre en compte toutes les contraintes technologiques : différents types de connexion via Intranet pouvant jouer sur les temps d accès et de réponses entre le poste client et la base de données situées en central sur un serveur. Une fois l application installée et testée, la base de données pourra alors être transférée en environnement de production et les applications clientes pourront être déployées. >> Aperçu synthétique du déroulement de la mise en oeuvre Phase préalable à la mise en oeuvre du projet 26

27 Phase de mise en œuvre du projet Phase d installation : conception fonctionnelle Les briques logicielles L architecture logicielle finale se compose d un SGBD et d une plateforme graphique à laquelle se superpose l application métier : - Oracle Locator 10g comme SGBD, - MapInfo comme environnement de travail ou plateforme graphique (interface homme/ machine), - Geomap GIS Routes. Oracle Locator 10g Oracle est un Système de Gestion de Base de Données (SGBD ou Data Base Management System). Depuis sa version 8i, Oracle propose un modèle de données de type Relationnel-Objet. Ce modèle est issu à la fois du modèle «Relationnel» repris par la plupart des SGBD disponibles sur le marché (comme ACCESS de Microsoft), et du modèle Orienté-Objet. Oracle fournit un véritable «environnement de travail» constitué d une suite logicielle permettant de rassembler des outils aux fonctionnalités complémentaires : - outils d administration, - outils de développement, - outils de communication, - outils de génie logiciel, - outils d aide à la décision. La version installée au CG38 est issue de la version Standard : Oracle Locator 10g. Oracle Locator constitue le «coeur» d Oracle Spatial et est inclus dans les deux variantes du SGBD Oracle proposées sur le marché : «Standard Edition» et «Enterprise Edition». A l inverse de la variante Entreprise, la variante Standard n intègre pas la cartouche spatiale et ne dispose pas de fonctionnalités d analyses spatiales aussi poussées (notamment sur le plan topologique), mais elle permet le stockage de la géométrie au format Oracle Spatial type «SDO_GEOMETRY». Ce dernier s est développé par l utilisation de la table SDO_GEOM_METADATA, laquelle gère les métadonnées relatives à la spatialisation des données (type de géométrie, nom de la colonne stockant la géométrie des objets, système de coordonnées utilisé ). Le format SDO_GEOMETRY contient les éléments suivant relatifs à chaque éléments (entités) spatial : - SDO_GTYPE : indique le type de géométrie (point, ligne, arcs ), - SDO_SRID : système de coordonnées utilisé, - SDO_ELEM_INFO : triplets décrivant le mode de stockage des coordonnées dans le SDO_ ORDINATE, - SDO_ORDINATE : coordonnées des éléments ; Phase de mise en oeuvre du projet 27

28 Le modèle de données d Oracle se base sur : - la layer : ensemble d objets géométriques ayant la même structure attributaire comprenant un champ géométrique (correspondant à une table), - les géométries : enregistrements de la table, - les éléments : bloc de base d une géométrie (point, ligne, polygone). Au niveau de la géométrie et de la spatialisation des données, Oracle fournit des possibilités de stockage et d exploitation évoluées, afin d améliorer les performances lors l interrogation de la base de données (gain de temps lors de requêtes ), grâce à : - des mécanismes d indexation très poussés (basés sur une indexation de type R-Trees ou Quad-Trees), - un schéma MDSYS décrivant la syntaxe, le stockage et les formats de données, - des fonctions et des procédures d administration, - un ensemble d opérateurs et de fonctions pour exécuter les requêtes spatiales. La géométrie de chaque objet est alors stockée dans un champ GEOMETRIE commun à chaque layer stockant des entités géométriques, au même titre que les champs attributaires (une colonne et une seule ligne par enregistrement). Le stockage de la géométrie se base sur le modèle SDO_ GEOMETRY. Le stockage des données et plus particulièrement de celles décrivant la géométrie et la spatialisation de chaque objet a été développé conformément aux dispositions de l OGC. Oracle étend également les possibilités de stockage à d autres types de données tel que les images, vidéo et XML (Extensible Markup Language ou langage de balisage extensible, format du World Wide Web servant à la description de tous types de données et textes). MapInfo L intérêt du logiciel SIG bureautique MapInfo évolue considérablement lorsqu on le complète d un SGBD ainsi que d un progiciel métier. La complémentarité d un tel logiciel avec un serveur SGBD lui confère un rôle de «client» permettant l interrogation du serveur SGBD et donc l accès à la base de données, mais ne lui enlève pas ses fonctionnalités de présentation et d exploitation de la base. Dans ce cas, le SGBD utilisé apporte en plus des possibilités de sécurisation quand à l accès et à l exploitation de la base de données. L intégration dans une architecture logicielle multicouche comprenant une application métier en aval et un SGBD en amont restreint le rôle du logiciel à une simple couche interface Homme/ machine. Il sert alors essentiellement de «plateforme graphique» : espace d affichage graphique et de visualisation des données. La symbolique des données ainsi que les possibilités de requêtes sont apportées par le progiciel métier. C est ce dernier qui devient également client et gère l accès au serveur de données inclus dans le SGBD. Geomap GIS Routes La couche métier incorporée en aval de l installation consiste avant tout à fournir des fonctionnalités métier plus poussées et ciblées spécifiquement sur la thématique du SIG en place. Dans le cadre de Geomap GIS Routes, le progiciel apporte en plus des fonctionnalités demandées des possibilités de gestion et de présentation des données, tant dans l interface homme/machine que dans la symbolique graphique des données. La connexion entre MapInfo et la base de données distante doit bien sûr être établie pour permettre l affichage d une table distante par MapInfo (connexion type DBMS permettant de télécharger et de cartographier des tables dans MapInfo depuis une base de données distantes). La couche métier assure donc la quasi totalité de l interface homme/machine en terme de Phase de mise en oeuvre du projet 28

29 fonctionnalités comprenant à la fois les fonctionnalités agissant graphiquement sur les données (modifications, consultations), mais également les fonctions d accès : ouverture et affichage d une layer (ou table). L utilisateur n a donc pas besoin de passer par des outils plus complexes disponibles dans MapInfo pour accéder à des données distantes. L accès en tant que client et la communication à la base de données distante se fait par Geomap et non par MapInfo. >> Schéma d architecture client/serveur Autodesk MapGuide Il s agit d un moteur cartographique développé par la société Autodesk en charge de la diffusion de données graphiques de type SIG sur le Web. Les technologies Web peuvent alors être utilisées au sein du Système d Information Routier permettant l intégration de clients distants dans le SIR via un réseau Intranet, Extranet ou Internet. Les réseaux nécessaires Plusieurs types de réseaux sont utilisés en fonction de la localisation géographique des clients par rapport aux serveurs utilisés (comprenant la base de données, le serveur cartographique ) situés en salle machine du à l Hôtel Du Département : - Les sites centraux du CG38 dispose d un réseau interne LAN (Local Area Network) partagés en lecteur selon l organisation du CG en direction et services. Le CG38 fait également parti des organismes publics connectés à la dorsale «métronet» : il s agit d un réseau fibre-optique ultrahaut-débit disposé sur le pourtour de l agglomération grenobloise réservé aux organismes publics notamment (universités, sites de organismes de recherche, collectivités ), leur permettant des échanges de données relativement volumineux dans des temps restreints. Ainsi, les sites centraux du CG38 situés dans l agglomération et connectés à ce réseau pourront l utiliser ; - Les autres sites du non-reliés au réseau interne du CG devront se connecter via le réseau Intranet en utilisant les technologies réseaux dont ils disposent suivant leur localisation : ADSL pour la plupart d entre eux. Phase de mise en oeuvre du projet 29

30 Schéma d architecture fonctionnelle >> Phase de mise en oeuvre du projet 30

31 Architec ture fonc tionnelle Décomposition des briques logicielles Oracle Locator 10g fonctionne en architecture client/serveur comprenant : - le serveur de données et d application dans lequel est créé la base et où se font les opérations de consultation et d exploitation de la base, - un module administrateur, - un module client L application Geomap GIS Routes se compose de plusieurs modules : - un moteur de requêtes ou serveur spatial chargé de transmettre les requêtes depuis le poste client à la base de données, - un module administrateur, - un module client variant suivant le type de client. Installation logicielle Selon les briques logicielles décrites précédemment, les modules logiciels à installer se répartissent entre ceux à installer sur serveur, et ceux installés en local sur chaque poste client. Installation à réaliser en central sur serveur Installation d Oracle Locator 10g Pendant la première phase d installation et de mise en place de l application, la base de données sera stockée sur un serveur test. Le SGBD est déjà installé sur un serveur informatique dédié au stockage des bases de données en phase de test. Il est bien sûr nécessaire de vérifier au préalable que l espace disque disponible sur le serveur sera suffisant pour contenir la BDR. Il faut alors créer l espace dédié à la BDR ainsi que l architecture de la base au sein du SGBD lequel peut contenir plusieurs bases de données aux thématiques différentes : Création de la DATABASE dans Oracle Locator 10g : création de l espace dédié à la base de données routières Installation de la console d administration Oracle Entreprise Manager (Module DBA) Installation de la console serveur Geomap : Installation de la console administrateur Geomap Installation du serveur cartographique Autodesk MapGuide Installation à réaliser en local sur poste client MapInfo Professionnel Les postes clients lourds nécessitent l installation de MapInfo Professionnel version 8 ou supérieures. La plupart de postes sont déjà équipés. Il est nécessaire de réaliser une installation complète, comprenant les options : - installation des pilotes Ole DB : protocole permettant la communication entre une application (comme Geomap) et une base de données distante (comme une base de données Oracle). Le choix du protocole Ole DB plutôt que le protocole classique ODBC a été imposé par l utilisation de l application Geomap. - installations des options de connexion Oracle Spatial. Phase de mise en oeuvre du projet 31

32 Client Oracle Le Client Oracle installé en local permet la communication avec le serveur de données Oracle. Pour la plupart des postes, il s agit d un client standard. Seul l administrateur bénéficie d un client Oracle type administrateur possédant tous les droits sur la base (installation du module DBA sur le poste local administrateur). Client Geomap Pour un client lourd, il s agit d un module client Geomap pour MapInfo à installer. Pour les clients distants via Intranet, il s agit simplement d un Active X à télécharger. L administrateur du SIR peut également être équipé du module administrateur Geomap sur son poste local. Mise en place d un poste environnement test comprenant : - la console d administration Geomap à partir de laquelle pourront être attribués des droits d accès par l identification d utilisateurs : déclaration et identification des utilisateurs se connectant à la BDR ; - l application Geomap - le logiciel MapInfo Cet environnement test est relié à la base de données Oracle. Phase de mise en oeuvre du projet 32

33 Phase de reprise des données Les données à reprendre Le Conseil Général de l Isère a demandé la reprise de données graphiques provenant de trois base de données différentes : la base VISAGE concernant les routes départementales toujours en place au CG38, la base MapInfo actuellement la plus utilisée, contenant le graphe routier (modélisation du réseau routier départemental), la base VISAGE relative aux routes nationales laquelle a été récupérée dans le cadre de la décentralisation et du transfert d une partie des routes nationales au département ; Toutes les données n étant pas exploitées, un tri a été effectué afin de ne reprendre que celles utiles à la gestion du réseau. Les données issues des deux bases VISAGE sont extraites au format.dbf : elles sont constituées de données de types alphanumériques décrivant la rubrique en question et dont la localisation de l attribut correspondant est décrite en PR+abscisses ou abscisses cumulées de début et fin d attribut. Bien qu elles n aient pas de représentation graphique dans leur base respective, la géométrie de ces données est déjà décrite en coordonnée curviligne. Les données issues de la base MapInfo comprenant principalement le graphe routier dans lequel chaque tronçon graphique est décrit par de multiples attributs. La base MapInfo comprant également d autres tables de même type : données attributaires se rapportant à des objets géométriques de type linéaire modélisant le réseau routier : les routes nationales, les autoroutes, les échangeurs autoroutiers. Il existe également une autre table importante pour la modélisation du réseau puisqu il s agit des PR à partir desquels vont être calculées et représentées les coordonnées des rubriques attributaires de chaque axe routier. Les autres tables de la BDR sont principalement des données d habillage de cartes ; il s agit de données ponctuelles dont l utilisation est principalement de pouvoir localiser spatialement lors d édition cartographiques : localisation des stations de comptage, des panneaux à message variables, des relais DDE... Il ne s agit pas de données de modélisation du graphe routier ou d attributs se rapportant au graphe. Réalisation du Modèle Physique de Données A partir du listing des attributs à reprendre établi par le chef de projet du PCC, un Modèle Physique de Données (MPD) a été réalisé. Le modèle physique de données se construit généralement à partir d un modèle conceptuel de données lequel reprend l ensemble des données à intégrer dans la base. Le MPD ajoute à cela les contraintes et spécificités du SGBD utilisé : spécification des identifiants, des clés primaires et étrangères... Etant donné l utilisation du SGBD Oracle Locator 10g basé sur un système relationnel-objet, la base de données se constitue d une table ou layer par rubrique attributaire : chaque layer de chaque attribut graphique contient donc un champ géométrique basé sur la géométrie Oracle SDO_GEOMETRY. Chaque attribut correspond donc à un «objet graphique» pouvant se représenter graphiquement. En revanche, pour les tables de données ponctuelles, la géométrie est gérée par l application Geomap (coordonnées X;Y). Phase de mise en oeuvre du projet 33

34 Le MPD a été réalisé par la société Geomap par l utilisation du logiciel POWER AMC permettant également de définir les vues, schéma et autres concepts nécessaires à la conception d une base de données Oracle.. La création des tables a été réalisée par des scripts SQL : création des tables destinées au stockage des données du graphe routier à l image du MPD, création des tables de METADATA : MAPCATALOG, création des utilisateurs, schéma et vues... Méthodologie de reprise des données On peut distinguer deux types de données à reprendre et intégrer dans la nouvelle BDR : les données graphiques de modélisation du réseau, et les données attributaires. Le référentiel routier Pour conserver une bonne précision et une bonne qualité du graphe routier, il a été décidé de «recréer» le graphe routier à partir des deux bases sources : Visage et MapInfo : la base Visage fournit une description précise des tronçons du réseau routier (longueur, routes rencontrées aux intersections), alors que le graphe routier issu de la base MapInfo fournit les tronçons graphiques. Pour cela, chaque tronçon graphique issu du graphe MapInfo a du être relié à sa description alphanumérique provenant de Visage. La même méthodologie a été employée pour les routes nationales. Reprise des données attributaires issues de Visage La même procédure sera utilisée pour la reprise des données issues des bases VISAGE RD et VISAGE RN. Une fois extraite au format.dbf lisible dans un tableau Excel, chaque enregistrement de chaque rubrique est intégrée tel quel dans le champ de sa layer correspondante. Les coordonnées sont déjà sous formes de coordonnées curvilignes et n ont pas besoins d être recalculées. En revanche, les objets graphiques correspondant à ces attributs n existent pas : il est donc nécessaire de les «créer» afin de remplir le champ géométrique. Les objets graphiques sont donc créés à partir des coordonnées de début et de fin données de manière attributaire par les bases VISAGE ; la géométrie est recréé à partir du graphe. Cette procédure est réalisable à l aide d un outil spécifique développé par Geomap qui se base sur la correspondance entre l axe indiqué pour chaque enregistrement, et l axe du graphe routier. Reprise des données attributaires MapInfo La reprise des données attributaires des tables MapInfo composant le référentiel routier actuel s effectue en deux temps. Dans un premier temps, les données doivent être intégrées dans le nouveau SGBD, Oracle. Dans un second temps, il s agit de renseigner graphiquement et géométriquement ces données. A l inverse des données issues des bases VISAGE, les données attributaires MapInfo ne comportent aucun champ renseignant sur leur géométrie ou leurs coordonnées curvilignes. La liaison entre le référentiel MapInfo d où proviennent les attributs et le nouveau graphe ne peut se faire que graphiquement sur l interface graphique MapInfo. La correspondance graphique doit s accompagner d une concordance entre le nom d axe issu des deux référentiels routiers. C est d après ce «placage graphique» que vont pouvoir être calculées les coordonnées curvilignes des attributs et les champs géométriques renseignés. Phase de mise en oeuvre du projet 34

35 Réalisation de la reprise des données : avantages et inconvénients La réalisation de la reprise des données afin de faire migrer les données dans la nouvelle base Oracle a nécessité un travail technique, long et fastidieux notamment pour la reprise du graphe puisqu il a fallu étiqueter chaque tronçon routier. Cette méthodologie permettait de relier les informations attributaires sur les axes eux-mêmes (longueur et routes rencontrées aux intersections) issues de la base Visage RD au graphe de MapInfo. Cela apporte une complémentarité des bases inexistante jusqu alors. Cette méthodologie présente tout de même des aspects négatifs : D une part la reprise de chaque axe tronçon par tronçon exige un temps relativement long, D autre part, elle tente d accorder deux bases qui n ont pas été mises à jour parallèlement : ainsi le graphe routier MapInfo a toujours été maintenu à jour graphiquement (changement de tracé, déplacement de PR pouvant influer sur les coordonnées...) alors que la base de données Visage ne l a pas toujours été : les longueurs des tronçons et les intersections ne concordent donc plus à ce que représente le graphe routier. Le problème de discordance entre les bases se pose également lors de la remontée des données attributaires des bases VISAGE. Bien qu il n y ait pas lieu de devoir recalculer leurs coordonnées, il est nécessaire de faire correspondre géométriquement ces données attributaires au graphe. Cette correspondance peut se faire à la seule condition que les noms des axes indiqués dans chaque table attributaire doivent pouvoir correspondre aux noms des axes du graphe. Or, la dénomination des routes dans les bases VISAGE n est pas la même que celle utilisée au CG38 et récupérée dans le nouveau graphe. De plus, un attribut issu de Visage n est plus pertinent si le point de repère 0 de l axe auquel il se rapporte a été déplacé. En outre, le calcul de la géométrie des attributs récupérés de VISAGE et MapInfo ainsi que le calcul des coordonnées de ces derniers se calque sur une correspondance entre les noms des axes des tables attributaires et ceux de la table du graphe. Cette correspondance n est assurée que si le graphe routier est lui-même entièrement repris et étiqueté. Format géométrique de la nouvelle BDR Segmentation dynamique et coordonnées curvilignes Historiquement, la gestion des routes se fait en PR+abscisses ; ce système permet une meilleure gestion des localisations d évènements le long d un axe. Ainsi, l application VISAGE développée par le Sétra se base sur ce système de localisation. L utilisation d un logiciel SIG comme MapInfo et l acquisition d un référentiel de modélisation du réseau (BD Carto de l IGN) ont imposé d utiliser des coordonnées latitude/longitude (X ;Y). Le fonctionnement d un système basé sur les abscisses curvilignes ou coordonnées curvilignes se base sur la longueur d une entité de type linéaire (route) : cela nécessite d avoir préalablement choisit un repère 0 sur chaque entité ; le calcul de coordonnées se fait donc par calcul de la longueur de l entité linéaire ; La notion de segmentation dynamique renvoie un système de type coordonnées curvilignes : elle se fonde sur une «description d emplacement» qui prend appuie sur la mesure du linéaire en coordonnées curvilignes. Ces coordonnées doivent donc se référer à des entités géométriques de type linéaire avec un référentiel 0 pour chaque entité (début de l entité ou emplacement d un PR 0) : la Phase de mise en oeuvre du projet 35

36 table du graphe lui-même ou «référentiel». Les attributs «décrits» par leur coordonnées de début et fin sont alors reportés graphiquement sur l entité géométrique correspondante (la concordance entre les attributs et le référentiel se faisant par le nom d axe). La géométrie du référentiel graphique linéaire n est pas attaquée par la projection des attributs : il est possible d afficher plusieurs attributs correspondant à des thématiques différentes sur le même référentiel linéaire sans que celui-ci ne soit sur-segmenté géométriquement en fonction des données attributaires. La segmentation se fait dynamiquement lors de chaque affichage d un attribut mais celle du référentiel linéaire reste la même. La conversion entre des coordonnées en abscisse cumulées et des coordonnées en PR+abscisses se fait par la gestion de PR le long de l axe : pour chaque PR, sa localisation précise en abscisses cumulées doit être connue : on prend alors le PR localisé juste avant l évènement auquel on rajoute la distance depuis ce PR jusqu à l évènement lui-même. Extrait du référentiel routier >> >> Représentation graphique attributaire sur le même axe Phase de mise en oeuvre du projet 36

37 Référentiel graphique et données attributaires de la nouvelle BDR On différencie deux types de données dans la nouvelle base de données : - les données graphiques comprenant des données de types ponctuel (comme les PR ou carrefour) ou bien de type linéaire géocodé (rubrique attributaire linéaire se projetant sur un axe routier) ; - les données de type SQL qui n ont pas de représentation graphique : il s agit de layers ne comportant pas de champ géométrique, destinés à stocker des listes prédéfinies de données, des images... Au sein des données graphiques : trois tables sont particulièrement importantes puisque ce sont les tables de modélisation du réseau routier «référentiel graphique» qui vont être à la base de la représentation graphique des données attributaires : la table du graphe : comportant tout le linéaire de modélisation du réseau (départementales, nationales, autoroutes, échangeurs) : c est la table géométrique de référence puisque la géométrie des attributs se calque sur celle du graphe ; chaque enregistrement correspond à un tronçon ou arc linéaire délimité par des nœuds de début et fin. Pour chaque tronçon, sont renseignés le nom de l axe auquel le tronçon appartient, les numéros des carrefours contigus au tronçon, les coordonnées curvilignes de début et fin du tronçon, la géométrie du tronçon au format Oracle. Les tronçons portant le même numéro d axe compose donc cet axe. la table des PR : les PR de chaque axe servent au calcul des coordonnées de chaque attribut ainsi que des coordonnées de chaque tronçon routier, la table des carrefours : chaque tronçon est délimité par un noeud ou carrefour de début et de fin ; cette table va également servir à stocker les informations relatives aux carrefours (routes rencontrées). Phase de mise en oeuvre du projet 37

38 Phase de vérification d aptitudes (VA) La couche de données constitue une composante principale d un SIG. Un SI quel qu il soit ne peut être exploité et utilisé si les données qu il contient ne sont pas fiables. La qualité des données est un critère nécessaire à une bonne exploitation d un SIG. C est pourquoi il est essentiel d intégrer une phase destinée à s assurer de la qualité des données dans toute conduite de projet. Une phase de test correspondant à une «démarche qualité» est généralement incluse dans le calendrier de mise en oeuvre préalablement à l exploitation de l application : elle consiste généralement à tester et vérifier les données. Dans le cadre de la mise en œuvre de l application Geomap GIS Routes, un important travail de reprise et migration des données a été réalisé. Il s avère nécessaire de vérifier les données une fois celles-ci intégrées dans les nouvelles tables. Une phase de Vérification d Aptitude (VA) a été définie : sur une durée de 3 mois environ, elle se divise en deux thématiques : - vérification de la reprise des données issues des bases VISAGE et MapInfo, - vérification de la fonctionnalité de l application. Vérification de la reprise des données Cette étape est d autant plus importante que la migration des données s est accompagnée d un changement de format (passage du format propriétaire MapInfo au format Oracle spatial), nécessitant de recalculer leur géométrie ainsi que leurs coordonnées en abscisses cumulées de début et de fin de chaque entité géométrique. La méthodologie de vérification des données a été définie comme suit : vérification alphanumérique suivie d une vérification graphique. La vérification alphanumérique consiste en une interrogation de la base de données : elle peut être réalisée par divers interfaces : SQL+, Oracle Entreprise Manager ou bien depuis l interface client de l application grâce aux fonctionnalités de consultation des données alphanumériques de la base. Cette première étape se décline en une vérification quantitative suivie d une vérification qualitative. 1.Vérification d ordre quantitatif Il s agit de s assurer que l ensemble des données attributaires a bien été intégré dans la base Oracle. La vérification porte donc sur la quantité des données réintégrées dans la nouvelle base, en concordance avec le MPD découlant du listing des attributs demandés par le CG38. Points nécessitant une vérification : - structure de la base de données : nombre de tables, composition des tables, - remplissage des tables du référentiel routier : table des axes, carrefours et PR, - remplissage des tables attributaires ; La vérification quantitative se fait notamment par requête SQL : recherche du nombre d axes renseignés, les types valeurs attributaires, le nombre d axes par type de valeurs. Elle se fait par une approche globale de la base de données. 2.Vérification d ordre qualitatif La vérification qualitative porte sur les valeurs alphanumériques décrivant les attributs : Phase de mise en oeuvre du projet 38

39 coordonnées et valeurs attributaires. Elle peut s effectuer par approche globale de la base de données (recherche d arcs particuliers : arcs dont la coordonnée de début est supérieure à celle de fin, arc en doublon sur d autres arcs ), ou bien selon une approche par axe en se basant sur un échantillon d axe. 3.Vérification graphique Elle consiste à observer le rendu graphique des rubriques attributaires par rapport au référentiel graphique : concordance entre le positionnement graphique des attributs le long d un axe et ses coordonnées. La procédure de vérifications des données diffère selon l origine des données. En effet, les données issues des bases Visage n ont pas subi de transformations de coordonnées : elles ont été réintégrées avec leurs coordonnées d origine. Leur géométrie qui se conforme à celle du graphe est ensuite calculée d après le graphe. En revanche, la migration des données issues des tables MapInfo doit permettre de calculer les coordonnées attributaires en coordonnées curvilignes et de renseigner leur géométrie au format Oracle Spatial. Bien que les données attributaires issues de MapInfo puissent être explorées par requêtes, la vérification graphique est beaucoup plus importante puisqu elle permet de comparer les bases de données. Vérification de reprise des données issues des bases VISAGE : Elle porte essentiellement sur la vérification alphanumérique : par extraction des données depuis la base source et la base Oracle sous Excel, il est facile de comparer et vérifier les coordonnées et valeurs attributaires des deux sources. Vérification de reprise des données issues de la base MapInfo : Etant donné que les coordonnées sont calculées au moment de la migration des données depuis la table source vers les tables Oracle, il n est pas possible de comparer leurs valeurs. La seule comparaison possible se fait par comparaison graphique par analyses thématiques attributaires. Vérification des fonc tionnalités Conformément aux foncitonnalités demandés dans le CCTP rédigé lors de la phase de définition du projet, l application doit répondre à certains critères. La prononciation de la phase de Vérification d aptitudes doit permettre de valider la réponse fonctionnelle de l application par rapport aux CCTP. Une liste des fonctionnalités a été établi : chacune doit donc être testé eet validée. Dans un premier temps, le test portera sur les fonctionnalités de l application en tant que client lourd et administrateur : fonctionnalités relatives aux possibilités de consultation et de modification du graphe et des rubriques attributaires notamment, focntionnalités relatives aux possibilités de paramétrages des droits et de l application. Phase de mise en oeuvre du projet 39

40 Phase de paramétrage Bien que les fonctionnalités de paramétrage doivent être testées durant la phase VA, le paramétrage complet de l application ne peut se faire qu en phase d exploitation. Conformément aux possibilités offertes par Geomap GIS Routes depuis la console d administration, le paramétrage comprend d une part, la préparation des interfaces d accès et de communication à la BDR depuis les postes clients, et d autre part l attribution des droits en fonction des différents types de clients et d utilisateurs. Paramétrage de l inter face Organisation de la BDR La couche Geomap GIS Routes se rajoute à l interface MapInfo habituel : elle apporte des barres d outils supplémentaires correspondant aux fonctionnalités métier Geomap. De plus, elle offre une interface d accès direct aux tables de la BDR stockée dans la base Oracle : listing des tables. C est par cette interface que les clients Geomap pour MapInfo pourront choisir les tables à afficher. Les actions et fonctionnalités propres à la couche sont également disponibles par cette interface. Les fonctionnalités de paramétrage proposées par Geomap permettent d apporter une structuration et une présentation à l application routière du CG38 : composants thématiques regroupant plusieurs tables. >> Organisation thématique des tables de la BDR Phase de mise en oeuvre du projet 40

41 Possibilités de paramétrage de la base de données Chaque table ou layer correspond à un «objet» : cet objet intègre également, en plus des variables de la table, des formats prédéfinis : format graphique lors de l affichage de la couche, format de présentation graphique et alphanumérique lors de requêtes, procédures propres aux variables de la table déclarées dans l objet : requêtes graphiques alphanumériques définies selon des critères choisis (choix d un axe ou critères sur une ou plusieurs variables) permettant l extraction de données depuis la base de données. De plus, à chaque objet doit être défini des interfaces de consultation qui pourront être appelés par les utilisateurs pour visualiser les données alphanumériques de la table. Ces interfaces se présentent sous formes de fiches ou tableaux pour lesquels il faut définir les variables (ou champs) de la table à afficher. Les actions permettant la consultation ainsi que la modification ou la création de données doivent donc être déclarées pour chaque objet. Ce fonctionnement apporte une sécurité supplémentaire quant à l intégrité de la base puisqu il faut nécessairement mettre à disposition des utilisateurs les actions pouvant impacter les données de la table. Exemple de fiche de consultation >> Phase de mise en oeuvre du projet 41

42 Administration de la BDR Seul l administrateur de l application possède le module d administration Geomap installé sur son poste. C est donc lui qui est en charge de son paramétrage. Le rôle de l administrateur est de: - structurer l information de la base de données routières : présentation des tables selon des groupes thématiques, - assurer la gestion des droits et des groupes d utilisateurs, - assurer l évolution de la BDR : création de nouvelles tables, - préparer les interfaces prédéfinis pour les clients ; La définition des droits donne prioritairement lieu à un listing des utilisateurs de l application. Bien qu actuellement les seuls utilisateurs courants de la BDR soient ceux du service PCC, les futurs utilisateurs doivent être pris en compte puisqu ils seront intégrés dans le SIR dès sa mise en exploitation. Leurs droits sont donc définis en fonction des données sur lesquelles ils seront susceptibles d intervenir. Le paramétrage de l application assurera au SIR sa sécurité et son intégrité en définissant précisément le rôle de chaque utilisateur potentiel, et en leur conférant des droits sur la base en fonction de leur rôle. Listing des utilisateurs Dans un premier temps, les droits ne sont définis que pour les clients les plus concernés et auxquels l application va être déployée dès que possible : En site central : - au service PCC/SIG : 2 à 3 agents dans un premier temps, - au service entretien de la Direction des routes : 4 agents ; En site distants : - dans les Maisons du Département : 1 type d utilisateur par territoire ; La gestion des droits ne descendra pas au niveau de chaque utilisateur : cela nécessiterait une définition trop détaillée par rapport aux besoins nécessaires. Les agents d un même service ont les mêmes besoins. De fait, les droits seront paramétrés selon des groupes d utilisateurs correspondant à chaque service. L attribution de droits particuliers pour un utilisateur sera toujours possible si besoin est. SERVICES PCC/SIG Service entretien routier Maisons du Département FONCTION Droit intégral sur la BDR : droit d accès et d écriture sur l ensemble de la BDR Postes d administration et de paramétrage de la BDR Consultation, exploitation de la base et création de cartes Droits d écritures/modifications sur une partie des données attributaires Consultation, exploitation de la base et création de cartes Droits d écritures/modifications sur les données attributaires relatives au territoire en question >> Tableau synthétique de l utilisation de la BDR selon les services Phase de mise en oeuvre du projet 42

43 Outils de gestion des droits de Geomap Les possibilités de gestion des droits par la console Studio Geomap sont multiples à l image de l interface de l application. Chaque niveau de l arborescence de l application peut faire l objet d attributions de droits. A l image des possibilités de paramétrage de l application, la gestion des droits peut se faire autant sur les données elles-mêmes que sur les procédures ou interfaces associés. La performance de gestion des droits tient dans sa possibilité de déclarer des droits au niveau de chaque champ d une table (ou layer) mais également sur les actions et interfaces propres à chaque objet. L attribution des droits se fait notamment par déclaration de permissions sur les composants. Les types de permissions courants : - accès interdit - lecture seule : simple consultation avec droit d accès aux procédures de requêtes, - droits de consultation, de modifications et/ou création (complétés par la mise à disposition des fonctionnalités correspondantes). Attribution des droits Le paramétrage des droits se fait selon les utilisations laissées aux différents clients : - consultation de données alphanumériques, graphiques et cartographiques, - réalisation de requêtes et rapports pour extraire des données particulières, - réalisation cartographique, - mise à jour de certaines rubriques attributaires, - modification du graphe ; Afin de laisser aux nouveaux clients le temps de s habituer à l interface de la nouvelle application Geomap GIS Routes, il a été décidé de n ouvrir les droits de la BDR qu en consultation simple dans un premier temps. Dans un second temps, les droits de modifications des données attributaires et éventuellement du graphe seront attribuées au service PCC afin qu il puisse réaliser les mises à jour nécessaires laissées en attente depuis la période de migration des données. Puis la passation des droits de modifications attributaires notamment se fera aux clients du service Entretien pour les rubriques les concernant. Les clients installés dans les Maisons du Département seront donc les derniers à se voir attribuer des droits de modifications. La définition des droits en fonction des utilisateurs a d abord été définie pour chaque rubrique (confère Tableau des droits en annexe p.51-52). En revanche, le paramétrage des droits concernant les Maisons du Département nécessite une restriction géographique selon la localisation de la donnée : chaque client issu d une des Maisons du Département ne pourra modifier que les données relatives au territoire auquel il appartient. Cette restriction géographique ne peut se faire par les seules fonctionnalités de Geomap : dans ce cas, la complémentarité des briques logicielles est nécessaire puisque ce «droit géographique» pourra être attribué par Oracle. Phase de mise en oeuvre du projet 43

44 >> Exemple d interface pour un client accès à toutes les fonctionnalités >> Exemple d interface pour un client ayant des doits restreints sur les actions notamment Phase de mise en oeuvre du projet 44

45 Phase opérationnelle : déploiement et perspective Le déploiement de l application une fois son passage en phase de production se fera progressivement. Bien que les droits aient été définis en fonction de l utilisation des données de la BDR selon chaque groupe d utilisateurs parallèlement à leur service respectif, l accès à la BDR ne sera permis qu en consultation. Cette étape permettra déjà aux agents de se familiariser avec l interface Geomap par MapGuide ainsi qu aux fonctionnalités de consultation et d interrogation proposées par Geomap GIS Routes. Dans un second temps, des permissions de modification seront accordées progressivement, conformément à la définition des droits. L accès à la BDR se fera donc progressivement. Le déploiement des postes clients dans les services internes puis au sein des Maisons de Département du CG38 s accompagnera de formations utilisateurs simultanément à leur intégration dans le SIR. D autre part, le paramétrage de l application routière pourra également être «personnalisé» en fonction de l attente des différents groupes d utilisateurs : ouverture automatiques de certaines données lors du lancement de l application. A plus long terme, le SIR pourra s étendre à d autre service comme le service Expertise, lequel sera intéressé par des tables particulières : données sur les ouvrages d art, dispositifs contre les risques naturels. Phase de mise en oeuvre du projet 45

46 Au-delà, d une présentation synthétique globale du déroulement d un projet SIG, cette approche soulève l importance d une rigueur méthodologique en terme organisationnel autant dans la phase de conception du projet que dans sa phase de mise en œuvre. Bien qu il s agisse d un projet de petite envergure car dédié à une application routière fondée sur une base de données relativement légère comparativement à d autres systèmes d information, il démontre la nécessité de suivre progressivement les étapes d avancement, et surtout l importance de la préparation par une définition la plus précise possible et une anticipation la plus détaillée des étapes de mise en œuvre. Bien que les aspects techniques n aient pas été développés de manière précise, les étapes détaillées de la phase de mise en œuvre de l application illustrent la complexité de cette phase. Les difficultés rencontrées font notamment référence aux problèmes de migration et de compatibilité des données, problématique récurrente dans le monde des SIG. D autre part, l architecture logicielle et les technologies informatiques nécessaires impliqués dans ce projet démontrent une fois de plus l ambiguïté de la place des SIG dans une structure entre son domaine d application et le monde informatique. A cette ambiguïté se rajoute celle d une «concurrence» entre les applications SIG thématiques comme celle des routes interne à une direction, et un SIG central ; il est donc difficile de trouver le compromis équilibré entre les applications thématiques et un SIG général tout en leur assurant un rôle fédérateur au sein de la collectivité et une mutualisation des données. La place centrale d un SIG en tant qu outil transversal ne permet pas toujours une bonne efficience face à un domaine d application particulier. En ce sens, l utilisation de technologies et d architectures logicielles plus élaborées peuvent parfois permettre de palier à ces difficultés. En outre, il devient évident que les SIG deviennent un outil de plus en plus complet par leur développement sur le monde de l Internet. En ce sens, leur accessibilité doit être assurée en tant qu outil de travail au quotidien auprès de plus en plus d agents ; les SIG ne sont donc pas destinées à être un domaine particulier réservé à des spécialistes issus notamment du monde l informatique ou de la géographie. 46

47 Bibliographie Sources d information sur les collectivités territoriales Sources documentaires internes au Conseil général de l Isère Sites Internet : Sources sur la méthodologie de conduite de projet Vademecum du chef de projet SIG : Sylvie Ravalet - Isabelle Panet, Ecole Nationale des Sciences Géographiques, Institut Géographique National, 2001 ( Cahier méthodologique sur la mise en œuvre d un SIG : Sources relatives au domaine informatique Informatique général Encyclopédie informatique libre : Dictionnaire de l informatique : SGBD : source d information et de tutoriaux sur les SGBD Autres sources: Que sais-je? Les Systèmes d Information Géographique, Jean Denègre - Françoise Salgé, PUF, Documentation et cours issus du cadre universitaire Sources Internet : Documentation diverse 47

48 ANNEXES Annexe 1 : Planning de mise en oeuvre Annexe 2 : Tableau des droits Annexe 3 : Exemple d interface de paramétrage des objets Annexe 4 : Exemple de synotpique 48

49 Annexe 1 : Planning de mise en oeuvre 49

50

51 Annexe 2 : Tableau des droits 51

52 Nom_table Type Poste ADM. Droits Service PCC Droits Service Entretien Droits Territoires Couche de structure SIR_GL_COUCHE_S ADM RXWDPE CC&M RXE CC&M RXE CC&M RXE Calibrage SIR_GL_CALIBRAGE ADM RXWDPE CC&M RXE CC&M RXE CC&M RXE Calibrage Classe_profil SIR_CLASSE_PROFIL ADM RXWDPE CC&M RXE SO No Access SO No Access Couche de liaison SIR_GL_COUCHE_L ADM RXWDPE CC&M RXE CC&M RXE CC&M RXE Couche de roulement SIR_GL_COUCHE_R ADM RXWDPE CC&M RXE CC&M RXE CC&M RXE Couche de roulement - nature SIR_COUCHE_NATURE ADM RXWDPE CC&M RXE SO No Access SO No Access Type de structure SIR_GL_STRUCT_TYPE ADM RXWDPE CC&M RXE CC&M RXE CC&M RXE Type de structure - Type SIR_STRUCT_TYPE ADM RXWDPE CC&M RXE SO No Access SO No Access Dispositif de retenue SIR_GL_RETENUE ADM RXWDPE CC&M RXE CC&M RXE CS RX Signalisation horizontale SIR_GL_SH ADM RXWDPE CC&M RXE CC&M RXE CS RX Gestionnaire SIR_GL_GESTION ADM RXWDPE CC&M RXE CS RX CS RX Subdivision SIR_GL_SUBDI ADM RXWDPE CC&M RXE CS RX CS RX Territoires SIR_GL_TERRITOIRE ADM RXWDPE CC&M RXE CS RX CS RX Categorie SIR_GL_CATEGORIE ADM RXWDPE CC&M RXE CS RX CS RX Classement SIR_GL_CLASSEMENT ADM RXWDPE CC&M RXE CS RX CS RX Itinéraire cyclable SIR_GL_ITIN_CYCL ADM RXWDPE CC&M RXE CS RX CS RX Itinéraire SIR_GL_ITIN ADM RXWDPE CC&M RXE CC&M RXE CS RX Itinéraire - description SIR_ITIN_DESC ADM RXWDPE CC&M RXE CC&M RXE CS RX Communes SIR_PL_COMMUNE_EP ADM RXWDPE CC&M RXE CS RX CS RX Subdivision SIR_PL_SUBDI ADM RXWDPE CC&M RXE CS RX CS RX Territoires SIR_PL_TERRITOIRE ADM RXWDPE CC&M RXE CS RX CS RX Déflexion SIR_GL_DEFLEXION ADM RXWDPE CC&M RXE CC&M RXE CS RX Déformation SIR_GL_DEFORM ADM RXWDPE CC&M RXE CC&M RXE CS RX Déformation et fissure latérale SIR_GL_DFL ADM RXWDPE CC&M RXE CC&M RXE CS RX Déformation et fissure transversale SIR_GL_DFT ADM RXWDPE CC&M RXE CC&M RXE CS RX Glissance SIR_GL_GLISSANCE ADM RXWDPE CC&M RXE CC&M RXE CS RX Rugolaser SIR_GL_RUGO ADM RXWDPE CC&M RXE CC&M RXE CS RX Gestion des sections SIR_GL_GEST_SECT ADM RXWDPE CC&M RXE CS RX CS RX Dispositif contre les risques naturels SIR_GL_RISQ_NAT ADM RXWDPE CC&M RXE CS RX CS RX Section SIR_GL_SECTION ADM RXWDPE CC&M RXE CS RX CS RX Profil en long SIR_GL_PROF_LONG ADM RXWDPE CC&M RXE CS RX CS RX Tracé en plan SIR_GL_TRACE_PLAN ADM RXWDPE CC&M RXE CS RX CS RX Tracé en plan nature SIR_TP_NATURE ADM RXWDPE CC&M RXE CS RX CS RX Accotement SIR_GL_ACCOTEMENT ADM RXWDPE CC&M RXE CS RX CS RX Accotement_nature SIR_ACCOT_NAT ADM RXWDPE CC&M RXE SO No Access SO No Access Aménagement central TPC SIR_GL_AMC_TPC ADM RXWDPE CC&M RXE CS RX CS RX Aménagement central TPC_niveau SIR_NIVEAU ADM RXWDPE CC&M RXE SO No Access SO No Access Aménagement central TPC_type SIR_AMEN_TYPE ADM RXWDPE CC&M RXE SO No Access SO No Access Assainissement drainage SIR_GL_ASS_DRAI ADM RXWDPE CC&M RXE CS RX CS RX Assainissement drainage type SIR_TYPE_ASS ADM RXWDPE CC&M RXE SO No Access SO No Access BAU SIR_GL_BAU ADM RXWDPE CC&M RXE CS RX CS RX Agglomération SIR_GL_AGGLO ADM RXWDPE CC&M RXE CS RX CS RX Agglomératio_liste SIR_AGGLO_LISTE ADM RXWDPE CC&M RXE SO No Access SO No Access Largeur SIR_GL_LARGEUR ADM RXWDPE CC&M RXE CS RX CS RX Largeur Nb-voies SIR_NB_VOIE ADM RXWDPE CC&M RXE SO No Access SO No Access Recalage BD Ortho SIR_GL_RECALAGE ADM RXWDPE CC&M RXE CS RX CS RX RN transférées SIR_GL_RN_TRANSF ADM RXWDPE CC&M RXE CS RX CS RX Voie bus SIR_GL_VOIE_BUS ADM RXWDPE CC&M RXE CS RX CS RX Axe = graphe SIR_GR_AXE ADM RXWDPE CS RX CS RX CS RX Carrefour SIR_GR_NŒUD ADM RXWDPE CS RX CS RX CS RX Carrefour - document SIR_NŒUD_DOC ADM RXWDPE CS RX CS RX CS RX Carrefour - type SIR_NŒUD_TYPE ADM RXWDPE CS RX CS RX CS RX PR SIR_GP_PR ADM RXWDPE CS RX CS RX CS RX Transport exceptionnel SIR_GL_TE ADM RXWDPE CC&M RXE CS RX CS RX Barrière de dégel SIR_GL_BAR_DEGEL ADM RXWDPE CC&M RXE CC&M RXE CS RX Viabilité Hivernale SIR_GL_VH ADM RXWDPE CC&M RXE CS RX CS RX RX : droit de visualisation * SO "Sans Objet" RXE : droit de visualisation et d'exécution de procédures de consultation * CS "Consultation Simple" RXWDE : droit de modification sur l'objet, de création et de suppression * CC&M "Création, Consultation et Modification" RXWDPE : tous les droits et droit d'attribuer des permissions * ADM "Administration" No Access

53 Annexe 3 : Exemple d interface de paramétrage des objets Annexe 4 : Exemple de synotpique 53