GeoServer : géométrie altérée en WFS mais pas en WMS o_O

[Maël REBOUX]

Bonjour,

Je termine la semaine sur un échec de publication d'une couche bête comme la mort avec 6 enregistrements.

Je poste ici car je n'ai encore jamais rencontré ce comportement.

La structure de la couche en base PostGIS

CREATE TABLE logement.cget_quart_prioritaire (
    objectid int4 NOT NULL,
    code_qp varchar(254) NOT NULL,
    nom_qp varchar(254) NULL,
    commune_qp varchar(254) NULL,
    st_area_shape_ numeric(38, 8) NOT NULL,
    st_length_shape_ numeric(38, 8) NOT NULL,
    shape geometry NULL,
    CONSTRAINT enforce_geotype_shape CHECK ((geometrytype(shape) = 'POLYGONM'::text)),
    CONSTRAINT enforce_srid_shape CHECK ((st_srid(shape) = 3948)),
    CONSTRAINT pk_cget_quart_prioritaire_code_qp PRIMARY KEY (code_qp)
);
CREATE INDEX a5608_ix1 ON logement.cget_quart_prioritaire USING gist (shape);
CREATE UNIQUE INDEX r5848_sde_rowid_uk ON logement.cget_quart_prioritaire USING btree (objectid) WITH (fillfactor=75);

Je note juste que c'est déclaré en POLYGONM (et je vois pas pourquoi).

Bien entendu la couche passe les tests : st_isvalid(shape) sous PostGIS et utilisation du greffon "Vérifier les géométries" sous QGIS.

RAS. Que dalle. Nada.

Par contre : impossible de publier la couche sur OpenDataSoft et pour cause :

(rouge WMS, le griboullis : le WFS de GeoServer)

Le pire est que le GML téléchargé depuis GeoServer est correct !

Est-ce que qqn aurait la moindre petite idée de l'origine du pb et de comment corriger ?

 

Maël REBOUX
Service Information Géographique Rennes Métropole
Chargé de mission données et diffusion

02 99 86 63 71

Twitter : @mael_reboux_ig

 

https://public.sig.rennesmetropole.fr   |  https://data.rennesmetropole.fr

 

[Benjamin Chartier]

Salut,

Pour le Polygonm il faudrait voir avec la source de données qui a été utilisée pour alimenter PostGIS. C'est un shapefile importé via les outils de base de données de QGIS ou autre chose ? Je voie que les données existent en KML.

Les données en KML ont systématiquement une composante Z car elles sont faites pour être présentées sur un globe 3D.

Si le M ou le Z est inutile (ce qui ne m'étonnerait pas) il faudrait mieux transformer le source de données pour en supprimer la composante "mesure" avant intégration dans PostGIS pour avoir juste le nécessaire.

[de manière générale il vaut mieux éviter d'utiliser des données en KML quand on a le choix d'avoir autre chose quand on intègre les données dans PostGIS. Les fichiers KML sont en WGS84. Elles ont donc déjà subi une déprojection et il est probable qu'elle vont ensemble subir une projection -> ces transformations altèrent de manière minimes les données mais de manière totalement inutile. Autant conserver les données dans le système de coordonnées d'origine.]

Pour l'altération visuelle, il faudrait comparer en mode texte la géométrie en base (exportable en WKT), la géométrie en sortie de GeoServer via une requête WFS+GML.

Quand tu dis que le GML téléchargé depuis GeoServer est correct tu parles de quoi ? D'une requête WFS GetFeatures avec un outputFormat = GML ?

Le gribouillis est issue de quelle requête ? C'est une requête GetFeatures avec un outputFormat = GML ?

Benjamin Chartier

[Maël REBOUX]

Bonjour Benjamin,

Les données viennent de l'Etat. Amha comme bien d'autres elles sont possiblement relativement pourries mais je n'avais jamais eu de pb sur cette couche jusqu'à présent.

Mais c'est pas moi qui crée les couche sen base donc aucune idée de pourquoi ça a été fait ainsi. Ahma depuis un shape avec les outils ESRI.

Un SELECT ST_AsText(shape) donne :

POLYGON M ((
1349547.062 7221778.9173 1.#QNAN
1349542.2198 7221821.1613 1.#QNAN
1349527.0639 7221926.9771 1.#QNAN

...

> Quand tu dis que le GML téléchargé depuis GeoServer est correct tu parles de quoi ? D'une requête WFS GetFeatures avec un outputFormat = GML ?

Oui. Et l'export GML (via GeoServer bien sûr) donne :

1349547.062,7221778.9173
1349542.2198,7221821.1613
1349527.0639,7221926.9771

On va commencer par refaire la couche en base en poylgone 2D et on voit ensuite.

---

De: "Benjamin Chartier" <con...@bchartier.net>
À: "georchestra" <georc...@googlegroups.com>
Envoyé: Vendredi 4 Mars 2022 18:29:55
Objet: [NEWSLETTER] [georchestra] Re: GeoServer : géométrie altérée en WFS mais pas en WMS o_O

--
--
Vous avez reçu ce message, car vous êtes abonné au groupe
Groupe "georchestra" georc...@googlegroups.com
voir http://groups.google.fr/group/georchestra
 
Site web : http://www.georchestra.org

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "georchestra".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse georchestra...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/georchestra/e9a00868-f1b8-4452-a5df-32265a4d2d68n%40googlegroups.com.

[Maël REBOUX]

Le passage en Polygon 2D normal a réglé le problème.

Super bizarre quand même la différence entre WMS et WFS....

---

De: "REBOUX Maël" <m.re...@rennesmetropole.fr>
À: georc...@googlegroups.com
Envoyé: Lundi 7 Mars 2022 09:42:04
Objet: [NEWSLETTER] Re: [georchestra] Re: GeoServer : géométrie altérée en WFS mais pas en WMS o_O

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/georchestra/1959589260.505558.1646642524803.JavaMail.zimbra%40rennesmetropole.fr.