Le blog de Jean David TECHER, un Réunionnais à Saint-Priest/Lyon

La news n'est pas nouvelle mais je me permets quand même de la faire apparaître sur mon blog. Comme chaque année ALL - Association pour le Logiciel Libre - organise la 6ème édition des Journées du Logiciel Libre à Montpellier. Répartie sur 3 journées, elle se décline sur 3 journées dédiée chacune à un public et un thème différent:

1. Jeudi 14 : journée collectivités - le poste de travail libre;
2. Vendredi 15 : journée entreprises - enjeux, migration et sécurité;
3. Samedi 16 : journée grand public - citoyenneté, éducation et jeux.

Je me souviens quand 2005, j'avais tenu un stand avec Gérald. On a reçu des contacts très intéressants cette année-là. Un des liens possibles à consulter est http://www.all.asso.fr/Realisations/2007/jlm07/

Ayé, Paul a publié la liste des souhaits pour PostGIS 2.0 disponible à http://docs.google.com/Doc?id=dg99qr76_2dgt26j. Le moins que l'on puisse dire est que la liste est des plus intéressantes. A mon sens chaque point a été passé en revue: geocoding, routing/réseau, conformité au SFSQL2, amélioration de la documentation, faire de geometry_columns une vue ou autre manipulation.

Je ne passerais pas ici tout en revue mais je citerais par exemple quelques points qui ont attiré mon attention:

1. renommer les fonctions et les préfixer: Use ST_ for SQL/MM, SE_ for ESRI, SP_ for PostGIS specific. Comme souligné dans ce passage, celà peut porter à la plus grande confusion. Personnellement, je ne me suis pas encore penché sur le cas du SQL/MM qui apparaît comme un sur-ensemble des «objets» de PostGIS. Lire les spécifications c'est long!
2. que faire de geometry_columns? comme dit le résumé, il faudra attendre que PostgreSQL supporte les triggers sur les tables-système. A quand? A voir!

Il semblerait que la route soit assez longue avant de voir apparaître une première ébauche d'une 2.0 mais la liste des souhaits me semble plus que correcte.

Suite à mon précédent billet sur dblink, j'ai mis ce billet en forme en tant qu'annexe dans ma documentation. On peut ainsi le retrouver à l'URL http://www.davidgis.fr/documentation/win32/html/apc.html. Contrairement à ce que j'avais annoncé vendredi vu que je n'ai pas eu le temps, j'incluerais l'annexe sur tsearch2 au cours de cette semaine.

Dblink est un module de PostgreSQL qui permet d'interroger des serveurs distants. Il est fournit dans les sources de PostgreSQL

pour la simulation

Ici je vais supposer que j'ai deux bases réparties sur deux serveurs distants:

1. bremko: IP 192.168.0.4, base: testgis, table:communes_lr;
2. jenna: IP 192.168.0.5, base: testgis2, table:departements_lr;

Mes deux bases. Le suffixe "_lr" désigne la région Languedoc-Roussillon. Il s'agit donc des communes et des départements du Languedoc-Roussillon. Mon but ici est de connaître l'ensemble des communes de la région limitrophes au département de l'Hérault (code insee=34).C'est sur bremko que je décide d'installer le module dblink. Pour gagner du temps, je vais supposer ici que mes deux tables sont convenablement indexées sur leur champ géométrique respectif. Je vais aussi supposer que les deux table sont dans le schéma public de leur base respective.
En bleu: communes limitrophes à l'Hérault que je souhaite en interrogeant les deux tables.

Compilation et installation

Pour compiler dblink, rien de plus simple que de se rendre dans les sources de PostgreSQL et de faire en tant que root:

cd /chemin/vers/sources/de/PostgreSQL/contrib/dblink
make
make install

Maintenant, je deviens propriétaire de la base tesgis - ici postgres - sur bremko et je dote ma base des fonctionnalités de dblink

su postgres
psql -d testgis -f /repertoire/racine/de/PostgreSQL/share/contrib/dblink.sql

Premiers tests

Je me connecte à la base testgis sur bremko.

psql testgis

Grâce à dblink, je vais essayer de me connecter à la base testgis2 sur jenna. Sur jenna, l'utilisateur est damien ayant le mot de passe morphine. Ma connexion je vais l'appeler c1. Je commence par ouvrir la connexion en utilisant la fonction dblink_connect():

N.B: Si vous voulez un descriptif de toutes les fonctionnalités de dblink, rendez-vous dans le sous-répertoire doc des sources.

testgis=# SELECT * from dblink_connect('c1','hostaddr=192.168.0.5 port=5432 dbname=testgis2 user=damien password=morphine');
 dblink_connect
----------------
 OK
(1 ligne)

J'effectue une requête simple qui me renvoit les données attributaires de la table departements_lr

testgis=# SELECT * from dblink('c1','select gid,id,nom,numero from departements_lr',true) as foo(gid int,id int,nom text,numero text) order by nom;
 gid | id |        nom        | numero
-----+----+-------------------+--------
   4 |  4 | Aude              | 11
   2 |  2 | Gard              | 30
   1 |  1 | Herault           | 34
   3 |  3 | Lozre             | 48
   5 |  5 | Pyrnes Orientales | 66
(5 lignes)

Je ferme ensuite ma connexion grâce à dblink_disconnect().

testgis=# SELECT * from dblink_disconnect('c1');
 dblink_disconnect
-------------------
 OK
(1 ligne)

Le test attendu

Bien sûr ici, je suppose que j'ai un connexion ouverte

testgis=# SELECT c.nom,c.insee FROM communes_lr c, 
dblink('c1','SELECT nom,the_geom FROM departements_lr',true) AS foo(nom text,the_geom geometry) 
WHERE   foo.nom='Herault' 
AND c.the_geom && foo.the_geom 
AND touches(c.the_geom,foo.the_geom) 
AND c.nom NOT LIKE '34%';

On notera ici que

• WHERE foo.nom='Herault' est utilisé pour ne retourner que le contour département héraultais de la table departements_lr;
• c.the_geom && foo.the_geom est utilisé pour tirer profit des index spatiaux;
• AND c.nom NOT LIKE '34%' pour ne pas retourner les communes internes de l'Hérault.