Le SIG est perçu de façon extrêmement positive dans l'agence par les différents interlocuteurs de l'agence, architectes-urbanistes, sociologues, géographes, géomaticiens, et pour l'ensemble de ces interlocuteurs, le SIG apparaît comme un outil important et largement utilisé.
- Il est reconnu pour sa richesse thématique, ses mises à jour régulières,
- il permet la production de nombreux plans, réalisés à partir des différentes couches disponibles
 
Néanmoins l'ancienne organisation des données,  ne permettait plus de garantir d'une part la qualité de la donnée, et d'autre part de permettre une organisation rigoureuse.
En effet, jusqu'au début de l'année 2008, l'ensemble des données étaient stockées sur un serveur de fichier avec une gestion des accès en lecture/écriture dont la gestion était confiée au service informatique.

Cette gestion avait depuis quelques temps montrait ses limites tant le nombre d'utilisateurs du SIG et des données géographiques n'avait cessé de croitre.
Au bout du compte, la plupart des utilisateurs disposait de la quasi-totalité des droits sur l'ensemble des fichiers géographiques de l'agence.
Cette situation remettait en question la qualité de la donné, puisque le risque de mise à jour, et de suppression était réel.

D'autre part nous avions constaté que nos utilisateurs ne connaissaient pas bien les données disponibles à l'agence, et quand ils les connaissent, ils avaient parfois du mal à les retrouver de manière simple.
Cette mauvaise connaissance des données disponibles et de leur emplacement avaient pour résultat une duplication des données sur les disques personnels des utilisateurs avec pour conséquence une perte de la qualité de la donnée.
 
Tous ces arguments, nous ont permis de faire adhérer l'ensemble des utilisateurs à cette réorganisation des données, ainsi qu'à une meilleure mutualisation des données.

Afin de réussir au mieux cette migration, notre réflexion a tout d'abord porté sur l'organisation des données sur le serveur ArcSDE.

En effet, l'A-urba est non seulement un producteur de données géographiques, mais bénéficie également d'échanges de données au travers de convention avec les principaux partenaires (Communauté Urbaines de Bordeaux, Conseil Général de la Gironde, etc .....)
Afin de respecter au mieux cette spécificité, la nouvelle organisation se doit de respecter ce constat. Le serveur ArcSDE, comporte donc deux types de données
- des données thématiques
- des données issus de partenaires
 
Les données thématiques sont donc organisées selon l'arborescence présentait dans le schéma suivant.

Cette organisation, qui s'appuie sur la thématique URBAMET, n'est pas figé et a vocation à évoluer en fonction des besoins.
 
En réalité au niveau de la base de données ArcSDE, chaque thématique, ainsi que chaque données issues de nos partenaires correspondent en fait à un utilisateur au sens base de données.


Ces utilisateurs sont définis grâce aux privilèges qu'accorde ArcSDE sur les données, et aux différents rôles que nous avons défini dans SQLServer.

Comme le montre la figure suivante, le nombre est conséquent et permet des répondre à nos différentes thématiques.

Le passage de l'ensemble de nos données sur un serveur ArcSDE a eu comme principale conséquence la sécurisation de ces dernières.
En effet, à moins de disposer des fichiers binaires sur son poste, et de maitriser la syntaxe des lignes de commandes, ou d'utiliser la seule licence ArcEditor disponible à l'agence, les différentes opérations de  mise à jour des données (création, suppression) sont désormais impossible.

Cette contrainte a été vu pour nous comme un atout dans notre volonté de mieux gérer nos données.
Ainsi ce rôle d'alimentation de la base SIG avec de nouvelles données, est réservé au seul administrateur du SIG qui à la charge de l'ensemble des opérations de mise à jour
 
Cette opération d'alimentation de la base de donnée SIG, s'effectue en accord avec les personnes ayant été identifié comme responsable d'une ou plusieurs thématiques.
 
Ces personnes ont donc la charge de la collecte, de la mise à jour de données, sur une ou plusieurs thématiques précises.
 
Afin de migrer ces nouvelles données sur le serveur, elles sont placées dans un espace de stockage temporaire, comme le montre la figure suivante,

structuré sous la forme de géodatabases fichiers qui se rapprochent en terme de structuration des géodatabases de type ArcSDE.
Cette étape permet notamment de définir de manière correcte le système de projection, de supprimer les caractères spécifiques, et de respecter les règles de nommage en vigueur.
 
Une fois ces différentes opérations effectuées, le rôle de l'administrateur consiste à transférer ces données des géodatabases dites tampons vers le serveur ArcSDE.

Les données une fois intégrées sur le serveur ArcSDE, doivent pourvoir être accessible par tous, à l'exception des données pour lesquelles nous disposons de convention restreinte.
 
Parallèlement aux différents utilisateurs au sens ArcSDE et SQLServer, nous avons décidé de mettre en place un utilisateur dit « générique » qui ne dispose que des droits de lecture des données.
Cet utilisateur est définit comme Data Base Reader au niveau de SQLServer, et bénéficie des privilèges accordés par l'administrateur sur chaque Jeu de classe d'entité de la base ArcSDE.
Cette attribution s'effectue en concertation avec le gestionnaire de la donnée, qui définit les accès aux données.

Cette organisation mise en place, la mission SIG a du réfléchir à la possibilité de partager l'information disponible sur le serveur SIG.


En effet, l'A-urba ne dispose que d'un nombre limité de licences ArcView (8 licences flottantes) qu'elle souhaite réserver à des profils d'utilisateurs maitrisant déjà les SIG.

La mission s'est donc naturellement tourné vers une solution de déploiement de viewer, ArcExplorer afin d'offrir la possibilité aux utilisateurs d'explorer, sans risque de commettre des erreurs de manipulation, les données du SIG.
 
Cet outil, aux performances cartographiques limitées, permet d'offrir une certaine autonomie aux utilisateurs (architectes, urbanistes), afin qu'il puissent ébaucher leur études cartographiques avant de se rapprocher de l'Atelier de Production Graphique, au  sein du duquel existe des compétences SIG.
 
Ce viewer offre des capacités limitées en matière cartographique mais également en matière de mise en page et d'impression.
Or la plupart des documents produits au sein de l'agence ont une vocation à être imprimé.

Aussi afin de répondre au mieux aux besoins de partage de l'information, l'agence s'est doter de l'extension Publisher, afin de transformer des documents réalisés avec les produits de la gamme ArcGIS en un document lisible par tous grâce à l'applicatif ArcReader.
 
Afin de permettre un partage simplifié, l'ensemble de ces projets dits bibliothèques qui ont un intérêt commun et donc une vocation à être partagé sont stocké sur un serveur dédié, comme le montre la figure suivante.

En outre afin de garantir une qualité des projets proposés, chaque producteur du document nomme son document en y ajoutant ses initiales afin de permettre aux utilisateurs de ce document de lui signaler tous problèmes sur le document ( problème de connexion aux données présentes dans le document, mise en page erronée, etc.....)

Dans un souci d'uniformisation des données qui sont publiées, il a été convenu de partager le plus souvent possible des fichiers de symbologie.

Pour cela tous les fichiers de symbologie (*.LYR) ont été regroupés sur un serveur spécifique,

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 SQLServer, 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, 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.

Ce travail autour de l'organisation des données géographiques était devenu nécessaire au bon fonctionnement du SIG de l'agence d'urbanisme de Bordeaux.
Après un gestation difficile, tant sur le plan de l'organisation à mettre en place que sur le plan de la migration des données, la nouvelle organisation semble trouver l'adhésion de tous grâce notamment à la mise en place des outils de visualisation des données et de projets.
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 !


Il subsiste néanmoins quelques points de blocage comme une absence de dictionnaire de métadonnées accessible à tous permettant d'offrir à tous une vision des données disponible à l'agence.


Parallèlement à cela la mission SIG travaille actuellement à la mise en place d'un éditeur de métadonnées simplifié, regroupant les principaux champs nécessaire à l'identification correcte des données.


Ce dictionnaire est la prochaine étape de partage de l'information, qui sera accessible directement depuis l'Intranet, sans voir recours à des outils SIG spécifiques.
 
Sa mise en ligne est étroitement liée à la mise en place de l'éditeur de métadonnées prévue d'ici à la fin de l'année 2008.