L'organisation des données géographiques à la Communauté d'Agglomération de Cergy-Pontoise

	Session Collectivités Territoriales
	Direction des Systèmes d’Information Gwénaëlle DAUNAS-LORTEAU Helga MONDESIR

	Mots-clés et logiciels ESRI utilisés
	Logiciels ESRI utilisés : ArcGIS, ArcEditor, ArcSDE, ArcIMS

La Communauté d’agglomération de Cergy-Pontoise a commencé en janvier 2006 une réflexion sur l’organisation des données géographiques, avec pour objectifs :

de simplifier l’accès à la donnée pour les utilisateurs,
de tendre vers l’unicité des bases de données,
de faciliter la connaissance et la recherche de données,
de faciliter la gestion des droits sous ArcSDE.

Ce projet d’une durée d’un an a été entrepris avec la société IDS France. Les utilisateurs du SIG dans la collectivité ont été fortement impliqués dans ce projet, par la création d’un groupe de travail comptant 15 personnes et mobilisé sur toute la durée du projet.

1. POURQUOI UN TEL PROJET

Le service de l’information géographique a été créé en juillet 2000. Après 5 années passées qui ont vues les compétences de l’agglomération évoluer, les données se multiplier, le nombre d’utilisateurs augmenter….il devenait nécessaire avant de poursuivre la croissance du service de structurer les données et les bases à une plus grande échelle.
Nous avions constaté que nos utilisateurs ne connaissaient pas bien les données disponibles, et quand ils les connaissaient, ils avaient parfois du mal à les retrouver. Ceci a entraîné parfois des duplications de données, et par conséquent des données qui perdaient de leur fiabilité. Les utilisateurs ont tout de suite compris l’importance du projet, mais également sa nécessité urgente et ce qu’une plus grande mutualisation de la donnée aller leur apporter.

2. LES ETAPES DU PROJET

Tout d’abord notre réflexion a été globale. Nous avons travaillé sur l’information géographique au sens large, c'est-à-dire les données SIG (classes d’entités ArcSDE, raster essentiellement), mais également les données DWG et en particulier les plans topographiques au 1/500, ainsi que les fonds de plan du territoire. Nous avons aussi inclus dans notre réflexion les plans scannés géoréférencés….bref toutes les données géographiques disponibles à partir du moment où cette donnée est géoréférencée.

Dans un premier temps, la société IDS a rencontré nos utilisateurs, de manière individuelle. L’objectif de ces entretiens a été de voir les pratiques de nos utilisateurs, d’analyser leurs besoins et leurs difficultés, de recenser les données dans les services qui potentiellement devraient être mutualisées. A l’issue de ces entretiens, IDS nous remis un cahier de propositions qui permettaient à la fois de répondre à nos objectifs de départ, et aux besoins exprimés par les utilisateurs.

Toutes les propositions faites par IDS ont été retenues et mises en place. Deux axes de solutions ont été proposés :

une organisation des données SIG et DWG qui se déclinait au niveau des logiciels, des données, mais également au niveau des processus,
la mise en place d’un outil de saisie et de recherche de métadonnées adossé à notre intranet / extranet.

3. L’ORGANISATION MISE EN PLACE

3.1 Au niveau des serveur et des logiciels

3.1.1 Un serveur de données unique pour les données SIG et plans topographiques

Toutes les données géographiques (SIG et DWG) ont été centralisées sur un seul et unique serveur, utilisé en tant que serveur de fichiers afin d’offrir un maximum de sécurité :
- Toutes les données DWG sont stockées sur ce serveur de fichiers.
- Toutes les données SIG ont été stockées sur un second serveur sur lequel est installé ORACLE 10g et ArcSDE 9.1. Les données SIG sont accessibles sur le serveur de fichiers par des fichiers de représentations (*.LYR).

L’accès aux données (SIG et DWG) se fait donc d’une manière centralisée depuis un seul serveur (le serveur de fichiers), ce qui nous garantit :

Une seule version pour une même donnée : fiabilité
Toutes les données créées par le Service de l’Information Géographique, mais aussi toutes les données créées par les utilisateurs ont été stockées dans ArcSDE 9.1. Grâce aux privilèges qu’accorde ArcSDE sur les données, et aux différents utilisateurs et rôles que nous avons défini dans ORACLE (et après le déploiement de licences flottante ArcEditor), nous avons pu offrir à certains utilisateurs le droit de mettre à jour directement dans la base les données dont ils ont pris la responsabilité. Ceci permet non seulement de garantir l’unicité de la donnée, mais également de responsabiliser les utilisateurs sur la qualité du travail de mise à jour attendue.
Des règles de confidentialité sur les données sensibles
- Une centralisation de toutes les données géographiques sur un seul et unique serveur nécessitait que nous garantissions à nos utilisateurs une certaine confidentialité de leurs données. En effet, certains services manipulent des données sensibles qu’ils ne souhaitent pas mettre à disposition de tous les utilisateurs. Certaines données sont donc stockées dans ArcSDE mais accessible à nombre restreint d’utilisateurs.
- Au niveau de l’outil de consultation des métadonnées, certaines fiches de métadonnées ne sont accessibles qu’à des profils utilisateurs bien définis. Là encore c’est le producteur de la données qui définit le niveau de confidentialité de la donnée qu’il gère.
Des plans de sauvegardes et de restauration testés et validés
Nous avons mis en place quatre modes de sauvegarde de notre base ArcSDE 9.1, chacun de ces modes s’exécute de manière automatique à des fréquences différentes (mensuelle, hebdomadaire et quotidienne). Chacun de ces modes a pu être testé, un crash de la base a été effectué et toutes les sauvegardes testées pour la restauration de la base. Nous avons mis en place des procédures de remonte de chacune de nos sauvegardes.
Des recherches facilitées
Des données accessibles depuis un seul et même endroit facilite la recherche. Inutile d’aller rechercher des données sur plusieurs serveurs, c’est particulièrement pratique pour la constitution de notre bibliothèque de plans topographiques. Jusqu’à présent ces plans étaient dispersés sur les différents serveurs des services techniques de l’agglomération.

3.1.2 Des versions de logiciels uniformisées

Mise à niveau des licences Autocad, des applicatifs métiers et des licences SIG
-     Un des freins identifiés par IDS était la multitude de versions d’Autocad présente dans la collectivité. Ceci constituait un véritable frein à la communication de plans en interne, mais également en externe, car certain service travaillait avec des versions anciennes du logiciel. Nous avons donc mis à jour l’intégralité de notre parc de licences Autocad.
-     Comme toutes les données devaient être stockées dans ArcSDE, nous devions également migrer tous nos applicatifs métiers IMAGIS en V9. Tous, sauf IMAVOI étaient disponibles en V9.
-     Nous avons également mis à jour tout notre parc ESRI, en faisant la migration de la version 8.3 vers la version 9.1 de tous nos outils (ArcGIS, ArcIMS, ArcSDE).
Temps d’accès aux données améliorés
Le fait de migrer tous nos applicatifs métiers IMAGIS en V9 et donc d’aller attaquer la donnée métier directement dans ArcSDE nous a permis d’améliorer considérablement les temps d’accès à ces applicatifs pour nos utilisateurs travaillant dans des sites distants. Ces temps d’accès ont parfois éte réduits par 3.
Échanges facilités
Nos échanges avec les bureaux d’études et les communes ont été facilités, car nous disposons maintenant de licences actualisées d’Autocad, ce qui nous permet d’exploiter les dernières fonctionnalités de ce logiciel que beaucoup de nos prestataires utilisent.

3.2 Au niveau des données

3.2.1 Des données documentées par des référents en assurant la mise à jour

Des correspondants et référents responsables de leurs données
Pour chacune des données du SIG d’agglomération, un référent a été désigné. Ces référents sont avant tout des utilisateurs du SIG dans leur service, et par conséquent des producteurs de données dans leur métier. Chacun des référents a donc définit la liste des données (couches SIG ou plan DWG) qu’il était en mesure de mettre à jour à partir des informations dont il disposait dans son service. Il est bien évident que le service « Transport » par exemple est le mieux placé pour mettre à jour les données SIG relatives aux transports et déplacements. Chaque référent doit bien sûr mettre à jour la donnée, mais il est également chargé de la documenter via l’outil de saisie des métadonnées. Et c’est son nom qui apparaît dans la fiche de métadonnée, il est donc responsable de la qualité de cette donnée.
Des données renseignées pour mieux en évaluer la qualité
La saisie des métadonnées se fait via le site intranet / extranet du SIG d’agglomération. Chaque producteur a un identifiant / mot de passe lui permettant d’accéder à l’interface de saisie. L’interface de consultation est accessible à tous les utilisateurs du site en interne et dans les communes.

La documentation des données : un nombre restreint de champs à renseigner
Nous avons défini des métadonnées pour décrire nos données en nous affranchissant de toute normalisation sur le sujet. Nous faisons une différence entre les fichiers cartographiques (SIG et DWG) et les plans topographiques (DWG uniquement).

Liste des critères pour les fichiers cartographiques et les plans topographiques :
-       Type de fichier : « Fichiers cartographiques » OU « Plans topographiques »,
-       Description : description textuelle du contenu de la couche
-       Nom du producteur : personne ou organisme qui a créé la donnée
-       Nom du référent : personne responsable de la donnée (personne qui met à jour la donnée, ou qui la connaît très bien)
-       Thématique : « Aménagement urbain » OU « Cadastre » OU « Données générales » OU « Périmètres réglementaires » OU « Plans topographique » OU « Réseau ». Les thématiques constituent notre arborescence de fichiers sur le serveur de fichiers.
-       Sous thématique : à chacune des thématiques sont associées des sous thématiques permettant de mieux définir la donnée.
-       Date de mise à jour
-       Echelle d’utilisation : « 1/50 au 1/500 » OU « 1/1000 au 1/2000 » OU « 1/2000 au 1/5000 » OU « 1/5000 au 1/25 000 » OU « 1/25 000 et plus »
-       Utilisation préconisée : le référent inscrit ici s’il souhaite que le service de l’information géographique prennent des mesures particulières de confidentialité sur cette donnée. Si rien n’est indiqué, la donnée est consultable par tous les utilisateurs.
Pour les plans topographiques uniquement, deux critères ont été ajoutés pour permettre une recherche géographique des plans :
-       Nom de la commune (liste déroulante),
-       Nom de la rue (liste déroulante).

Un plan topographique est un plan au 1/200 ou 1/500, réalisé par un géomètre expert. Ce plan doit être géoréférencé et doit comporter un cartouche contenant au minimum la date du levé, le nom du géomètre, et l’échelle.

Un couche cartographique est une couche SIG (généralement un *.LYR) ou un fichier *.DWG différent d’un plan topographique, ou une image scannée et son fichier de géoréférencement….

3.2.2 Des fichiers de représentation organisés dans une arborescence thématique

Nous n’avons pas fait de distinction dans le traitement des données SIG et des données AUTOCAD (*.dwg). Elles sont stockées ensemble, sur le même serveur, dans une même arborescence.

Toutes les données cartographiques stockées dans ArcSDE sont accessibles via un fichier *.LYR au nom explicite. Ceci évite aux utilisateurs d’aller chercher la donnée dans ArcSDE via ArcCatalog, donc cela contribue bien à la simplification de l’accès à la donnée. De plus les fichiers *.LYR pointent bien sur des données en consultation seule, paramétrées à partir des privilèges ArcSDE, des rôles et utilisateurs ORACLE, donc aucun risque de mise à jour malencontreuse de la données.

Les *.LYR utilisés par la mise à jour sont rangés dans une autre arborescence, du même serveur. Ce sont alors les droits WINDOWS appliqués aux répertoires, associés aux rôles et utilisateurs ORACLE qui sont utilisés pour garantir les droits d’accès aux données.

Enfin, les fichiers *.LYR permettent de définir une ou plusieurs représentation de chacune des couches. Ce qui permet à des utilisateurs non spécialistes de la cartographie de construire une carte simplement, sans se soucier (ou presque) de la symbologie.

4. L’OUTIL DE SAISIE ET DE CONSULTATION DES METADONNEES

Cet outil constitue « la partie visible de l’iceberg ». En effet, pour de nombreux utilisateurs, cet outil a constitué la partie visible de notre projet.

Deux nouvelles fonctionnalités ont donc été ajoutées à notre intranet / extranet de consultation des données du SIG Intercommunal. La partie « Catalogue » est accessible à tous, par contre la partie « Saisie » n’est accessible qu’à certains groupes d’utilisateurs.

Dans la partie « Saisie », donc avons dû là aussi mettre en place des protection, de façon à ce que par exemple les membres du groupe « Transport » ne puissent pas supprimer ou modifier les fiches de métadonnées du groupe « Assainissement ». Chaque groupe ne peut donc créer des fiches que dans les thématiques / Sous thématiques qui lui sont autorisées.

Interface de recherche d’une couche cartographique

Résultat de la recherche d’un plan topographique

CONCLUSION

Ce travail autour de l’organisation des données géographiques était devenu nécessaire au bon fonctionnement du SIG dans l’agglomération. Après une année de travail, ces nouveaux outils et ces nouvelles pratiques sont mis en production depuis février 2007. Les principales difficultés auxquelles nous nous sommes heurtées n’ont pas été des difficultés techniques, mais plutôt des difficultés organisationnelles. Le fait de déplacer, de regrouper les données, a nécessité un travail important de la part de tous les utilisateurs, tous les *.MXD produits étaient à refaire ! Ce fut une réflexion extrêmement enrichissante, qui va permettre au SIG d’agglomération de poursuivre sa croissance.