Stockage des GEOMETRIES about geonature HOT 9 CLOSED

En effet, PostGIS (la cartouche spatiale de PostgreSQL) permet de stocker la géométrie des objets (points, lignes ou polygones) directement dans la BDD (http://www.postgis.fr/chrome/site/docs/workshop-foss4g/doc/introduction.html).
Cela permet de combiner des requêtes attributaires et spatiales, d'afficher les données sur un carte (dans une application WEB ou un SIG comme QGIS).

Ces données peuvent être stockées selon différents systèmes de coordonnées comme tant tous les SIG (http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_coordonn%C3%A9es_%28cartographie%29).

Chaque système de coordonnées a un code (SRID).
2154 = Lambert 93 (système de référence au niveau français)
3857 = WGS84 Pseudo Mercator (système mondial utilisé par Google Maps...)

Dans ContactFaune de GeoNature, l'application de saisie renvoie à la BDD les géométries en 2154, les stocke dans le champs the_geom_2154 de t_fiches_cf puis le trigger insert_fiche_cf() les reprojecte aussi en 3857 pour remplir automatiquement le champs the_geom_3857.
Une fois la donnée intégrée dans les tables du protocole (ContactFaune dans ce cas), le trigger synthese_insert_releve_cf() alimente automatiquement la Synthese.

Mais la logique est bien de saisir (ou intégrer massivement) les données au niveau du schema du protocole (ContactFaune, Invertébrés, FloreStation, Historique, MonProtocoleX, Mon ProtocoleY...) pour qu'elles soient ensuite intégrées automatiquement dans la SYNTHESE.

Il existe différents moyens pour importer des données spatiales dans PostGIS. La plupart du temps, on part du SHAPEFILE (format de fichier SIG le plus courant).

• Depuis QGIS (http://mesange.educagri.fr/htdocs/sigea/supports/QGIS/distance/perfectionnement/M05_SQL_BDD_gen_web/co/10_N2_Gestion_Tables_Postgis.html)
• Avec des plugins dans PgAdmin - http://blogbi.asi.fr/2012/08/30/charger-des-donnees-spatiales-dans-postgis/
• En ligne de commande avec OGR2OGR - http://www.portailsig.org/content/comment-importerexporter-des-donnees-vers-une-base-de-donnees-postgresqlpostgis

from geonature.

Il faut stocker les données brutes dans le schéma du protocole.
Soit un protocole déjà existant dans GeoNature, soit un autre protocole pour lequel vous créez vos tables.

Le plus simple pour intégrer les données dans PostGIS étant de passer par QGIS.

• Ouvrir vos données dans QGIS (depuis un shapefile ou un CSV si vous avez un tableau avec des X et Y)
• Utilisez le Gestionnaire de BDD de QGIS pour importer les données dans PostGIS (dans une table existante ou en créant une nouvelle table).
  Attention, dans les liens ci-dessous, ils parlent de Plugin dans QGIS. Cependant dans les nouvelles versions, ces fonctionnalités ont été intégrées dans QGIS (Base de données / Gestionnaire de bases de données).
  Pour pouvoir utiliser une connexion à une base de données via dbmanager de QGIS il faut au préalable avoir créé la connexion à cette même base au travers du gestionnaire de connexion PostgreSQL (ajouter une nouvelle couche PostGIS)

from geonature.

Le champs the_geom_2154 a été renommé en the_geom_local dans la 1.9.0 qui gère le multi-projection.

from geonature.

Je me permets de poser la question ici, suite à une réflexion que je me fais sur les géométries dans la V2 :

Etant donné qu'il va être maintenant possible (si j'ai bien suivi) de saisir des données rattachées à des polygones, est-ce que la synthèse va, pour chaque donnée d'un même polygone de saisie, dupliquer les géométries ?
Cela ne pose-t-il pas un problème pour le poids de la BDD qui risque d'augmenter rapidement ?

Ex. : un relevé de 100 espèces sur un "patatoïde" de 30 noeuds, va devoir stocker l'équivalent de 3000 noeuds ?

Ou alors, la table synthèse est-elle en lien avec une table de géométries pour "factoriser" ce stockage ? (mais du coup, la synthèse n'est plus une "vue à plat" des données des protocoles).

Merci pour cet éclaircissement (en espérant que ma question soit claire).

A+

from geonature.

Oui c'est clair.
Dans les donnees sources au niveau du protocole on peut factoriser des géométries.
On le fait dans OccTax où on le stocke qu"une fois au niveau du relevé.

On va le faire dans les Suivid où les sites de suivi sont centralisés.

Mais dans la Synthèse on remet tout à plat. A priori.

from geonature.

Peut-être pourrait-on partir du principe que la synthèse ne stocke que le point (ST_PointOnSurface()) des géométries, afin de l'alléger ?
(sinon, peut-être un paramètre à gérer au niveau de chaque instance pour avoir le choix)

On le fait dans OccTax où on le stocke qu"une fois au niveau du relevé.

Ca c'est une bonne nouvelle, et c'était en fait mon inquiétude. Cool, merci tu me rassure ! :)

from geonature.

Je pense qu'il faut rester à plat dans la Synthèse pour que ça reste simple.

La question du poids ne sera pas un problème.

On en recause.

from geonature.

OK.
Dans tous les cas, libre à chacun de gérer la définition des géométries de la synthèse, avec un minimum d'adaptations SQL.

La question du poids ne sera pas un problème.

Je ne sais pas comment PostGreSQL stocke les données sur le disque, mais naïvement, je me dis que multiplier par n le champ geom implique nécessairement une perte d'espace disque considérable, sur des jeux de données très volumineux.
Mais tant mieux si tu penses que ce n'est pas un problème ;)

from geonature.

Franchement je pense pas que ce soit une bonne idée.
Mieux vaut que toutes les spécificités soient gérées au nouveau des données sources du protocole et que l'on gère tout à plat de manière homogène dans la Synthèse, en évitant les cas variables, les données dégradées en fonction de tel protocole ou non etc...

from geonature.