Le portail francophone de la géomatique

Bonjour,

Pouvez vous m'expliquer ce qu'est un SIG sans base de données ?

La confusion récurrente entre système d'information géographique et logiciel SIG ...

J'ajouterai qu' ACCESS n'est pas un vrai SGBDR, et qu'il vaut mieux se connecter à PostGis plutôt qu'à PostGresql uniquement.

Bonjour,

je suis complètement d'accord avec le message de Jean-Michel. J'emets simplement une réserve concernant les SIG "mono-utilisateur" ou assimilé. Il est important de prendre en compte le nombre d'utilisateurs, car je ne suis pas parsuadé qu'il faille investir en temps (open source) et/ou en argent (solution payante type Oracle ou SQL server) dans un SGBDR de competition pour 1 ou 2 ou même 3 utilisateurs... Après c'est sur que c'est plus propre mais une géodatabase fichier (dans le cas d'ESRI) ou une base Access va peut-être suffire.. c'est la limite du truc, et ça s'appelle la rentabilité (temps passé Vs gain financier ou fonctionnel)

Cdt

Benulti, Jean-Michel et Christophe,

Omettre le mot "logiciel" devant SIG m'a été fatal alors que pourtant, je partage la même définition des SIG que vous et ne fait aucune confusion entre logiciel et SIG. Les fois où j'ai du apprendre les bases du SIG à un quelqu'un j'ai toujours commencé par rappeler ce que sont les SI.

Bref, là où je me suis peut-être mal fait comprendre, c'est qu'entre se contenter d'une base de données fichier ou bien passer sur Postgres/postgis, il y a effectivement beaucoup d'investissement en temps. Et en bureau d'étude, le temps c'est de l'argent...

Du coup, étant entendu qu'un logiciel SIG n'est rien sans une base de données, quelque soit sa forme, qu'est-ce qui motive le passage de l'un à l'autre ? du fichier à Postgres ? Je vous ai donné mes raisons, mais j'aurais aimé avoir celles de ceux qui ont de l'expérience et qui se sont posés cette question en début de projet.

Merci !

Bonjour,

Voici des exemples plus concrets.
Personnellement, je pense que le fait d'avoir à partager des données et à les maintenir proprement oblige à passer par un SGBDR tôt ou tard.

En effet, si dans le bureau d'études, vous êtes trois et que chacun a son fichier SHP de son côté, ça va être compliqué car un jour, l'un des chargés de mission va changer la structure et/ou modifier des attributs. Si c'est pour un besoin ponctuel, la gestion fichiers est OK; tu fais ta "cuisine" de ton côté.
A l 'inverse, imagine par exemple que tu as fait un relevé de terrain et que vous soyez plusieurs à noter, pendant 6 mois. Pour consolider, tu utilises un SIG bureautique genre Quantum GIS pour te connecter à la base et chacun fait sa saisie pour mettre à jour son relevé. Tu as à la fin, une donnée à jour et maintenue. Si tu as un fichier, tu copies/colle pour donner à ton voisin à chaque modification et tu maintiens comme ça? Pas sûr!!

Tu peux aussi avoir besoin d'une application web pour partager en visualisation ta donnée mise à jour. Cette application probablement consommera de la donnée venant d'un SGBD alors qu'avec un fichier même si c'est faisable, ce n'est pas simple de le manipuler aussi simplement qu'une base de données (le "pouvoir" du SQL)

Pareil, tu veux faire des traitements réguliers du type, changer le format date mal saisi par tes collègues, tu vas pouvoir lancer une requête SQL automatiquement pour faire cette correction alors qu'avec un fichier, tu vas ouvrir ton SIG bureautique chaque fois une fois par semaine pour ça.

Si tu as un fichier, selon le format, si dans ta structure, tu as une licence Mapinfo, ton voisin, ArcGIS et que le dernier utilise Quantum GIS, soit tu prend  du shp et tu te prives des géodatabases ESRI (en perdant les relations et le côté un fichier pour plusieurs tables), soit tu perds l'analyse thématique qui est stockée dans ton fichier TAB Mapinfo (ce dernier contient des styles pas que de la donnée) soit tu te dis on bosse avec PostGIS pour partager notre donnée pour ne pas avoir des copies de copies de fichiers dans la nature

J'espère que ces exemples t'auront éclairés.

Cordialement

ThomasG

Bonjour,

J'ajouterai deux avantages pour les solutions SGBDR Serveur vis à vis des SGBD fichier de type Access.

Le premier est que, comme cela a déjà été dit, tu peux stocker un volume très important de données. Donc plutôt que d'avoir une multitude de base thématique ou par projet, tu peux tout mettre dans une seule base serveur. Du coup, toutes tes données sont complètement réutilisables /(croisable). Donc si tu es en serveur tu ne risque pas de prendre des liens entre les fichiers parce que ceux-ci sont déplacés par exemple.

Le second avantage est que tu peux gérer toute la logique de ta base de données coté serveur.  Par exemple si tu veux stocker  les dates de saisie ou de modification des données, insérer des champs automatiquement, etc... tu gères cela au niveau du serveur. Après peu importe le logiciel qui te servira à modifier tes données (Access, Qgis, appli Web,....), les éléments "logiques" seront gérés au niveau de ta base de données et non plus au niveau du client. Ainsi tu pourras avoir des données propres qui respecte bien ton modèle sans trop te soucier du logiciel client

Par ailleurs, sur le rapport investissement formation pour le libre et prix des licences pour le propriétaire. Il ne faut pas non plus oublier qu'avec des licences propriétaires il y a aussi des temps de formation et peut-être aussi des temps de prestation de votre fournisseur.

Cordialement

Christophe

Messieurs membres du bureau, messieurs modérateurs,

À vous écouter, la donnée SIG ne peut qu'être sous forme de base de données gérée par un SGBDR. Le jeu de données sous forme de fichier n'existe que pour l'échange, le transport d'une base de donnée à une autre, et encore si je le retrouvais je rappellerais ici un article prophétisant le remplacement du fichier shapefile par une base fichier SpatiaLite.


Connaissant le cadre de travail de certains d'entre vous, l'intérêt de la base de données est plus qu'évident.

Mais tous ces logiciels SIG que nous utilisons tous les jours sont prêts à l'emploi pour des jeux de données fichier, un glisser-déplacer et une couche est crée, alors que certains logiciels peinent à être compatible avec tous les SGBD spatiaux disponibles sur le marché (oui, y a qu'à prendre PostGIS), et lorsqu'il faut utiliser les données, c'est tout de suite plus compliqué que cliquer sur une icône et la glisser dans l'application SIG. Certes ce n'est pas beaucoup plus compliqué, il y a beaucoup d'avantages.


Si en fin d'études géomatique un stagiaire ne sait pas qu'il faut forcément utiliser une base de données, c'est qu'il n'a pas écouté en cours ? Ou bien la base de donnée SIG sous forme de fichier pour chaque jeu de donnée, accessible sur un répertoire réseau unique dans le cas de partage des données, c'est quelque chose qu'on apprend toujours en formation initiale pour certaines raisons pertinentes ? Ou bien les formations initiales ne devraient pas enseigner ces hérésies que sont les SIG avec des jeux de données hors des bases de données gérées par des SGBDR ?



Je trouve la question intéressante, j'aimerais trouver autre chose que des arguments d'autorité.

Mais Pat, je suis cool.

Si j'ai fait cette introduction un peu formelle, c'est juste pour rappeler qu'à voir défiler toutes ces personnes de l'association on a bien ici ces messieurs les professionnels expérimentés dont Samy demandait l'avis, mais que par la même occasion, les environnements de travail sont surement différents d'un bureau d'étude utilisant occasionnellement l'information géographique (sinon, ce n'est pas un stagiaire qui a la gestion de toute la base géographique).


Pour rappel, on ne voit pas tous ces jolis avatars qui peuvent dédramatiser ces marques distinctives "modérateur", "membre du bureau". Et donc ces marques distinctives donne du poids à tous ces points de vue et arguments qui deviennent des arguments d'autorité d'une certaine façon, surtout lorsque le même message est répété de manière quasiment identique par toutes ces personnes différentes. (Mais ça, on en a déjà parlé, ce n'est qu'un rappel)


Et pour soulever l'éventuelle indépendance entre un modérateur et un expert du domaine, quelqu'un qui s'investit dans la modération ou l'administration d'une association, il a suffisamment d'intérêts et de pratiques lié à ce domaine pour que la valeur de son point de vue soit un minimum supérieur à un membre lambda avec peu d'interventions.




Nous qui sommes dans un cadre différent, notre expérience est-elle valable, pertinente ?

Je trouve juste qu'il y a une grande différence de ton entre cette évidence martelée sur une dizaine de messages, base de données gérée par un SGDBR, et les offres logicielles ainsi que les formations à ce sujet.

Bonjour,

Cela dérive un peu par rapport à la question initiale, mais je me permets à titre privé d'éclairer un peu ma vision du SIG en vous proposant un extrait d'un rapport qui m'a été commandé il y a quelques temps.

Christophe, j'ose faire une synthèse, voir même une simplification, de l'extrait dont tu nous a fait bénéficié :

Si les données reposent sur un modèle assez homogène, simple, l'extraction des données par le logiciel consommateur (le client) peut se dispenser de système.

Bonjour,

Oui ! Tu m'as bien lu. Mais dans ce cas et ce n'est pas qu'une question de sémantique, le S de SIG ne veut plus rien dire. La géomatique est une science jeune, un peu plus jeune que l'informatique. Pour faire une comparaison un peu rapide, l'utilisation d'un logiciel SIG (c'est le terme consacré employons le) en connexion directe avec des fichiers "à plat" par rapport à un Système d'Information Géographique c'est un peu comme faire de l'analyse procédurale versus analyse objet en génie logiciel. Les deux approches sont bonnes, tout dépend de ce que l'on veut faire.

Petite remarque, la donnée commune et basique très répandue dans le monde du logiciel SIG qu'est le Shape est déjà une "base de donnée " ... DBase III.

Qu'en est-il pour les BD décisionnelle?

Est ce qu'une collectivité peut se permettre de migrer vers une telle organisation?

Et quels sont les liens "standards" vers un SIG?

Dernière modification par luern (Wed 03 April 2013 11:47)

Pardon?

Salut à tous,

Je n'ai pas réagit jusqu'à maintenant mais ai lu attentivement chacun de vos postes.

Vos commentaires me sont très utiles et je vous remercie vraiment de cet échange...Vous donnez un sacré coup de pouce à ma réflexion pour ce stage, et j'espère que ça réponds à d'autres qui se sont posés les mêmes questions !

Effectivement, vu la demande en carto/analyse, refondre le SI sera sans doute beaucoup trop chronophage et dangereux surtout si le passage de flambeaux est fait dans l'urgence. Pourtant, les avantages sont effectivement nombreux et répondent à des vrais problèmes de sécurité et d'optimisation ici...

Je pense mettre de l'ordre dans les données couramment utilisées, construire une base Access et surtout faire des formations pour instaurer un protocole rigoureux d'écriture et de rangement des données.

Reste à voir comment tout mettre en ordre sans exploser tous les .WOR ou .qgs importants, sans supprimer les données qu'on croyaient obsolètes et qui finalement ne l'étaient pas...

Au boulot !

Il existe des systèmes de gestion de documentation (appelé GED ou Gestion électronique des documents) qui rassemblent toutes les données dans un serveur et les données utilisées sont rapatriées à la demande sur le poste de l'utilisateur. En cas de modification, des mécanismes de verrouillage du fichier peuvent être mis en place, lorsque la modification est finie / approuvée / validée, elle est remontée vers le serveur, les utilisateurs mettant alors à jour leurs jeux de données.


Ça reste des systèmes compliqués où il faut respecter certaines marches à suivre. En plus les jeux de données SIG étant constitués de plusieurs fichiers, il y a des sources d'erreurs si le système n'est pas intégré dans le logiciel utilisé. Or je n'ai jamais entendu d'une telle intégration (puisque toute question de connexions multiples de ce genre passe d'habitude par une solution base de données.