Le portail francophone de la géomatique

Bonsoir,

Si ces procédés doivent être répétés et mis à jour régulièrement (ex: mise à jour des exploitations) ça vaut vraiment le coup de passer par du SQL (d'abandonner le format shape). Je vois deux possibilités: installer un serveur PostgreSQL ou passer par une base Spatialite (je n'ai jamais fais).

L'idée serait de passer par des "vues". À chaque appel de la vue, la requête est exécutée et fournit un résultat actualisé de ladite requête.
En cas de lenteur (gros lot de données), il faudra se tourner vers les "vues matérialisées", mais c'est un autre sujet.
Voici en substance ce que donnerait ce que vous cherchez à faire sous postGIS/postgreSQL:

1) Créer un tampon de 500 m dans PostgreSQL: ST_Buffer(geom,500).
2) Tester l'intersection entre parcelle et le tampon: ST_Intersects(parcelle.geom, tampon.geom)
3) Étape qu'il est possible de s'économiser en passant par PostgreSQL.
4) ajouter le nom de l'agriculteur à la couche parcelle si la parcelle est dans le buffer de 500m autour du siège de l'exploitation.
5) ne sélectionner que que les terres de "Mr Machin" via une clause where: SELECT * FROM ma_vue WHERE nom = 'Mr Machin' ;

J'aurais tendance à simplifier la démarche en:
1) crééant une vue qui joint le nom de l'exploitant, le siège et la culture concernée aux polygones parcelles
2) interroger cette vue, selon les critères recherchés.

Exemple de requête pour la vue:

SELECT p.geom, e.nom, e.siege, e.culture
FROM parcelle p
JOIN exploitation e ON ST_Intersects(ST_Buffer(e.geom,500),p.geom)

Exemple de requête pour sélection des prairies de monsieur X

SELECT *
FROM la_vue_du_dessus
WHERE nom = 'Monsieur X' AND culture ILIKE '%prairie%'

À adapter en fonction des données en présence, bien évidemment.

Autre exemple en un coup, pour répondre à la seconde problématique:

SELET *
FROM exploitation e
JOIN parcelle p ON ST_Intersects(ST_Buffer(e.geom,300),p.geom) 
WHERE e.nom_exploitant = 'M.Bidule' AND culture = 'céréales'

Bref le monde merveilleux du SQL s'offre à vous!
Bonne continuation.

Bonjour,

Excusez la réponse tardive de ma part, je suis nouvelle ici et je m'attendais à ce que les réponses me soit signalées par mail...


A priori, cela fait moins peur de se lancer sur les couches virtuelles mais une petite info supplémentaire:

la mise à jour n'est pas effectuée régulièrement. C'est plutôt que la même manipulation devrait être répétée sur différentes zones au grès de nos commandes/projets.
Lors de ce projet, on mène d'abord un travail de terrain pour mettre à jour nos 2 couches avant d'effectuer cette manipulation. Puis on effectue l'opération que je vous ai expliqué.

Peut être que ca ne change rien à la solution technique mais peut être qu'avec ces informations une des 3 solutions peut vous apparaitre plus adéquates ?
- Couche virtuelle
- Serveur PostgreSQL
- base Spatialite

Merci à vous deux

Bonjour,

Je ne sais pas s'il est nécessaire de convertir les .tab pour les utiliser en tant que couches virtuelles.

Pour les utiliser dans PostgreSQL, il est possible de les convertir puis de les intégrer comme "couches PostGIS" ou alors d'utiliser ce que l'on nomme "foreign data wrapper" qui permet d'utiliser des fichiers (comme du csv, des fichiers tab, des flux, etc) directement depuis la base de données.
Quelques infos sur les foreign data wrapper disponibles:
https://wiki.postgresql.org/wiki/Foreign_data_wrappers
Le FDW qui vous conviendrait:
https://github.com/robe2/pgsql-ogr-fdw

Pour la base Spatialite, il faudra convertir (à ma connaissance).

Concernant le format à préférer l'avantage de PostgreSQL est que les données sont dans une base accessible par plusieurs utilisateurs en même temps. Par contre c'est probablement la solution la + complexe à mettre en place.
Pour Spatialite, la base est "contenue" dans un fichier unique accessible par un seul utilisateur à la fois, mais les informations sont dans la base.
Pour les couches virtuelles, les informations sont dans le projet (1 seul utilisateur à la fois).

Personnellement je penche PostgreSQL car c'est le système que je connais, il faudrait voir les avis des autres membres.

Bonne journée

Bonjour à tous,
Petit up.
Quelqu'un utilise-t-il Qgis avec des Foreign Data Wrapper dans PostgreSQL/Postgis ?
Merci.

Merci de ce retour !
J'ai tenté d'en mettre un en place (PGSQL 9.6/ Postgis 2.3.3) mais Qgis (2.18.21 sous Windows 7) ne voit ni le schéma créé, ni les foreign tables.
Est-ce normal ?

Ci-dessous les commandes utilisées :

CREATE EXTENSION IF NOT EXISTS postgres_fdw;

CREATE SERVER instance_a
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'localhost', port '54xx', dbname 'base_xxxx');

CREATE USER MAPPING FOR USER
SERVER instance_a
OPTIONS (user 'base_xxxx', password 'xxxxxxx');

DROP SCHEMA IF EXISTS ext_base_xxxx;
CREATE SCHEMA ext_base_xxxx;
IMPORT FOREIGN SCHEMA public
FROM SERVER instance_a
INTO ext_base_xxxx;

GRANT ALL ON SCHEMA ext_base_xxxx TO xxxx;
GRANT USAGE ON SCHEMA ext_base_xxxx TO xxxx;
GRANT ALL ON SCHEMA ext_base_xxxx TO xxxx;

Merci de votre aide.

Dernière modification par chanteclair (Fri 19 October 2018 14:26)