Le portail francophone de la géomatique

Bonjour,

Oui, c'est possible.
PostGIS est une base de données à composante spatiale ainsi que Spatialite, BDD plus légère à mettre en place.
PostGIS et Spatialite ont un fonctionnement très différent.
Spatialite est un format de stockage intermédiaire entre les fichiers plats géographiques et les SGBDR à composante spatiale

QGIS est à l'origine un visualiseur de données PostGIS. Il gère donc très bien les connexions aux BDD PostGIS.
Le module SPIT permet de verser des données présentes au format ESRI SHP vers le SGBDR.
Et il est relativement aisé de se connecter à une BDD PostGIS et de modifier des objets stockés dans la base.
Il y a énormément de plugins QGIS liés à PostGIS..

De même, QGIS gère aussi bien les connexions aux BDD Spatialite.

Dernière modification par baobazz (Thu 01 July 2010 11:15)

Difficile d'exporter une entité géométrique autre que le point dans une ligne excel, pour des polygones ou des lignes vous devrez soit créer des centroïdes ou multiplier les lignes d'enregistrements par le nombre de sommets. QGIS peut rajouter des colonnes x/y, surface, périmètre à vos fichiers *.shp.

Sinon il n'y pas besoin de s'y connaître en SQL pour par exemple faire une recherche simple dans la table attributaire, je vous laisse compulser le manuel à ce sujet.

En fait, tu peux exporter tes couches en ESRI. Cela génère des fichiers dbf qui sont lisibles sous OpenOffice Calc. Tu peux les modifier au sein de l'application voire ensuite les enregistrer au format Excel..

Salut,

Je ne sais pas comment marche filemaker, mais ne serait pas plus simple de combiner tous les enregistrements qui correspondent à un même polygone.
Ensuite tu exportes ta couche dans le format voulu (shapefile par exemple), et tu pourras la modifier à loisir dans QGis.

NB: J'ai une utilisation quotidienne de Qgis, mais je n'ai jamais eu à faire ce type de manip donc c'est juste une idée, et je ne sais pas si elle est bonne! Dans tous les cas je pense que c'est moins de travail de faire le tri avant la conversion vers Qgis (à vérifier).

ericire > il n'est à ma connaissance pas possible de stocker la géométrie (ex. : l'emprise d'une parcelle) d'une entité dans une base FileMaker, car celui-ci ne gère pas ce type de données, car il ne dispose pas de cartouche spatiale. Soit vous remplissez un champ texte avec les données au format WKT (ex. : POLYGON(10 10, 20 10, 20 20)), mais je doute de la simplicité de mis en oeuvre, soit vous utilisez une couche géométrique avec un identifiant qui permet de faire une relation vers tables FileMaker, soit vous passez à une vraie base de données gérant les géométries spatiales nativement (spatialite, postgis, SQL server, etc.) en continuant d'utiliser vos fiches FileMaker via une connexion JBDC/OBDC.

J'ai peut-être mal compris votre situation, mais je pense que poursuivre dans la voie du tout FileMaker ne soit pas réalisable.

Concernant l'aspect de conservation,  la totalité des SGBD que j'ai cités s'aligne sur les normes industrielles établies par l'OGC. Vu le nombre d'acteurs engagés et la masse des déploiements effectués, je peux t'assurer qu'enregistrer tes données au format SQL est plus pérenne que de les confier à FileMaker. Pour rappel, FM a fini par intégrer le support du langage SQL à partir de la version 10, mais aussi l'accès à des bases SQL externes (ESS) ce qui permet de garder les formulaires existants pour l'édition et la consultation des données attributaires sans infliger des requêtes SQL à vos utilisateurs.

Il est déraisonnable de vouloir stocker les entités géométriques au sein d'une base FileMaker, cela peut se faire en suivant le format WKT mais son exploitation sera ardue du fait de l'absence de pilotes logicielles pouvant exploiter ces donnes depuis FM. Ce que je conseille dans votre situation c'est l'emploi de formulaires FM pour l'édition et la consultation des données attributaires dans une base telle que SQLite (qui suit un principe similaire à FM, à savoir un seul fichier, à la nuance que ce fichier peut stocker plusieurs tables) via une connexion OBDC, mais pas de retour visuel géographique direct dans FM. Tel que je le comprends l'ESS de FM permet de faire des relations entre des tables FM et des tables SQL (dans la limite du possible selon le schéma relationnel de votre base [unicité des clés de vos niveaux, etc.]), vous pouvez décider de stocker que la géométrie dans la base SQL et de créer des "vues" pour visualiser dynamiquement vos sélections sous QGIS. Cela demande que vous vous formiez un minimum au principe du SQL et la gestion d'une telle base, mais cela permettrait de conserver les outils et les habitudes de vos utilisateurs tout en bénéficiant des relations 1-n.

A moins que FM n'intègre une cartouche spatiale dans sa prochaine version c'est, à mon sens, la manière la plus élégante d'opérer.

L'autre choix c'est de garder votre structure actuelle et de faire un ou des fichiers de géométries (p. ex. des *.shp) ayant seulement des colonnes contenant les numéros d'US,de structure, de niveaux (une colonne par type). L'utilisateur fait ses requêtes sous FM, exporte la sélection résultante au format *.dbf et opère une jointure entre ce dbf et le fichier de géométrie pour observer la répartition spatiale. C'est la voie demandant le moins d'acquisitions de nouvelles compétences pour vous et pour eux, c'est aussi la plus laborieuse sur le long terme, chaque fichier "joint" est une image à un moment T d'une problématique et nécessitera la répétition de la manoeuvre pour être à jour.