GEOTOOLS

Une méthode pour la manipulation et la diffusion des données géographiques

GeoTools est l'aboutissement (provisoire) de deux décennies de pratique par les services techniques de la Communauté Urbaine de Lille dans la manipulation et l'exploitation de données géographiques.

L'objet de cet ensemble d'outils n'est certainement pas de concurrencer des produits commerciaux conçus dans la perpective d'équiper un poste de travail polyvalent qui permet au même utilisateur de prendre en charge complètement une application et d'assumer avec un maximum d'autonomie des tâches de conception, de saisie, d'analyse, et de mise en forme des résultats. Ce type d'utilisateur existe, bien entendu, au sein des collectivités, mais il s'avère qu'il est très peu représentatif quand l'utilisation et la maintenance des données géographiques s'est banalisée à tous les niveaux et dans chacun des domaines techniques.

Dans ce cas, le centre d'intérêt n'est plus l'application, mais la donnée géographique elle-même, qui doit être diffusée le plus largement possible, en vue d'être utilisée dans des applications aussi diverses que la gestion de l'urbanisme, l'entretien de la voirie, des réseaux enterrés, les transports en communs, les services de secours, etc...

Les principaux problèmes auxquels il faut répondre quand les données engrangées sont abondantes et que le nombre d'utilisateurs internes ou externes à la collectivité est important, réside alors dans la mise en oeuvre de modes opératoires diversifiés, dans l'adaptions des données aux différents métiers, dans la production de documents à grande échelle, et dans l'intéropérabilité avec un nombre croissant d'autres outils spécifiques, éventuellement commerciaux.

Geotools essaie de répondre à ces contraintes en mettant en place une plate-forme d'intégration sous la forme d'un circuit permettant aux données géographiques de circuler depuis les différentes structures d'accueil ou elles sont hébergées, vers d'autre structures, ou vers différents moyens de restitution, tout en proposant un certain nombre de fonctionnalités permettant d'accéder à ces données, de les recouper avec d'autres données non géographiques mais localisables, et d'adapter leur présentation aux besoins des utilisateurs, tout en tâchant d'instaurer un certain formalisme, de façon à faciliter la communication entre les différents domaines d'activité.

Les principaux composants de Geotools

• La bibliothèque Geotools proprement dite, propose des fonctions de lecture et d'écriture dans différents formats, des fonctions de conversions entre certains types d'objets, quelques opérateurs spaciaux, et enfin, une fonction très avancée de restitution graphique.
  C'est sur cette bibliothèque que sont basés les deux modules les plus importants du circuit: geoview, pour la récupération des données, quelque soient les structures ou elles sont conservées, et proddm, pour la construction automatique des documents graphiques.
• Un certain nombre de programmes, développés à partir de la bibliothèque de Geotools, peuvent être utilisés dans des scripts, le plus souvent sous forme de filtres.
• Une bibliothèque de couvertures géographiques répertorie les ensembles cohérents de données. Celles-ci peuvent être archivées sous forme de fichiers plats ou dans des bases de données relationnelles. Certaines couvertures peuvent être en réalité des scripts qui sont automatiquement activés par geoview au moment d'y accéder. Cette possiblité permet de faire reboucler le circuit, et d'injecter en amont des données géographiques enrichies dynamiquement.
• Des catalogues de représentations graphiques, structurés en domaines d'activité, permettent de définir des profils d'utilisateurs, et pour chaque domaine, de spécifier les rêgles de représentation des objets.
• Un langage de description de document, appelé DDM, permet de structurer le document en terme de fenêtres, de sous-fenêtres, de couches, de légendes, et de paramétrer son contenu et la façon de le représenter.

Le circuit des données géographiques avec Geotools

Un exemple d'application

La plupart des applications de Geotools sont dissimulées dans des couvertures logiques, et le système s'avère pratiquement inutilisable si on ne dispose pas d'une base de données géographiques déjà bien fournie. Celà rend difficile les démonstrations en ligne si un minimum de données ne peuvent pas être rendues publiques.

Heureusement, la CUDL a décidé officiellement que la base de données géographiques qu'elle gère devait être libre d'accès, ceci afin de répandre l'utilisation de ses structures d'appui auprès de tous ses partenaires. Il en est résulté une circulation beaucoup plus fluide des informations relatives à l'état du patrimoine, et des économies sur les études et sur sa maintenance qui ont largement dépassé les coût de gestion de cette base de données.

La diffusion de ces informations a été mise en ligne récemment, et l'application GEODOC permet à tout internaute de construire un script DDM, dans lequel il spécifie la zone qui l'intéresse, les couvertures qu'il souhaite et le format numérique dans lequel il faut générer le document.

Le script est ensuite envoyé par courrier électronique à un robot situé sur le réseau privé de la CUDL qui traite la demande et retourne; également par courrier, le document au demandeur. Ce protocole a été adopté afin d'éviter de placer toutes les données géographiques dans la zone publique, et afin de garder le contrôle sur la consommation des ressources du système.

GEODOC tourne actuellement sur un PC doté d'un Celeron à 300Mhz, de 128Mo de RAM et d'un disque dur IDE. Les temps de réponses sont encore raisonnables, compte tenu des traitements effectués systématiquement par Geoview et Proddm à chaque sollicitation d'une nouvelle image.

Le bilan

Il est difficile de dresser un bilan qui soit spécifique à Geotools, parce que la grande majorité des résultats obtenus jusqu'ici sont essentiellement dûs à une étroite collaboration entre l'ensemble des utilisateurs et le service informatique, laquelle a été initiée depuis plus de vingt ans.

Néanmoins, Geotools a permis de formaliser l'expérience acquise, et sa conception fut l'occasion de mieux discerner les métiers à impliquer dans l'exploitation et la valorisation des aspects géographiques attachés aux informations manipulées par une collectivité.

Parmi ces métiers on peut distinguer:

• Le métier d'opérateur dont la tâche est de créer et de maintenir les structures géographiques de base. Pour celà il applique les méthodes et utilise les outils les mieux appropriés, selon les contraintes liées à la couverture dont il est responsable.
• Le gestionnaire de données, en charge de repérer les relations entre les informations gérées par les diverses applications. Il est le mieux placé pour déclarer, par exemple, les couvertures extractibles des SGBDR, et pour rédiger les vues logiques adéquates.
• Le développeur spécialisé dans la rédaction de scripts. C'est lui qui adapte les fonctions avancées de Geotools aux besoins des utilisateurs, chaque nouveau script devenant une sorte d'extension du système, et éventuellement une nouvelle couverture.
• L'assistant pour la construction d'un document. Il ne s'agit pas seulement de bien connaitre toutes les subtilités de DDM, mais aussi de porter conseil sur la pertinence d'une demande, et sur la meilleure façon de mettre en évidence les informations. Pour celà il devra aussi intervenir sur les catalogues de représentation, voire, encore plus en amont, sur la nomenclature des classes d'objets.
• Et enfin, puisqu'un projet informatrique n'est vraiment terminé que lorsqu'il est abandonné, le programmeur en charge de débugger et d'étendre les fonctionalités de la bibliothèque. Sa fonction n'est certainement pas négligeable, dans la mesure ou il peut modifier certains comportements du système qui obligeraient, sinon, les autres utilisateurs à appliquer des astuces ou des méthodes de contournement coûteuses, récurentes, et beaucoup plus difficiles à maintenir. Evidemment, celà est possible uniquement parce que les sources de Geotools sont disponibles.

On remarque que certains de ces métiers ne sont pas spécifiques aux techniques de l'information géographique. Le personnel impliqué peut donc s'investir dans d'autres secteurs. Cette compétence transversale, bien que contrariant la tendance actuelle à rendre l'utilisateur final aussi autonome que possible, est néanmoins un vecteur de diffusion de l'information à ne surtout pas négliger sur le plan organisationnel.

Le futur

Il est envisagé deux sortes d'évolutions du système Geotools.

Evolution de l'étendue de son d'utilisation.

On sait qu'un projet trouve avant tout sa force dans le nombre de ses utilisateurs, et dans le nombre de ceux qui peuvent faire évoluer ses spécifications et ses fonctionalités. Pour celà il est souhaitable que Geotools puisse être exploité et amélioré à l'extérieur de la CUDL. Etants donnés les droits moraux attachés à Geotools, il n'est pas encore possible de le diffuser publiquement, mais il est d'ores et déjà possible que des collectivités ou d'autres organisations intéressées contactent le service informatique pour envisager ensemble une collaboration.

Dans la même perspective, les prochains développements se concentreront sur l'interopérabilité de Geotools avec les autres outils spécialisés dans le traitement des données géographiques (pompeusement appelés SIG pour Systèmes d'Information Géographiques). ll s'agit, en amont, d'encapsuler les bases de données de ces outils dans des couvertures dynamiques, et, réciproquement, de les alimenter en aval. Une première expérience sera lancée en priorité avec l'excellent outil d'analyse que constitue GRASS, qui a d'ailleurs largement inspiré certains choix techniques de Geotools.

Evolution de l'étendue de son implémentation.

Puisque Geotools est avant tout conçu pour faire circuler l'information géographique, il est logique que ce circuit puisse traverser les murs des collectivités, et permette de reccueillir en une seule requête des données gérées en des lieux différents. Geoview peut facilement être utilisé dans un CGI, et envoyer sur Internet, via HTTP, les objets qu'on lui demande de collecter. Par ailleurs, puisque certaines couvertures sont en réalité des scripts, il est tout à fait envisageable que ces derniers interrogent un serveur HTTP distant. Dans le même ordre d'idée, on peut étudier la façon d'implémenter les méta-données, telles que les catalogues de couvertures, les index et les catalogues de représentation, dans des serveurs LDAP.
Une telle architecture permettrait d'améliorer la collaboration entre la collectivité et tous ses partenaires intéressés par un meilleure maitrise du territoire, et permettrait aussi à des groupes de petites ou moyennes communes de travailler collectivement sur une base commune, continue et cohérente.