[Francophone] Statut registre IGNF dans PostGIS

Even Rouault even.rouault at spatialys.com
Mon Sep 24 09:53:54 PDT 2018


Salut Régis,

Sans répondre dans le détail à tes questions, je voulais juste rappeler que je 
suis en train de faire un gros refactoring de la gestion des CRS dans PROJ et 
GDAL (cf https://gdalbarn.com/).
Je n'ai pas regardé (encore?) comment intégrer le registre IGNF dans la 
nouvelle base de données de CRS & opérations sur les coordonnées, mais 
typiquement le code sera une chaine de caractère, donc pas de souci pour les 
codes IGNF.
Je ne sais pas comment PostGIS prendra ça en compte in-fine (probablement dans 
un 1er temps à l'identique de l'existant), mais on peut imaginer qu'à terme 
PostGIS revoit substantiellement sa façon de faire pour la gestion des 
changements de datum (PostGIS 3 qui se profile serait un bon moment pour 
éventuellement modifier le schéma de spatial_ref_sys). Typiquement la notion 
de +towgs84 / +nadgrids dans des chaines PROJ va devenir obsolète et la 
solution serait plutôt de rechercher les transformations associées à un couple 
(souce_crs, target_crs) dans une table dédiée.

Even

> Bonjour à tous,
> 
> Je (re) découvre une situation très spécifique au contexte français lorsque
> l'on utilise le couple QGIS /PostGIS, qui traine depuis quelques années.
> 
> En synthèse, le registre des SRS IGNF est actuellement inclus dans proj4
> (Merci Didier), Geoserver (Merci Gilles), QGIS (merci qui?) mais pas dans
> PostGIS.
> 
> Cette situation implique que les utilisateurs souhaitant utiliser le
> registre IGNF dans PostGIS - et donc l'appel à la grille de reprojection
> métropolitaine des anciens Lambert vers les nouveaux - sont amener à faire
> de la bricole compliquée dans PostGIS. Ces bricoles sont à même de sauter
> pendant les mises à jour PostGIS, et en plus les identifiants de registre ne
> sont pas acceptés par les contraintes sur la longueur de l'ID dans PostGIS.
> Par ailleurs, même avec les registres IGNF bien intégrés, 99% des
> utilisateurs ne connaissent pas ce registre, et utilisent les codes EPSG. Ce
> qui aboutit encore et toujours à des dégradations de données pendant les
> reprojections.
> 
> Et oui, dans la réalité, on va encore devoir écluser le patrimoine de
> données en lambert2 et consorts pendant quelques (dizaines) d'années, malgré
> l'obligation d'échange en RGF93 depuis près de 10 ans.
> 
> Une bonne synthèse des problèmes est ici:
> https://georezo.net/forum/viewtopic.php?id=96995
> 
> Je me dis que l'OSGEO-fr serait totalement dans son rôle d'essayer de sortir
> par le haut de cette situation un peu compliquée.
> 
> Parmi les questions que je souhaiterais lever, l'essentiel est là:
> 
> - Si nous contribuons le registre à PostGIS, Comment assurer la maintenance
> avec les services de l'IGN qui les produisent? La numérotation utilisée
> bloque, vaut-il mieux modifier PostGIS ou les déclarations SQL du registre
> IGNF disponibles en ligne?
> 
> - Est-il imaginable de faire corriger le registre EPSG en amont pour
> intégrer les déclarations de grille nadgrid IGN (qui sont déjà disponibles
> dans proj4), et ainsi espérer voir moins souvent des données altérées par
> mégarde ?
> 
> Y a t-il des problématiques de gouvernance EPSG-IGN qui m'échappent et qui
> expliquerait notre spécificité nationale?
> 
> En tout cas, je suis preneur d'avis, car la réaction des clients en
> formation-conseil donne vraiment envie de leur rendre la vie plus simple..
> 
> Régis
> 
> 
> 
> --
> Sent from:
> http://osgeo-org.1560.x6.nabble.com/OSGeo-French-Local-Chapter-f3726325.htm
> l _______________________________________________
> Francophone mailing list
> Francophone at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/francophone


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the Francophone mailing list