Le portail francophone de la géomatique

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 (Hier 08:11)