Le portail francophone de la géomatique

Bonjour,

Avant les "cartouches spatiales" attachés aux SGBD, chaque éditeur avait sa propre façon d'organiser cette information .

Si cette information n'a pas vocation a être multi-accédée , elle est rangée sous forme de  fichiers (souvent un groupe de fichier rassemblant les coordonnées, les index spatiaux et les attributs alphanumériques des objets). Les formats de fichier les plus connus sont le Shape (ESRI), map/tab (MAPINFO) . Cette façon de stocker l'information est encore très répandue car la plupart des SIG (en tant que système d'information) n'ont pas à gérer une concurrence d'accès.

Si cette information a pour vocation à étre partagée avec une gestion de la concurrence d'accès  en écriture , les éditeurs utilisaient (et utilisent encore)  leur propre structuration de l'information spatiale au sein d'un SGBD relationnel. Intergraph s'appuie sur le modèle ou middleware  MGE , Esri sur SDE , MapInfo sur SpatialWare. Ces middleware propriétaires peuvent s'appuyer sur plusieurs SGBD relationnels.


Cordialement

JYG

Le SGBD n'est PAS "partie intégrante d'un logiciel SIG". Un SGBD géographique contient des centaines de fonctions géographiques, qui existent AUSSI dans les logiciels SIG (doublons).
Le bon usage d'un SGBDR spatial implique donc de "repenser le SIG" autour de la base de données.
Dans ce concept de "SIG distribués", le SGBD devient un élement central du système, et les logicels SIG ne sont que des logiciels clients, un peu comme un explorateur web est client d'un serveur web. Cette indépendance de la partie cliente et de la partie serveur permet - en théorie - d'associer le "meilleur client" au "meilleur serveur", pour peu que les échanges entre les deux soient normalisés. Celà permet également des évolutions asynchrones côté client et côté serveur.

La mise en oeuvre de tels SIG distribués est encore un peu limitée pour un usage avec certains logiciels SIG desktop comme clients, soit en raison d'une certaine réticence des éditeurs à concevoir des systèmes ouverts, soit parce que ces évolutions de leurs "vieux" SIG desktop n'est pas finalisée.

L'intérêt de concevoir un SIG autour d'une base de donnée est évident: requêtes mixtes spatiales/attributaires, gestion des droits d'accès/màj, simplification de la maintenance des données.
Le seul "inconvénient" est la nécessité de disposer des compétences requises pour mettre en oeuvre de tels systèmes partagés.

Mais à terme, il n'y a pas de raisons objectives pour que les SIG ne tirent pas eux aussi profit des progrès de l'informatique: les éditeurs "y vont", et les géomaticiens "de la vieille école" acquièrent progressivement la nécessaire "culture base de données".

L'autre évolution majeure des SIG est l'apparation de web-services normalisés (OGC), qui seront de plus en plus utilisés pour les transactions entre SBGDR spatiaux et logiciels SIG clients.

Cdt,
--
Daniel FAIVRE
Expert en géomatique
webmaster@texte-a-enlever.geomaticien.com

Bonjour,

Merci à Daniel Faivre pour sa réponse.
Si je comprends bien, la mutation des concepts de création SIG est la conséquence naturelle de la mutation objet des concepts de developpement.
Je ne pensais pas dans mon précédent message poser la question "à quoi sert un SGDB" pour un SIG, mais plutôt pourquoi ne pas se servir exclusivement d'un SGDB. Pour ma part mon produit gère l'ensemble des infos attributaires et spatial dans une base Access, et il m'avait parut naturel à l'époque de procéder comme cela (en l'état de mes connaissances une solution "libre" me plairait d'avantage).

Salutations

Christophe