Le portail francophone de la géomatique

Bonjour,

Deux points:

• Découper le gros polygone en pleins de petits (st_subdivide): le temps de traitement sera réduit de facon... spectaculaire
• Utilisez un anti join pour trouver les geometries sans rapport spatial avec d'autres: les index spatiaux ne marchent bien que pour répondre: "oui, des objets sont en relations spatiales"::

select p.id 
from points p 
where not exists (
  select null
  from poly_decoupe d
  where st_dwithin(p.geom, d.geom, 0.001) --< precision a regler suivant vos données, ou st_contains
);

Pfff pardon ! c'est votre deuxieme requete ! j'ai lu un peu vite...
Découpage donc !

Nicolas

Bonjour,

Pour ce genre de requête en revanche pour des fonction comme st_symdifference() c'est l'inverse.

Bonjour,

Comme l'indique Nicolas, les index ça marche bien pour le OUI. Combien de temps met votre sous requête avec st_within() ?

@ ChristopheV, j'ai relancé avec st_within est la requête n'est pas finie. Elle devrait mettre le même temps je pense?

@ Nicolas, j'ai lancé "le filet" et je suis en train de découper pour polygone et ensuite lancer la requête de recherche.

J'attends les résultats et vous tiens au courant dès que possible

Pour la requête de Nicolas,
pouvez vous la poster, ainsi que le plan d’exécution ?
On dirait que la découpe génère des géométries
incompatibles avec l'index (!), pour remédier à cela
il faudrait peut être filter au préalable la sortie de votre subdivide maison,
afin de ne retenir que les (multi)polygones.

Pour votre requête initiale, simple remarque :
je ne sais pas si utiliser une requête latérale produira
le plan de requête le plus optimal (même si peut être que dans ce cas-ci,
il sera identique).

Sinon, avec 4 fois moins de points que vous et pour un polygone de surface équivalente,
avec la requête suivante j'arrive à 1min10 :

SELECT st_dump(st_difference(points, geom)) point FROM (SELECT st_union(point) FROM mes_points) p, (SELECT geom FROM mes_polys LIMIT 1) g;

Il faut ensuite refaire la jointure avec la table des points. (on peut utiliser st_memunion pour être gentil et ne pas consommer trop de mémoire).

EDIT: 2min20 avec une jointure spatiale

EDIT2: 1min30 en joignant sur l'id des points (utilisation d'une des dimensions dispo (M ou Z) pour stocker l'idée du point dans le st_union).

EDIT3: changer st_union avec st_collect n'a pas l'air d'affecter le temps d'exécution.

EDIT4: la dimension M ne peut pas être utilisée pour stocker l'id car elle est effacée par st_difference.

Dernière modification par tumasgiu (Mon 12 November 2018 11:53)

Je ne sais pas, il faudrait voir votre requête.

Ok,
je vais donc rester à la méthode de subdivision qui fonctionne parfaitement.

Encore merci

Si je comprends vous voulez la requête de Nicolas?
La voici, c'est celle que j'avais posté également au tout début de mon post.

select p.id, p.geom 
from "Phil"."import_leve_PointZ" p 
where not exists (
  select null
  from "Phil"."polygondecoup_singlev2" d
  where st_intersects(p.geom, d.geom) 
)

Est-ce cela?

En testant séparément, je me suis aperçu que dans la requête :

SELECT st_dump(st_difference(geom, g.geom)) point FROM 
(SELECT st_union(geom) FROM "Phil"."import_leve_PointZ") p, (SELECT geom FROM "Phil"."polygon" LIMIT 1) g

la partie relative au st_union me renvoyait un résultat vide!

Tumasgiu, je viens de stopper la requête, car ça faisait 17h30 qu'elle tournait

En fichier joint le résultat du explain.

En espérant que cela vous soit utile

Merci pour le "&&", sur ta requête elle se termine en 20 minutes (contrairement à la dernière fois où j'avais du la stopper).

Avec la grille 3 minutes
là j'obtiens un résultat en 20 minutes, mais le résultat n'est pas bon, il faut que je vois pourquoi. Normalement, je devrais avoir qu'une seule "anomalie", présentement j'en ai 4067733!

La machine est mon PC de travail, RAm 12Go, I7-3773 CPU 3.4Ghz.
Je n'ai apporté aucune modification sur la config.