Le portail francophone de la géomatique

Bonjour,

Je vous propose une bizarrerie de plus pour aiguiser votre curiosité.

Je réalise à nouveau ma requête d'intersection entre  la couche 'zone de végétation' de type MULTIPOLYGON issue de la BDTOPO de l'IGN et ma couche limite administrative d'une collectivité territoriale.

Le résultat est la création d'une table intégrée dans le schéma regroupant l'ensemble des intersections des couches géographiques de l'IGN BDTOPO.

Lorsque je vérifie sous Qgis 1.8 l'affichage de cette nouvelle table, trois couches géographiques apparaissent de type POLYGON, POINT et LINESTRING, comme si le type était plutôt une collection d'où le message d'erreur initial...

Qu'en pensez vous,


merci

Elodie

Dernière modification par Elodie11 (Fri 18 January 2013 09:16)

Bonjour,

Quelle version de PG et PGis utilisez-vous ?

Effectivement, une intersection entre objet peut renvoyer tout type de geometrie: point, ligne, polygone, multi*, geometryCollection.
Tout stocker dans la meme colonne dépend du modèle que vous adopter et de ce que vous voulez faire.
Tres souvent, c'est assez limitant car bcp de fonctions de postgis marchent sur des types précis (st_length, st_area...).

Effectivement, si vous travaillez avec des objets de dimension differentes, c'est plus judicieux de forcer la 2D comme vous faites (peut etre meme sur les tables d'origine, si les dimensions M et Z ne vous servent pas.)

QGis, me semble-t-il, considere qu'une colonne geographique doit avoir un seul type: il a du mal avec les colonnes stockant des types de geometries différents. Une solution possible est de creer des vues sur votre table resultant de l'intersection, une vue par type:

create view z_veget_point as (
select ...
from z_veget
where geometryType('the_geom') = 'POINT'
);

et pareil pour les autres types.
Enregistrez ces vues dans geometry_columns et qgis devrait les voir et vous permettre de les exploiter.

Sinon, pouvez-vous trouver le plus petit jeu de données qui provoque l'erreur et l'envoyer sur le forum ?

Nicolas

Merci Nicolas pour le temps accordé.

Nous travaillons sur PG 9.2 et Postgis 2.0

A l'origine, la couche géographique intersectée est uniquement de type Multipolygon (couche zone végétation de la BDTOPO de l'IGN). Il semblerait que le problème vienne plus de ma requête d'intersection qui génère une seule table censée être du Multipolygon et interprétée par Qgis 1.8 comme trois couches de type Polygon, Linestring et point.

Lorsque j'ai intégré les différentes couches géographiques de la BDTOPO certaines sont restées en 2D et d'autres ont été automatiquement fixées en 4D. C'est le cas pour les couches géographiques correspondant aux routes, chemins, cours d'eau...

Concernant dblink on a pour le moment opté pour une organisation thématique des bases de données type cadastre, hydrographie, bdtopo, puis métier type habitat, tri... la mise en place de notre serveur est assez récente ce qui explique certains choix qui peuvent sembler ne pas être judicieux, je prends note de vos conseils d'organisation de données en démultipliant le nombre de schémas dans une même base de données.

Vous voulez une extraction sous quel format? un backup d'une des tables qui pose problème ?

Elodie

Dernière modification par Elodie11 (Fri 18 January 2013 14:24)

Nicolas,
concernant :

Le détail des objets produits et cette distinction de types se voit uniquement sous Qgis. Si je lance un st_GeometryType dans PgAdmin il me renvoie Multipolygon sur toutes les lignes.

j'avais pensé à cela mais je n'ai pas trouvé la fonction qui permet de le faire

Le backup et/ou le shp sont un peu lourd... je peux peut-être vous les envoyer par mail ?

Elodie

si je lance la même requête sur le fichier source il me renvoie MULTIPOLYGON.

J'ai bien compris que

mais n'y a-t-il pas une fonction de "restriction" en quelque sorte qui permettrait de renvoyer uniquement le type MULTIPOLYGON ?

Elodie

effectivement je n'avais pas pensé à un UPDATE...

Concernant cette précision :

Nous avons fait le choix d'une "découpe" stricte des objets dans le cadre d'une convention de mise à disposition de données d'une étude où la continuité géographique n'est pas vraiment un enjeu. Obtenir uniquement les objets intersectant cette emprise m'aurait effectivement simplifié la vie...

Je vous envoie ma table à problème en backup.

Encore merci beaucoup Nicolas

Elodie

Voici ce que j'ai vu, si j'ai bien compris la problematique:

La table cst_lin11 contient les lignes a croiser avec la colonne the_geom de la table z_veget.

La requete d'intersection que j'ai lancée:

create table res as (
    select z.gid as zgid, c.gid as cgid, st_multi(st_intersection(z.the_geom, c.geometrie)) as geom
    from z_veget z join cst_lin11 c on (st_intersects(c.geometrie, z.the_geom))
);

Cette table contient des MULTILINESTRINGS et des MULTIPOINTS (j'utilise st_multi pour forcer la generation de multi objets dans tous les cas: ca genere moins de types d'objets différents)

ensuite:

delete from res where geometryType(geom) = 'MULTIPOINT';

(5 lignes uniquement)

La table res contient bien des objets homogènes que QGIs peut afficher.

je n'ai pas eu le message d'erreur: ERREUR:  lwcollection_construct: mixed dimension geometries: 0/2 lors de ce croisement, me laissant penser que la partie DBLink peut causer cette erreur: les deux serveurs ont-ils les memes versions de PG et PGIS ?

Sinon, pour corriger le probleme, en partant du principe que les dimensions Z et M ne vous interessent pas:

alter TABLE cst_lin11 ALTER COLUMN geometrie TYPE geometry(MultiLineString,3943) using st_force_2d(geometrie);

Les geometries de la table cst_lin11 sont alors en 2D.

Idem avec l'autre table:

alter TABLE z_veget ALTER COLUMN the_geom TYPE geometry(MultiPolygon,3943) using st_force_2d(the_geom);

Puis la requete finale ne gardant que des geometries du type que vous voulez:

with inter as (
    select z.gid as zgid, c.gid as cgid, st_multi(st_intersection(z.the_geom, c.geometrie)) as geom
    from z_veget z join cst_lin11 c on (st_intersects(c.geometrie, z.the_geom))
) select * from inter where geometryType(geom) = <le type a filtrer>

Nicolas

je vous ai également envoyé par mail le backup de la table gn_2013.

Je vais lancer la chaine de traitement que vous me proposez (en l'adaptant à gn_2013), en attendant vos remarques avec cette fois ci le croisement des envois précédents avec la table gn_2013.

merci encore pour votre motivation !

Elodie