Choix d’une stratégie de développement 65

Nous avons tout d’abord jugé que le développement complet d’un SIG n’était pas une solution optimale. Nous avons en effet estimé qu’il existe actuellement une large panoplie de géotechnologies (notre inventaire le démontrant) et que nous devons profiter des forces et avantages de ces produits. Nous avons ainsi jugé que les technologies SIG et CAO étaient suffisamment performantes et matures quant à la manipulation et la gestion de données spatiales, même si elles présentent chacune des lacunes quant à la 3D. Ainsi, en résumé, nous avions le choix entre nous attaquer directement au noyau d’un SIG afin de lui greffer une primitive volumique ou rajouter à un outil CAO certaines capacités de gestion, d’analyse et de diffusion des données.

En informatique, il est très complexe d’aller revoir les fondements mêmes d’une application lorsque les changements à apporter sont majeurs et n’ont pas été prévus lors de sa conception. On dit souvent d’une manière symbolique que dans le processus de développement d’une application, une modification apportée au moment de la conception coûte 1$, durant le développement coûte 100$ et durant l’implantation coûte 1 000$. Nous pensons donc qu’extensionner un SIG existant représente un travail colossal étant donné la nature des changements à apporter.

Lorsqu’on parle d’intégration d’une application existante à un autre système ou d’ajout de fonctionnalités à celles déjà existantes en respectant les fondements de cette application, on se trouve dans une situation relativement courante et de complexité généralement moindre que de devoir s’attaquer au cœur d’un programme. Les systèmes d’aujourd’hui étant souvent pensés et construits de manière évolutive et modulaire, leur structure se prête généralement bien à une telle intégration ou à de tels ajouts de fonctionnalités lorsqu’ils ont été bien construits à la base. De plus, il était essentiel pour nous d’avoir un système qui implémente une ou plusieurs des structures géométriques 3D présentées au chapitre précédant. Pour ces raisons, nous avons décidé d’extensionner un outil CAO existant pour lui ajouter certaines fonctionnalités de gestion et de diffusion de données 3D. Il était alors

important de sélectionner un outil CAO spécifique dit "ouvert" i.e. qui possède par exemple un API permettant de venir ajouter des fonctionnalités au système de base. Il était aussi important de choisir un outil CAO qui implémente une ou plusieurs structures géométriques identifiées comme intéressantes pour la représentation du territoire en trois dimensions.

Comme les outils CAO ne permettent pas, de manière native, le stockage des modèles au sein de bases de données, nous proposons de coupler le système à un SGBD. Ainsi, les modèles 3D pourront être stockés au sein de bases de données et on pourra tirer profit de tous les avantages que procurent les SGBD par rapport au stockage par fichier (sécurité et intégrité des données, accès multi-usagers, etc.). Et puis, comme nous avons privilégié la diffusion et l’interopérabilité, Internet et l’utilisation de standards ont été identifiés comme composantes essentielles. L’interopérabilité sera considérée tant au niveau de la structure, de l’échange et du requêtage des données. Ainsi, nous proposons le développement d’un SIG 3D suivant une approche de service Web standard. L’adoption d’une telle approche, contrairement à l’approche traditionnelle client/serveur i.e. un serveur Web publiant une page Web, offre plusieurs avantages. Le service Web n’impose pas à l’usager une interface graphique particulière, mais partage plutôt la logique applicative (le noyau fonctionnel de l’application), les données et les traitements par le biais d’une interface standard à travers le réseau local ou Internet. Par la suite, un développeur peut ajouter le service Web à une interface graphique comme un programme ou une page Web pour offrir des fonctionnalités spécifiques à un groupe d’usager. De plus, l’approche service Web présentant une interface standard, la communication entre différentes applications par l’intermédiaire de ce service ne demande pas de trop grands efforts d’adaptation et de programmation spécifique non réutilisable de part et d’autre. Finalement, comme les communications exploitent le langage XML, elles ne sont pas limitées à un système d’exploitation ou un langage de programmation spécifique. Cela signifie par exemple qu’une application Java tournant sous Linux pourrait très bien communiquer avec une application en .Net sous plate-forme Windows. Dans le cadre de l’architecture de SIG 3D que nous proposons, un service Web sera ajouté au système proposé afin d’offrir un service de partage de données spatiales et d’opérateurs spatiaux 3D à partir d’un réseau local ou d’Internet.

En résumé, nous proposons un SIG 3D construit sur la base d’un outil de modélisation 3D de type CAO couplé à un SGBD pour le stockage des modèles dans une approche de service Web. Apel présentait en 2004 un prototype de SIG 3D mettant en œuvre un service Web pour la diffusion des modèles géologiques 3D. Son système permettait l’accès en ligne à des modèles 3D stockés sous format XML dans un SGBD spécialisé dans le stockage XML natif à partir du client Gocad. Cet effort de Apel apportait des idées intéressantes et innovantes et a beaucoup inspiré nos travaux. Toutefois, le requêtage et le stockage des données de son système présentait certaines lacunes puisqu’aucune structure de données géométriques, ni spécification de service Web standard n’ont été utilisées. C’est particulièrement à ce niveau, soit celui des normes et des standards, que l’architecture du système que nous proposons se distingue de ce celui de Apel. En effet, nous proposons dans l’architecture de notre système l’utilisation de spécifications et de standards :

 Au niveau du service Web par l’adoption de la spécification WFS de l’OGC  Au niveau de la représentation et du transfert des données par l’adoption du format

GML

 Au niveau de la structure des données géométriques au sein du système par l’adoption du schéma spatial ISO 19107

Nous pensons que l’utilisation de ces standards favorisera grandement l’interopérabilité, ce qui permettra de faciliter l’accès aux données et diminuera la duplication des efforts notamment en favorisant la réutilisation de code lors du développement. Nous pensons que cela pourrait aussi aider à convaincre les organisations à adopter un tel système pour la gestion de leurs données géométriques 3D puisqu’un système s’appuyant sur les derniers standards en vigueur risque d’avoir une durée de vie plus longue ce qui peut faciliter la justification des efforts et des investissements que commande son développement.

En ce qui a trait au choix du WFS par rapport aux autres spécifications de services Web (comme le WMS, WCS), mentionnons qu’il est le seul de ces standards permettant d’extraire le modèle lui-même ainsi que ses propriétés descriptives afin d’avoir toute la latitude possible pour manipuler et interroger à sa guise le modèle au sein d’un outil performant tel un outil CAO. À terme, une spécification telle que le W3DS pourrait être

très intéressante pour un projet nécessitant avant tout la visualisation de modèles 3D et pouvant se contenter des capacités « limitées » d’un navigateur Internet. Lorsque l’interrogation, l’analyse et l’édition des modèles 3D sont nécessaires, l’accès aux données elles-mêmes (géométriques et descriptives) ainsi qu’à des opérateurs spatiaux tels que l’offre le WFS devient selon nous la meilleure option. Cependant lors du choix des technologies, cette spécification n’était pas encore disponible.