Le portail francophone de la géomatique

Super ça marche, merci, j'y avais pas pensé à séparer en deux l'entité.

L'autre solution est impossible car je dois impérativement suivre le cadastre point par point et ne pas avoir de décalage (même minime).

Merci beaucoup

En fait, cela relève du GPU et non pas du CNIG, du coup, j'ai informé du problème via le formulaire de contact (cf pj).

Bonsoir,

Tu veux dire que ce serait quand même pertinent de faire remonter l'info au CNIG ?

Bonne soirée.
Elise

Bonjour,

Je pense que dans l'exemple la zone Ac devient, soit une enclave en sens technique bien qu'invisible à l'oeil ou bien il y a un mini-pont entre Ac et la zone Na encore une fois invisible à l'oeil mais existante en sens de la donnée.
Les autres zones sont modifiées en fonction pour compenser.

JJ

Dernière modification par Joseph Jacquet (Wed 13 October 2021 09:11)

Bonjour

Non, il n'y a pas de trou, dans l'exemple que je montre la zone Ac devient une enclave dans la zone Ap.

Edit : Idem que la réponse d'Elise ci-dessus

À la base, il n'y a justement qu'un seul polygone "papillon" mais le validateur du Géoportail de l'Urbanisme considère cela comme une erreur d'où l'idée de le diviser pour faire deux polygones distincts.

La problématique des polygones papillons avec le GPU est plus difficile à contourner dans l'exemple d'Élise. C'est possible pour une vision plan (invisible) mais en terme de donnée pure, cela pose plus de soucis.

JJ

Dernière modification par Joseph Jacquet (Wed 13 October 2021 11:43)

Effectivement mais il faudrait diviser la zone Ap ailleurs car dans ce cas, elle "embrasse" la zone Ac et deux noeuds de la zone Ap se partage la même coordonnée entre Ac et la zone N à droite

Bonjour

Je ne connais pas les particularités du GPU mais j'ai déjà rencontré ce type de polygones et problèmes sur des données de type occupation du sol. Les erreurs qui semblent être remontées sont celles d'une validité de la géométrie au sens des normes OGC (SimpleFeature).

Le premier cas "papillon" est effectivement résolu en passant de un polygone à 2 polygone. Dans le deuxième cas il devrait être résolu en passant d'un polygone à un polygone avec trou (i.e un seul contours exterieurs -> un contours exterieur + un contour intérieurs). Ce qui n'est pas autorisé dans les géométries valides au sens OGC c'est d'avoir deux fois le même point (sommet) dans un contour.

Ces deux types de problèmes et leurs solutions sont assez bien expliqués sur cette petite doc postgis : https://postgis.net/workshops/postgis-i … idity.html

Merci à Nicolas pour le lien c'est ce que je cherchais sans trouver immédiatement tout à l'heure.

En fait dans l'exemple d'Elise, il y a trois polygones.
Ap est un polygone avec trou, dont l'enveloppe extérieure (Exterior_ring) comporte un sommet commun avec Na.
Et un trou qui lui aussi est une polyligne fermée qui possède un sommet commun avec son enveloppe extérieure. (et donc Na).
Et un autre polygon Ac qui est égale topologiquement au trou de Ap.

Ensuite si vous voulez vraiment faire de la topologie, faite le avec l'extension topology de Postgis insérez vos polygons dans la couche topo vous verrez s'il y a des erreurs et si les faces crées sont correctes ...

Dernière modification par ChristopheV (Wed 13 October 2021 14:54)

Bonjour,

Bruno, c'est pas du fromage ou du saucisson ... y'a comme un standard, une norme quoi ... le standard OGC ... après si les gens du GPu inventent leur propre règles ...

Bonjour,

Quelques éléments de réponse côté IGN :

La validation géométrique se résume à :

- Est-il possible de lire la géométrie (chose qui bloque par exemple avec des contours de polygones à 3 points) ?
- La géométrie est-elle valide, au sens "ST_IsValid" de PostGIS du terme ?

Quelques précisions concernant le validateur GpU :

- Le contrôle de la géométrie a été introduit pour que les algorithmes des bibliothèques de calcul géométrique (qui ne sont pas conçus pour travailler avec des géométries non valides au sens de l'OGC) puissent répondre à la question "Quelles sont les zones qui intersectent la parcelle ?" (avec une réponse autre que "GEOS intersects() threw an error"!).

- La possibilité avait été étudiée de tenter des corrections automatiques de topologie (l'équivalent de ST_MakeValid) pour la diffusion (c-à-d. sans toucher aux archives), avec un simple avertissement dans le rapport de validation en cas de réussite de la correction automatique.
Cependant l'intégrité de la donnée producteur prime pour le moment et cette piste a donc été écartée.

- L’IGN a proposé avec sa MOA des fiches d'aide pour accompagner les utilisateurs sur chaque code d'erreur de validation, et il y a un document pointé par ces fiches d'aide qui explique ce qu'est une géométrie valide au sens de l'OGC (https://www.geoportail-urbanisme.gouv.f … es_1-0.pdf).

Nous nous efforçons de rester sur des contrôles standards qui puissent être effectués facilement avec des outils tels QuantumGIS, PostGIS,...

Il reste principalement deux difficultés sur les contrôles géométriques :

- Nous sommes en train d'ajouter des contrôles de complexité géométrique car on peut avoir parfois des cas exotiques avec de nombreux points et contours difficilement exploitables pour de la diffusion (avec 2.8 millions de points sur une seule géométrie, il y a peu d'outils assurant des traitements fluides).
Le GpU peut difficilement assumer la fonction de simplification des géométries obtenues par des processus de vectorisation automatique et c’est pourquoi le rapprochement avec nos utilisateurs est un souci permanent.

- "Tricher" en décalant de façon non visible à une échelle d'impression le sommet du polygone amène potentiellement à des géométries valides dans la projection utilisée pour la production des données mais non valides dans la projection utilisée pour la diffusion.
Le problème de fond réside dans le fait qu'un contrôle topologique sans notion de précision sur la donnée n'a pas vraiment de sens (sans notion de précision, la réponse à la question "De quel côté de la droite se trouve le point ?" va dépendre de la précision des calculs dans l'ordinateur).

Enfin, le dépôt https://github.com/IGNF/validator correspond bien au code du validateur.

On retrouvera la même méthode que la bibliothèque java JTS (portée en C++ sous le nom GEOS pour PostGIS, QuantumGIS,...) pour répondre à la question "est-ce que la géométrie est valide" :
- Validateur IGN : https://github.com/IGNF/validator/blob/ … va#L32-L52
- isValid de JTS : https://github.com/locationtech/jts/blo … #L428-L431

La différence tient au fait que nous récupérons la localisation de l'erreur géométrique. L'idée étant, dans la prochaine version du GpU, de permettre le téléchargement du rapport de validation au format GeoJSON pour localiser plus facilement les erreurs de validation géométrique.

Cordialement, L’équipe GPU

Bonsoir,

En premier lieu, merci d'afficher la couleur. Pour des anciens, la chose n'était pas si facile il y a quelques années et comme géoretraité, content de voir la qualité et la visibilité pérenne de cette association

Tout vient à point à qui sait ...

Reste en matière de précision un truc simple, c'est quoi qu'on représente ? Une réalité de terrain à l'échelle communal. Cela s'appelle un plan (non une carte ) et la précision de ce référentiel est centimétrique. Ce référentiel de base, qui se nomme le plan cadastral ( déformé ou non ) est en effet centimétrique. Un éditeur de texte pour visualiser un .Vec d'un fichier Edigéo le démontre aisément.

Suffit de conserver cette précision quand on intègre les données et de s'en servir de référentiel pour toutes les couches qui viennent s'y superposer.
Problème trouver un format d'échange qui permet d'échanger la donnée sans altérer sa précision. C'est pas le shp qui va le faire
Bon Edigéo ça le fait, le WKB aussi alors ...

[Edit] Une précision pour conserver la précision

Il est évident que l'intersection de la droite formée par deux sommets d'un polygone et une autre droite est un point dont les coordonnées sont deux nombres réels, pas forcément des décimaux à deux chiffres, au sens de la géométrie dans R² oui. Pour garantir cette précision entre référentiels géométrique il ne faut pas raisonner en termes de géométrie "euclidienne" mais en topologie.
L'intersection du vecteur formé par deux sommets d'un arc avec un autre arc est un Noeud est les deux arcs précédents deviennent 4.
Ce Noeud a une précision géométrique au centimètre. (Les sommets des arcs aussi )

Dernière modification par ChristopheV (Wed 17 November 2021 13:39)