Le portail francophone de la géomatique

Bonjour,

Le sujet de la présence du règlement pdf dans le lot de données conformes au standard CNIG PLU a été débattu lors du dernier GT CNIG DDU du 2 octobre 2025 (§6.1 page 7) :

Le caractère facultatif du règlement graphique sous forme d’image encapsulée en pdf a été affirmé dans le standard CNIG PLU, conformément à la décision du GT DDU le 31 mars 2022.

Cette disposition pourrait être révisée au regard des besoins à couvrir par la liaison GPU - @ctes quoique le GT DDU était déjà convenu en 2022 que l’enjeu est de donner au contrôle de légalité l'accès à toutes les pièces écrites nécessaires sans qu’elles ne soient nécessairement stockées dans le GPU.

Le sujet repose la question du statut juridique du document d’urbanisme numérique version papier vs version standardisée CNIG vs version numérique image (variantes « scan » et « image exportée du SIG »). Il interroge également les pratiques et les besoins du contrôle de légalité, ainsi que la procédure à appliquer par l’autorité compétente en cas de détection d’une erreur dans le document d’urbanisme standardisé et publié sur le GPU.

Le GT DDU maintient le caractère facultatif du règlement graphique sous forme d’image.
Les questions évoquées ci-dessus feront l’objet d’une réunion du SG1 « métier urbanisme ».

Cordialement,
A. Gallais

Afin de vous aider dans la constitution de vos données PLU(i), une nouvelle version majeure d'OMiPLU est disponible au téléchargement !!!

Dans cette dernière version vous aurez notamment la possibilité de pré-valider vos données avant de les déposer sur le GPU

OMiPLU c'est aussi des tutoriels vidéo disponible sur le site

Toutes les infos sur OMiPLU sur https://omiplu.mikkrogeo.com

Bonjour Arnauld,

J'ai le "sentiment" que ce très bon article mériterait d'être lu à la DGALN (MTE):
https://www.axes.fr/upload/documents/an … itaine.pdf

Travailler sur des standards, c'est bien, monter en compétence sur la qualité des données géo, c'est bien aussi

Bruno
PS: je peux déplacer dans un autre sujet...

Bonjour,

Quelques observations sur ce rapport :

1°) (p.2 & 12) La source de données n'est pas la source officielle (ce n'est pas le GPU). Il est possible que ce portail tiers ait réalisé des opérations ayant eu pour effet de dégrader la qualité géométrique des données, alors que les données originelles sont correctes. Notamment, il n'est pas clair que la couche utilisée n'ait pas été produite par reprojection des données téléchargées en coordonnées géographiques depuis le GPU. (Je pense même que c'est le cas, nos PLU n'étant publiés que sur le GPU). Il serait intéressant de reproduire l'analyse directement avec les données des archives publiées sur le GPU.

2°) (p.3) Le rapport mentionne une reprojection. La reprojection est susceptible de modifier la précision des coordonnées, et donc la topologie. Il serait intéressant de reproduire l'analyse avec les données dans leur projection originelle. Précisons que le code EPSG de la projection à portée nationale du système national en vigueur en France métropolitaine est EPSG:9794 (le standard CNIG devrait être corrigé sur ce point).

3°) (p.2) Le rapport mentionne une analyse dans PostGIS. Il aurait été utile de vérifier que l'import ait bien été réalisé en Well-Known Binary (dialecte OGC ou dialecte PostGIS)

4°) (p.3) L'étude du nombre de décimales de la représentation décimale des coordonnées n'est pas un indicateur probant. En interne, les coordonnées sont stockées sous la forme de nombres flottants à double précision binaire (IEEE 754 double), et le nombre de décimales de la représentation décimale de ces nombres n'est pas représentatif de la précision de ce nombre. Par exemple la coordonnée 0x4110000090000000 a la même précision (mantisse de 6 chiffres hexadécimaux) que 0x41100000A0000000 , mais sa représentation décimale 262144.140625 a un chiffre de plus que 262144.15625 . De manière générale, 0.2999 n'est pas plus précis que 0.3 lorsque ce dernier est l'abréviation de 0.3000 .

5°) (p.4) Il serait utile de reproduire l'étude des non-conformités géométriques avec un processus d'import plus fiable. Le rapport indique qu'il travaille sous PostGIS, mais cette capture d'écran provient de QGIS ; il serait intéressant de vérifier que le système de coordonnées du projet QGIS est identique à celui de la couche testée. La concentration des erreurs pourrait être expliquée par l'absence de PLU intercommunaux, les documents d'urbanisme communaux pouvant alors être plus vieux et numérisés avec des logiciels n'ayant pas la même notion de validité, ou utilisant un système de référence autre que Lambert-93, et versés à une époque où les contrôles du GPU étaient peut-être moins poussés. Toutefois, je pense que la principale cause de ces erreurs est que la source des données a reprojeté les données du GPU.

6°) (p.5) Il serait utile de mener une étude identique sur le plan cadastral : ces singularités pourraient être dues au référentiel source.

7°) (p.10) Comme vu précédemment, le nombre de décimales de la représentation décimale des coordonnées n'a aucune importance et n'est pas susceptible d'engendrer des erreurs de topologie. En revanche, les calculs d'aire, et peut-être d'intersection, utilisent des valeurs approchées, et sont susceptibles de voir un recouvrement de 10^-15 m² alors qu'en réalité il n'y a pas de recouvrement. C'est pourquoi tous les algorithmes travaillant avec des doubles proposent un paramètre de tolérance, et l'ignorer est contreproductif. Toutefois, je pense que la principale cause de ces erreurs est que la source des données a reprojeté les données du GPU.

8°) (p.10) Les zones urba en doublon pourraient-elles être causées par l'annulation partielle d'un document d'urbanisme ? Ainsi, il s'agirait d'un choix lors de l'agrégation des données, et non un problème des données sources.

Dernière modification par Alban Kraus (Wed 27 May 2026 08:11)

Bonjour,

Merci pour votre demande, car le bureau métier du ministère de l'écologie (à l'origine des demandes d'évolutions) ne nous avait pas alerté sur cette nouvelle disposition.

Le standard CNIG PLU/CC ne la prend donc pas encore en compte, ni a fortiori le GPU dont l'alimentation repose sur le standard CNIG.

Je la note pour l'évoquer au groupe de travail en vue de la prochaine révision du standard.

En attendant : prévoyez un périmètre d'information (table info) codé 99 00 avec un libellé explicite (champ LIBELLE) de type "périmètre de diagnostic structurel des bâtiments d'habitation collectifs", voire une étiquette (champ TXT) de type "DSBH" de façon à pouvoir les identifier et les basculer par la suite dans le code d'info qui leur sera dédié.

Merci Arnauld pour ce retour.

Bonjour,

Je me permets de déplacer votre question dans ce sujet dédié.
Aunauld, peut-être as-tu la réponse à cette question règlementaire.

Bonne semaine!

Hello
Peux tu partager en SHP le fameux polygone, je vais l analyser avec AutoCAD MAP ...
GeoBye, Pat

J’utilise Open Jump pour les problèmes de géométrie.
In indique exactement les noeuds qui posent problème.
Bon courage

J'exporte le rapport de validation du GPU en GeoJSON, la couche point localise tous les problèmes géométrique.

Bonjour,
Merci beaucoup Elise pour l'astuce, que je ne connaissais pas, d'ouvrir le Json sur QGIS ! ça m'a permis de repérer les erreurs que QGIS ne trouvais pas.
Et le dossier est enfin valide !!! ouf !
Merci à tous pour votre aide !

Bonjour,

Je cherche un fichier de styles complet pour les documents d urbanisme. Vous allez me dire que c est le lien ci dessus, mais j ai déjà passe cette étape.

**
Soit dit en passant, pour telecharger sur GitHub, il a a semble t-il 2 techniques
- le clic droit > telecharger la cible di lien sous
- cliquer pour ouvrir le fichier et quand le code s affiche, aller sur la fleche de telechargement en haut a droite
Les fichiers ne sont pas de le meme taille, pas les meme du tout quand on les ouvre en texte, et dans le 1er cas ne donnent pa ssatisfaction.
Si certains s y connaissent sur le sujet, je suis curieux  d'en savoir plus.
**

Je suis allé sur le geoportail de l'urbanisme, la page de la commune qui m'intéressait et j'ai telecharge le document complet
Dans le dossier "Donnees_geographiques" il y avait 6 shapefiles dans mon cas

242600252_HABILLAGE_TXT_20260224.shp
242600252_INFO_SURF_20260224.shp
242600252_PRESCRIPTION_LIN_20260224.shp
242600252_PRESCRIPTION_PCT_20260224.shp
242600252_PRESCRIPTION_SURF_20260224.shp
242600252_ZONE_URBA_20260224.shp

On reconnait les noms des fichiers qml du lien du message precedent : plu_psc_s.qml correspond aux prescriptions surfaciques d'une couche de surfaces, donc polygone, soit 242600252_PRESCRIPTION_SURF_20260224.shp

Mon problème c'est que ca ne marche pas parfaitement bien de mon point de vue.
La symbologie fonctionne par catégorisation et est basee sur le champ SYMBOLE qui est vide dans mes couches
je pense pouvoir le recréer avec une formule du type 'PSC-s_' ||  "TYPEPSC"  || '-' ||  "STYPEPSC"  || '_001'
J'ai mis 001 en suffixe car c est le plus courant, mais on voit bien dans la symbologie qu'il y en a d autres (voir image avec le suffixe 120 par exemple) et je ne sais pas comment recreer cela.

Par ailleurs, la légende est mal faite, on a le code symbole, qui n'est pas très parlant, au lieu d'un texte explicatif disant a quoi ca correspond.

Bref, je si quelqu un sait ou trouver la symbologie complète, ce serait génial, ou dans une moindre mesure, est ce qu il serait possible de changer la légende (en utilisant le champ du libelle par exemple) en quelques opérations pour tous les symboles a la fois?

Merci

Bonjour Tixi,

J'ai constaté la même chose que toi en téléchargeant les fichiers via le github : le clic droit sur le nom de fichier et "enregistrer sous" importe un fichier inexploitable. Il faut effectivement passer par  "code" et "download zip".
Je ne comprends pas très bien ce qui ne marche pas dans ton cas. La correspondance des noms de code et sous code est dans le pdf du standard :
https://cnig.gouv.fr/IMG/pdf/252212_sta … 025-06.pdf (page 30 et suivantes)

Les champs libelle et nature sont des champs "libres", le modèle de symbologie proposé par le CNIG doit pouvoir s'appliquer quel que soit le PLU(i), il ne peut donc que s'appuyer sur des champs communs (d'où code/sous code/numéro d'ordre).
Les personnes qui travaillent dans le sous-groupe du CNIG dédié à la symbolisation sont presque toutes des bénévoles. Proposer un gabarit avec un nom plus intuitif dans la légende représente du temps et une réflexion pour que ce nom soit le plus fidèle vis-a-vis du code de l'urbanisme tout en restant assez court. Bref, un travail de longue haleine qui devra en fin de chaine être validé par la commission des standards (si j'ai bien compris le fonctionnement du CNIG !).

Bonsoir Arnauld,

Veux-tu que je déplace ce sujet dans le sujet "maitre" ou du moins historique?