Le portail francophone de la géomatique

image95 · Tue 24 June 2025 11:27

Bonjour,
Je voulais comparer un géotraitement fait sur qgis et postgis. Il s'agit d'une union de 2 couches vecteur polygonales volumineuses.
Le traitement sur Qgis a pris 1h30 sur une station bien équipée (32 Go de RAM). Sur postgis, je n'ai jamais pu faire le traitement.

Voici la requête testée :

Code:

create table public.union as
select st_union(ST_Forece2D(mos.geom), ST_Forece2D(bd_topo_bat.geom))
from public.mos, public.bd_topo_bat

Voici le message d'erreur :

Code:

ERROR: could not extend file "base/19370/76968.57" with FileFallocate(): No space left on device HINT: Vérifiez l'espace disque disponible. ERREUR: could not extend file "base/19370/76968.57" with FileFallocate(): No space left on device SQL state: 53100

Le message d'erreur annonce un probleme de fichier log temporaire. Dans le fichier postgresql.conf, j'ai édité le fichier en passant la valeur de log_temp_files = 10240 .La valeur par défaut était -1. J'ai fait cette action en m'inspirant de ce post : https://stackoverflow.com/questions/508 … on-device.

Si une personne pense pouvoir m'aider. Merci.

tumasgiu · Tue 24 June 2025 11:45

Bonjour,

votre requête génère probablement un très (trop) grand nombre de lignes, n * m (ou n et m sont les nombres de lignes respectifs de vos deux tables). Vous n'avez pas assez d'espace de stockage pour cela. Comme vous réalisez une jointure de vos deux tables vous produisez une combinaison de chaque géomètrie de vos deux tables. Si vous rajouter LIMIT 100 à la fin de votre requête pour restreindre le nombre de resultat, vous verrez que le résultat n'est sans doute pas celui que vous souhaiter.

Vous souhaitez probablement une table composée de n + m ligne (toutes les géometries de votre première table et toutes les géomètries de la seconde), avec une requête comme celle-ci :

Code:

create table public.union as
(
select ST_Force2D(mos.geom)
from public.mos

--ce mot clé permet de combiner les ensemble de resultats de deux requêtes en un seul ensemble
UNION ALL

select  ST_Force2D(bd_topo_bat.geom))
from public.bd_topo_bat
)

EDIT

Si vous souhaitez plutôt dissoudre les géometries de vos deux tables dans une seule énorme géomètrie, une stratégie pourrait être celle de modifier la taille de mémoire allouée à postgresql pour réaliser la requête (paramètre work_mem dans le fichier postgresql.conf).

Une autre statégie serait de travailler par itérations, comme suggeré dans ce post stackoverflow https://gis.stackexchange.com/questions … ng-postgis

Dernière modification par tumasgiu (Tue 24 June 2025 12:12)

image95 · Tue 24 June 2025 12:35

Bonjour,
Un grand merci pour votre retour. je vais lire attentivement votre réponse. Pour votre information, mon but est de réaliser avec postgis l'équivalent du géotraitement "UNION" de Qgis :
https://docs.qgis.org/3.40/en/docs/user … html#union

Dernière modification par image95 (Tue 24 June 2025 17:03)

tumasgiu · Tue 24 June 2025 14:14

Voici une idée :

Code:

SELECT
    geom
FROM
(
    SELECT 
       unnest(geoms) geom
    FROM (
        SELECT
            ARRAY[
                    st_difference(   a.geom, b.geom),
                    st_difference(   b.geom, a.geom),
                    st_intersection(a.geom, b.geom),
                    st_intersection(a.geom, b.geom) -- on repete l'intersection pour respecter l'algo de qgis                
                 ] AS geoms
        FROM
            test.bd_topo_bat a JOIN test.mos b ON st_intersects(a.geom, b.geom)
        ) AS sous_requete
    UNION ALL
    SELECT
        a.geom
    FROM
    test.bd_topo_bat a LEFT JOIN test.mos b ON st_intersects(a.geom, b.geom)
    where b.geom is null
    UNION ALL
    SELECT
        b.geom
    FROM
    test.bd_topo_bat a RIGHT JOIN test.mos b ON st_intersects(a.geom, b.geom)
    where a.geom is null
) AS sous_requete_2(geom)
WHERE geom is not null

ppluvinet · Tue 24 June 2025 14:23

Bonjour,
Pour faire un UNION comme décrit, je joue personnellement avec les fonctions st_intersection et st_difference et ce n'est pas très sexy ! Si quelqu'un a une solution plus simple, je suis preneur, sinon, j'essaierai de vous donner ma solution.

Dernière modification par ppluvinet (Tue 24 June 2025 14:24)

tumasgiu · Tue 24 June 2025 14:47

C'est vrai c'est pas super. Avec un moteur qui le supporte (pas postgresql du coup ), on peut simplifier la requête en supprimant les deux UNION ALL et en remplaçant le INNER JOIN par un FULL OUTER JOIN mais çà reste pas génial.

Nicolas Ribot · Tue 24 June 2025 19:22

Bonsoir,

Perso, pour ce genre de décomposition spatiale, si les couches à croiser sont conséquentes, je passe en linestring (st_boundary(geom)), puis je fais l'union pour produire un set nodé, puis st_polygonize pour reconstruire les surfaces.
En jouant avec pointOnSurface des deux couches on peut identifier quel bout du resultat provient de quelle geometrie source.

Si la ou les couches sont énormes, je découpe en lot pour traiter ces lots, puis une requete pour identifier les éventuels cas particuliers aux frontieres des zones traitées par lot.

Je me permets une remarque concernant st_union dans Postgis: je vous pleins de gens, en formation ou chez des clients, qui veulent faire l'union d'une couche polygone pour avoir un seule géométrie (ou plusieurs très grosses avec un st_union() group by ...

Pitié, ne faites JAMAIS ca, dans 99% des cas, ca ne sert a rien a part faire planter postgis ou faire tourner une requete pdt des heures:
postgis ADORE avoir pleins de petites geometries et deteste travailler avec peu de grosses geom.

Par ex, une couche occupation du sol dans laquelle on voudrait faire une geom par type d'occupation est une hérésie dans postgis: il faut au contraire utiliser st_subdivide pour découper tout gros polygone en pleins de petits bouts.
En terme de topologie, c'est pareil: avoir un pg de 100km2 ou 1millions de petits polygones de 100m2 represente la meme surface. Par contre, si on veut utiliser ce gros pg dans une requete, postgis rame un max pour deux raisons:
1) pleins de coordonnées en mémoire à gérer
2) l'index spatial n'a plus d'interet, puisque le test entre ce gros polygones et d'autres géométries n'est pas selectif du tout et renvoie pleins de candidats qui doivent etre traités

Un exemple concret de cette stratégie de découpage en petits bouts (et qui nous a bien fait halluciner en vrai): un croisement d'une belle grosse couche occupation du sol sur un dept ou region (me rappelle plus) vs une autre couche avec pleins de polygones:
la requete avec la couche occsol initiale: plus de 6h
subdivide sur la couche occsol (1-2min) + requete lancée sur cette nouvelle table occsol_sub: 30s !

Nicolas

Nicolas Ribot · Tue 24 June 2025 19:39

Exemple en passant par des linestrings (st_boundary(geom)):

Code:

with tmp as (
    select st_union(st_boundary(geom)) as geom
    from circles
)
select (st_dump(st_collectionextract(st_polygonize(geom), 3))).path[1] as id,
        (st_dump(st_collectionextract(st_polygonize(geom), 3))).geom
from tmp;

circles = table des 4 cercles qu'on veut exploser

(edit: la pj montrant le résultat ne marche pas )
Nicolas

Dernière modification par Nicolas Ribot (Tue 24 June 2025 20:56)

ChristopheV · Wed 25 June 2025 16:39

Bonjour,
Nicolas a parfaitement raison. Et dans son commentaire il souligne un point important, "pourquoi ?".

Réaliser l'union de la couche d'occupation du sol et de la couche bâtie de la BD Topo dans quel but ????

Un autre conseil au vu de la requête présentée, n'utilisez pas le schéma "public" pour vos données métier.

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Sites amis	Agenda Biblio Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

Annonce

#1 Tue 24 June 2025 11:27

Postgreql/postgis : Error No space left on device SQL state: 53100

Code:

Code:

#2 Tue 24 June 2025 11:45

Re: Postgreql/postgis : Error No space left on device SQL state: 53100

Code:

#3 Tue 24 June 2025 12:35

Re: Postgreql/postgis : Error No space left on device SQL state: 53100

#4 Tue 24 June 2025 14:14

Re: Postgreql/postgis : Error No space left on device SQL state: 53100

Code:

#5 Tue 24 June 2025 14:23

Re: Postgreql/postgis : Error No space left on device SQL state: 53100

#6 Tue 24 June 2025 14:47

Re: Postgreql/postgis : Error No space left on device SQL state: 53100

#7 Tue 24 June 2025 19:22

Re: Postgreql/postgis : Error No space left on device SQL state: 53100

#8 Tue 24 June 2025 19:39

Re: Postgreql/postgis : Error No space left on device SQL state: 53100

Code:

#9 Wed 25 June 2025 16:39

Re: Postgreql/postgis : Error No space left on device SQL state: 53100

Pied de page des forums