Discussion :

[apidou]

Bonjour,

J'utilise ce code pour croiser deux tables (une table des communes avec d'autres objets géographiques) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
"SELECT AsSVG( table1.the_geom,1,1) as geom 
FROM table1, public.commune
WHERE
table1.the_geom && '$box'::box3d 
AND intersects (table1.the_geom,public.commune.the_geom) 
AND public.commune.code_insee='$com' ";

$box correspond au rectangle d'encadrement de ma commune

Première question :
Y a t-il un moyen d'optimiser... la méthode me parait un peu lourde : je réduis le nombre d'objets de ma table 1 en ne prenant que ceux contenus dans le rectangle puis je croise avec l'objet (=ma commune)

Deuxième question (=the problème):
Cette requête fonctionne sauf pour une commune et là j'obtiens le message :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
ERREUR:  Operation on two geometries with different SRIDs

Pourtant mes deux tables ont le même srid (2154) !
j'ai vérifier avec un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT srid(the_geom) FROM...

Comment se fait il que j'ai ce message pour une requête particulière?

Que faut il tester et modifier ?

[apidou]

J'ai réglé mon problème de srid avec setSRID
mais je me demande si cette clause sert à quelque chose ...
voici ma requête retravaillée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
$sql="SELECT DISTINCT AsSVG( table1.the_geom,1,1) as geom 
FROM table1, 
(SELECT the_geom FROM commune WHERE code_insee = '$com') com
WHERE
table1.the_geom && setSRID('$box'::box3d,2154) 
AND ST_INTERSECTS (table1.the_geom,com.the_geom) 
";

ma requête sur la commune est trop lente (40s environ pour 47000 enregistrements sélectionnés)...
remarque : j'ai bien un index sur la colonne the_geom de ma table1

[estofilo]

Pour les questions de performance, il faut regarder le résultat d'EXPLAIN ANALYZE des requêtes

[SQLpro]

L'erreur est normale : vous mélangez des objets géographiques (communes département) avec des objets géométrique (rectangle) donc il y a incompatibilité de types (en particulier SRID).

De manière générale votre requête me parait absurde : pourquoi passez par une "box" lorsque l'on peut faire directement l'intersection ?
D'autant que cela peut vous conduire à un résultat faux.
Le reste (cout et donc optimisation) n'est donc qu'une question d'indexation.

A +

[apidou]

Je débute avec PostGis

J'avais rajouté la clause supplémentaire de la box car j'avais vu dans des exemples que cela devait faire gagner du temps...
Après vérification, cela s'avère inexacte car les temps d'exécution sont presque identiques donc la clause et aussi inutile qu'absurde (je l'ai donc supprimée).

Voici le résultat d'EXPLAIN ANALYSE : si quelqu'un peut m'aider à décrypter.... J'ai l'impression que c'est mon intersection qui est lente et je ne sais pas si je peut améliorer quelque chose.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Nested Loop  (cost=0.00..26.80 rows=522 width=605) (actual time=8.128..32560.059 rows=47042 loops=1)
  Join Filter: _st_intersects(table1.the_geom, commune.the_geom)
  ->  Index Scan using code_insee on commune  (cost=0.00..8.27 rows=1 width=130919) (actual time=0.037..0.039 rows=1 loops=1)
        Index Cond: ((code_insee)::text = '..085'::text)
  ->  Index Scan using table1_the_geom_gist on table1  (cost=0.00..16.44 rows=3 width=605) (actual time=0.092..95.573 rows=75826 loops=1)
        Index Cond: (table1.the_geom && commune.the_geom)
Total runtime: 32581.143 ms

Petite précision : un index a été crée de façon auto par shapefile importer sur ma colonne geo de la table1 (CREATE INDEX table1_the_geom_gist ON table1 USING gist (the_geom) )

[estofilo]

Ici:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
  ->  INDEX Scan USING table1_the_geom_gist ON table1  (cost=0.00..16.44 rows=3 width=605) (actual time=0.092..95.573 rows=75826 loops=1)
        INDEX Cond: (table1.the_geom && commune.the_geom)

l'optimiseur semble estimer que ça va produire 3 lignes, et en fait ça en produit plus de 75000.
Est-ce que les statistiques sont à jour par rapport aux volumes réels des données?
Dans le doute, lancer la commande ANALYZE dans la base et recommençer le test.