Le portail francophone de la géomatique

bonsoir,
J'ai cherché un compromis entre être d'un côté simplifier et aller à l'essentiel, et de l'autre contextualiser mon problème. Il semble que l'équilibre n'était pas bon.
Le fichier de couche est une sorte de parcellaire. Il permet de suivre l'occupation du sol précise sur plusieurs années. Chaque polygone a toujous été homogène occupation du sol. Un îlot agricole est un espace contigüe exploité par un agriculteur. L'assolement fait que le nombre de parcelles agricoles au sein d'un îlot varie d'une année sur l'autre. De plus, les limites de parcelles peuvent changer même si le nombre de parcelles est le même. Pour définir une parcelle, il faut un espace continu présentant la même culture exploitée par le même agriculteur (pour ne pas fusionner les blés de M. Bidule avec ceux de son voisin). 

Voilà pour le contexte.
Pour la question technique, ce que vous dites de st_union ne me rassure pas... Pourriez-vous préciser, SVP ?
Avec mes remerciements,
Jean-Baptiste

Bonjour Santana,

J'ai essayé st_dump().

SELECT 
    (st_dump(st_union(geom))).geom as singlegeom,
    MIN(no_par) as no_par,
    SUM(surf) as s_ilot,
    MAX(date_interv),
    SUM(quantite)/SUM(surf) as dose,
    code_stream,
    id_resp
FROM occup2015
GROUP BY code_stream, id_resp

Cette fonction permet bien d'exploser une géométrie multipartie: la couche produite est conforme à ce que j'attends du point de vue de la géométrie. Mais les statistiques sont calculées sur l'ensemble, avant "explosion". Chaque géométrie retournée par st_dump se voit attribuer la même valeur s_ilot ou de dose, calculées sur l'ensemble des enregistrements présentant le même couple (code_stream, id_resp), contiguës ou pas.  J'ai même forcé le passage en polygones simples, mais le résultat est le même.

SELECT 
    (st_dump(st_union(geom))).geom::geometry(polygon,2154)  as singlegeom,

Faudra-t-il multiplier les étapes
1) fusionner avec st_union,
2) "exploser" avec st_dump,
3) calculer les autres champs avec une jointure spatiale (st_within) ?

Ce ne serait pas très élégant, lorsqu'il suffirait que st_union nous donne des géométries simples... J'en reviens donc à ma question initiale, que je reformule de façon plus prudente néanmoins :
Est-il possible de forcer st_union à retourner des polygones simples ?

En vous remerciant pour votre aide,
Bien sincèrement,

Jean-Baptiste

Bonjour,

Mon message arrive sûrement trop tard, mais j’ai eût le même problème que vous et, m’inspirant de votre « bidouille », j’ai réussi à le régler. Voilà le code que vous auriez pu utiliser (inspiré de celui que j’ai fait mais il faudrait le tester) :

SELECT 
    table_fusion.singlegeom AS geom,
    MIN(table_ini.no_par) as no_par,
    SUM(table_ini.surf) as s_ilot,
    MAX(table_ini.date_interv),
    SUM(table_ini.quantite)/SUM(table_ini.surf) as dose,
    table_fusion.code_stream,
    table_fusion.id_resp

FROM (SELECT 
        code_stream,
        id_resp,
        (st_dump(st_union(geom))).geom as singlegeom
    FROM occup2015
    GROUP BY code_stream, id_resp)
    AS table_fusion,
    LEFT OUTER JOIN occup2015 AS table_ini ON ST_Contains(table_fusion.geom,table_ini.geom)

GROUP BY  table_fusion.geom,table_fusion.code_stream,table_fusion.id_resp

L’idée est donc de créer :
   - une table « table_fusion » qui contient les géométries voulues : les parcelles fusionnées, groupées par identifiant de culture et d’agriculteur, puis explosées avec ST_DUMP
   - une table « table_ini » qui contient les données initiales, regroupées via des fonctions d’aggrégation (MIN, SUM, MAX) et associées par une jointure spatiale « ST_CONTAINS » aux parcelles de « table_fusion »

Je ne sais pas si mes explications sont claires, mais j’espère en tout cas que cette bidouille pourra aider quelqu’un.

Bien cordialement,

Alice Martin