Statut registre IGNF dans PostGIS

Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Statut registre IGNF dans PostGIS

Régis Haubourg
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.html
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
Reply | Threaded
Open this post in threaded view
|

Re: Statut registre IGNF dans PostGIS

Even Rouault-2
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
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/francophone


--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
Reply | Threaded
Open this post in threaded view
|

Re: Statut registre IGNF dans PostGIS

Olivier Courtin-2
In reply to this post by Régis Haubourg
Régis,


> - 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?


Hum si le problème 'bloque' c'est souvent qu'il est mal posé ^^


Pour rappel:
 - La définition des systèmes de projection dans PostGIS est réalisée
coté utilisateur,
   'fin tant qu'elle est exprimable dans une syntaxe valide pour Proj4

- Les identifiants sémantiques, de système de projection sont le tuple
  (auth_name, auth_srid)

- Et le srid qui fait office de clef primaire, n'est qu'un alias
pointant sur ce tuple.

- Historiquement il y a une correspondance 1-1 entre le auth_srid et
le srid pour tous
  les systèmes de projection EPSG.

- Mais rien n'empêche, bien entendu, de rajouter de nouveaux systèmes gérés par
  des entités tierces.


Bref il ne peut pas y avoir de collisions, vu que chaque entité
dispose de son espace
de nommage.

Il reste donc juste, a faire un PR pour s'économiser un INSERT sur les
installs futures...


HTH,


O.
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
Reply | Threaded
Open this post in threaded view
|

Re: Statut registre IGNF dans PostGIS

Régis Haubourg
In reply to this post by Even Rouault-2
Merci Even pour le rappel du travail en cours dans le gdal_barn. (et bravo
pour ce chantier titanesque)
Si je comprends bien, il faut pousser ce sujet dans la liste des vœux
postgis3, mais aussi préparer la migration du coté de QGIS (et tous les
autres outils OSGEO).  La gestion des srid en texte est une très bonne
nouvelle !

Si la notion de towgs84 et nadgrid est reportée dans une table de
transformations, penses tu qu'il sera possible d'affecter les
transformations avec grille y compris pour les EPSG:27572 > EPSG:2154 et
consorts?
Cela simplifierait énormément la situation la plus classique rencontrée, et
il serait bien plus simple de faire cela que d'expliquer à tout le monde de
basculer toutes les définitions QGIS, postgis etc vers du IGNF.

Autre question subsidiaire, actuellement, QGIS détecte les chaines proj4 et
les .prj vers du EPSG automatiquement. Qu'en serait il avec deux définitions
similaires EPSG et IGNF? Il y aurait un choix à faire à ce niveau là sur
quel registre privilégier en cas d'incertitude?



 @olivier, pas sûr d'avoir compris entre les lignes. Tu suggère de faire
sauter, ou élargir, la contrainte sur le SRID pour pouvoir intégrer le
registre IGNF ou tu suggère de recodifier le registre IGNF pour coller aux
contraintes PostGIS?
Dans le deuxième cas, toute base de donnée avec des géométries castées en
typmod `geometry(montypegeom, moncodeIGNF) devra être migrée. Et c'est pas
si simple de migrer une base avec des vues qui verrouillent assez fortement
le système de projection. On a beau dire que c'est l'utilisateur qui définit
un alias, il y a un coté "legacy" et migration à réfléchir un peu si on part
sur une recodification du registre postgis.  
Ceci dit, il doit pas y avoir grand monde basant ses vues sur un IGNF... vu
qu'il faut faire sauter la contrainte, et qu'on voit pas tant de monde que
ça poser la question.

Merci à vous deux pour ces retours!



--
Sent from: http://osgeo-org.1560.x6.nabble.com/OSGeo-French-Local-Chapter-f3726325.html
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
Reply | Threaded
Open this post in threaded view
|

Re: Statut registre IGNF dans PostGIS

Olivier Courtin-2
>  @olivier, pas sûr d'avoir compris entre les lignes. Tu suggère de faire
> sauter, ou élargir, la contrainte sur le SRID pour pouvoir intégrer le
> registre IGNF ou tu suggère de recodifier le registre IGNF pour coller aux
> contraintes PostGIS?

Je suggère juste que tu ne te crée pas de contraintes qui n'existe pas ^^

Il n'est écrit nulle part (dans OGC SFS, et donc par extension dans PostGIS)
qu'il soit nécessaire d'avoir une égalité srid == auth_srid.

Et ce pour la bonne et simple raison que cela doit continuer a
fonctionner en multi autorités.
L'ESPG en est une, IGN France en est une autre, Google une troisième...

O.
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
Reply | Threaded
Open this post in threaded view
|

Re: Statut registre IGNF dans PostGIS

Even Rouault-2
In reply to this post by Régis Haubourg
On lundi 24 septembre 2018 12:17:20 CEST Régis Haubourg wrote:

> Merci Even pour le rappel du travail en cours dans le gdal_barn. (et bravo
> pour ce chantier titanesque)
> Si je comprends bien, il faut pousser ce sujet dans la liste des vœux
> postgis3, mais aussi préparer la migration du coté de QGIS (et tous les
> autres outils OSGEO).  La gestion des srid en texte est une très bonne
> nouvelle !
>
> Si la notion de towgs84 et nadgrid est reportée dans une table de
> transformations, penses tu qu'il sera possible d'affecter les
> transformations avec grille y compris pour les EPSG:27572 > EPSG:2154 et
> consorts?

Oui, il faudra rajouter des entrées dans la table qui va bien (je parle au niveau de PROJ),
mais le formalisme le permettra

Pour l'instant cette table
https://github.com/OSGeo/proj.4/blob/922873f221c827c33c5dbabf10ddf607ae586cba/data/sql/grid_transformation.sql
n'est peuplée qu'à partir du registre EPSG, mais l'idée est de pouvoir ajouter d'autres entrées.

En fait tu as déjà les entrées qui vont bien:

INSERT INTO "grid_transformation" VALUES('EPSG','15958','RGF93 to NTF (2)','EPSG','9615','NTv2','EPSG','4171','EPSG','4275','EPSG','3694',1.0,'EPSG','8656','rgf93_ntf.gsb',NULL,NULL,NULL,NULL,NULL,0);
INSERT INTO "grid_transformation" VALUES('EPSG','15959','ETRS89 to NTF (3)','EPSG','9615','NTv2','EPSG','4258','EPSG','4275','EPSG','3694',1.0,'EPSG','8656','rgf93_ntf.gsb',NULL,NULL,NULL,NULL,NULL,0);
INSERT INTO "grid_transformation" VALUES('EPSG','15960','WGS 84 to NTF (3)','EPSG','9615','NTv2','EPSG','4326','EPSG','4275','EPSG','3694',1.0,'EPSG','8656','rgf93_ntf.gsb',NULL,NULL,NULL,NULL,NULL,0);

Sauf que la table intégrée à PROJ s'appelle ntf_r93.gsb, et effectue la transformation dans l'autre sens,
mais bon, en ajoutant une table d'adaptation pour rectifier le tir, on a ce qu'il faut.


> Cela simplifierait énormément la situation la plus classique rencontrée, et
> il serait bien plus simple de faire cela que d'expliquer à tout le monde de
> basculer toutes les définitions QGIS, postgis etc vers du IGNF.
>
> Autre question subsidiaire, actuellement, QGIS détecte les chaines proj4 et
> les .prj vers du EPSG automatiquement. Qu'en serait il avec deux définitions
> similaires EPSG et IGNF? Il y aurait un choix à faire à ce niveau là sur
> quel registre privilégier en cas d'incertitude?

Oui, soit on laisse à l'utilisateur le soin de départager, soit il y a une
logique applicative pour le faire à sa place...

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
Reply | Threaded
Open this post in threaded view
|

Re: Statut registre IGNF dans PostGIS

Régis Haubourg
Merci Even pour les précisions, la cible pour PostGIS3 me parait assez claire.

Plus je creuse en amont et moins je comprends à quel point l'utilisation de grille est décrit par les standards EPSG/OGC.

Un exemple pour OSGB 1936
 -  http://spatialreference.org/ref/epsg/4277/ ne mentionne aucune grille.
 -  EPSG.io, maintenu par Klokantech,  mentionne  qu'il y a une grille de type NTV2 qui permet des reprojection à 1m.Le nom de la grille est fourni dans la page, mais n'est disponible dans aucune des chaînes de définition EPSG / OGC / Proj, ESRI, etc..

Est-ce que cela signifie qu'aucun organisme ne standardise cette notion de grille?
Est-ce que cela implique que c'est à l'utilisateur, comme dans Geoserver [0], d'ajouter lui même les transformations qu'il souhaite? 
Est-ce que cela nous autorise arbitrairement à modifier les définitions EPSG Lambert pour ajouter la grille ign ? Cela serait bien le plus simple pour attendre un postGIS3 plus propre au niveau de la gestion des registres et des transformations.

Régis (en croisade pour une utilisation des grilles simple et à la portée de tous)


Le lun. 24 sept. 2018 à 22:08, Even Rouault <[hidden email]> a écrit :
On lundi 24 septembre 2018 12:17:20 CEST Régis Haubourg wrote:
> Merci Even pour le rappel du travail en cours dans le gdal_barn. (et bravo
> pour ce chantier titanesque)
> Si je comprends bien, il faut pousser ce sujet dans la liste des vœux
> postgis3, mais aussi préparer la migration du coté de QGIS (et tous les
> autres outils OSGEO).  La gestion des srid en texte est une très bonne
> nouvelle !
>
> Si la notion de towgs84 et nadgrid est reportée dans une table de
> transformations, penses tu qu'il sera possible d'affecter les
> transformations avec grille y compris pour les EPSG:27572 > EPSG:2154 et
> consorts?

Oui, il faudra rajouter des entrées dans la table qui va bien (je parle au niveau de PROJ),
mais le formalisme le permettra

Pour l'instant cette table
https://github.com/OSGeo/proj.4/blob/922873f221c827c33c5dbabf10ddf607ae586cba/data/sql/grid_transformation.sql
n'est peuplée qu'à partir du registre EPSG, mais l'idée est de pouvoir ajouter d'autres entrées.

En fait tu as déjà les entrées qui vont bien:

INSERT INTO "grid_transformation" VALUES('EPSG','15958','RGF93 to NTF (2)','EPSG','9615','NTv2','EPSG','4171','EPSG','4275','EPSG','3694',1.0,'EPSG','8656','rgf93_ntf.gsb',NULL,NULL,NULL,NULL,NULL,0);
INSERT INTO "grid_transformation" VALUES('EPSG','15959','ETRS89 to NTF (3)','EPSG','9615','NTv2','EPSG','4258','EPSG','4275','EPSG','3694',1.0,'EPSG','8656','rgf93_ntf.gsb',NULL,NULL,NULL,NULL,NULL,0);
INSERT INTO "grid_transformation" VALUES('EPSG','15960','WGS 84 to NTF (3)','EPSG','9615','NTv2','EPSG','4326','EPSG','4275','EPSG','3694',1.0,'EPSG','8656','rgf93_ntf.gsb',NULL,NULL,NULL,NULL,NULL,0);

Sauf que la table intégrée à PROJ s'appelle ntf_r93.gsb, et effectue la transformation dans l'autre sens,
mais bon, en ajoutant une table d'adaptation pour rectifier le tir, on a ce qu'il faut.


> Cela simplifierait énormément la situation la plus classique rencontrée, et
> il serait bien plus simple de faire cela que d'expliquer à tout le monde de
> basculer toutes les définitions QGIS, postgis etc vers du IGNF.
>
> Autre question subsidiaire, actuellement, QGIS détecte les chaines proj4 et
> les .prj vers du EPSG automatiquement. Qu'en serait il avec deux définitions
> similaires EPSG et IGNF? Il y aurait un choix à faire à ce niveau là sur
> quel registre privilégier en cas d'incertitude?

Oui, soit on laisse à l'utilisateur le soin de départager, soit il y a une
logique applicative pour le faire à sa place...

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

_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
Reply | Threaded
Open this post in threaded view
|

Re: Statut registre IGNF dans PostGIS

Even Rouault-2
On mardi 25 septembre 2018 10:07:04 CEST Régis Haubourg wrote:
> Merci Even pour les précisions, la cible pour PostGIS3 me parait assez
> claire.
>
> Plus je creuse en amont et moins je comprends à quel point l'utilisation de
> grille est décrit par les standards EPSG/OGC.

Quelques liens "utiles":

- OGC Topic 2 - Spatial referencing by coordinates / ISO 19111:2017
http://portal.opengeospatial.org/files/?artifact_id=39049
C'est la modélisation théorique des CRS et des notions de transformation de coordonnées

- WKT 2: http://docs.opengeospatial.org/is/12-063r5/12-063r5.html
Une implémentation basée sur cette modélisation abstraite

- EPSG Guidance Note 7-2
https://www.iogp.org/bookstore/product/coordinate-conversions-and-transformation-including-formulas/
qui décrit les différents types de transformation possibles

>
> Un exemple pour OSGB 1936
>  -  http://spatialreference.org/ref/epsg/4277/ ne mentionne aucune grille.

Comme son nom l'indique :-), spatialreference.org n'est ni un site de référence
ni maintenu depuis une bonne dizaine d'années.
Ceci dit il est normal qu'une définition de CRS ne contienne pas de grille.
Un CRS existe en tant que lui-même. Il n'est pas défini par rapport à un autre.
La notion de noeu TOWGS84 ou EXTENSION["PROJ4_GRIDS", "..."] dans le WKT1 ou
dans les chaines PROJ.4 est un "hack" pour faciliter la vie en passant
par un système WGS84 pivot, ce qui est loin d'être idéal car induit des pertes
de précision.
Cf diapos 26 et 27 de
https://download.osgeo.org/gdal/presentations/GDAL%202.3%20(FOSS4G-E%202018)%20-%2020%20year%20already%20and%20heading%20to%20the%20cloud.pdf
pour quelques limitations de cette approche dite "early binding" vs
l'approche "late binding" où on a d'une part les définitions de CRS et d'autre
part un catalogue de transformations dispoibles pour des couples (src_srs, dst_srs).

>  -  EPSG.io, maintenu par Klokantech,  mentionne  qu'il y a une grille de
> type NTV2 qui permet des reprojection à 1m.Le nom de la grille est fourni
> dans la page, mais n'est disponible dans aucune des chaînes de définition
> EPSG / OGC / Proj, ESRI, etc..

Tu parles de OSTN02_NTv2.gsb ?
C'est discuté dans https://github.com/OSGeo/proj-datumgrid/issues/21
la grille est dispo
https://www.ordnancesurvey.co.uk/business-and-government/help-and-support/navigation-technology/os-net/ostn02-ntv2-format.html

PROJ a maintenu un dépot dédié avec plusieurs paquets de grilles: un paquet
mondial de taille modeste avec les grilles les plus courantes et basse résolution,
et des paquets continentaux/régionaux avec des grilles plus précises:
https://github.com/OSGeo/proj-datumgrid/

Mais oui de manière générale, il peut y avoir des écarts dans le nommage des grilles ou le format effectivement
utilisé. D'où mon idée dans mes travaux à venir d'avoir une sorte de table
d'alias pour faire l'adaptation entre le nom/format du registre officiel et
celui effectivement utilisé.

>
> Est-ce que cela signifie qu'aucun organisme ne standardise cette notion de
> grille?
> Est-ce que cela implique que c'est à l'utilisateur, comme dans Geoserver
> [0], d'ajouter lui même les transformations qu'il souhaite?
> Est-ce que cela nous autorise arbitrairement à modifier les définitions
> EPSG Lambert pour ajouter la grille ign ?

C'est ce qui est fait dans le fichier IGNF de PROJ avec les chains +proj= qui
contiennent un +nadgrids.

> Cela serait bien le plus simple
> pour attendre un postGIS3 plus propre au niveau de la gestion des registres
> et des transformations.
>
> Régis (en croisade pour une utilisation des grilles simple et à la portée
> de tous)

Bonne chance !

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
Reply | Threaded
Open this post in threaded view
|

Re: Statut registre IGNF dans PostGIS

Didier Richard
Bonjour,

(désolé pour mon temps de réponse)

Quelques petites informations si ça peut aider étant à l'origine des registres IGN (xml) et des fichiers comme IGNF, la grille ntf_r93.gsb, fichiers conçus avec l'aide du Service de la Géodésie de l'IGN et de la cellule normalisation de l'époque.

Even m'avait interpellé justement sur la mise à jour du registre il y a quelques mois ... j'ai pris quelques informations depuis, mais pas d'action réelle.

Le registre des systèmes de référence de coordonnées, ainsi que des méthodes de passage d'un système à un autre est diffusé à l'adresse : http://librairies.ign.fr/geoportail/resources/IGNF.xml 
C'est un fichier qui s'appuie sur la norme ISO 19139 ; il décrit les systèmes, les paramètres et les méthodes de transformation entre système et qui sont de la responsabilité de l'IGN. Il fait aussi le lien entre nomenclature IGN et quant elle existe la nomenclature EPSG (enfin, OGP maintenant). Il décrit aussi les transformations (interpolation géocentrique, conversion altimétrique, lambert conique conforme sécant à deux parallèles, etc ...). Du lourd !D
Il existe aussi un registre en ligne : https://registre.ign.fr/ign/IGNF/IGNF/ qui permet aux logiciels qui consomment le registre statique IGNF.xml de naviguer dans les systèmes, paramètres, etc ... registre mis en ligne par l'équipe Géoportail.

Ce registre XML est régulièrement mis à jour (dernière version : mars 2018).

Sur la même page du site de la géodésie (Cf. https://geodesie.ign.fr/index.php?page=documentation#titre3), on trouve aussi un lien vers un script SQL d'import dans PostGIS, fichier que j'avais conçu à l'époque (2008 !-), donc plus à jour ...
Ce qui est important dans ce fichier SQL, c'est en fait la dernière colonne de la table spatial_ref_sys qui contient la chaîne PROJ4 qui fait donc référence au registre IGNF que l'on trouve dans le projet PROJ (sans le 4 maintenant).
C'était la seule façon de faire en sorte que sous PostGIS on puisse effectuer des transformations correctes entre NTF et RGF93 (passage de Lambert II étendue à Lambert 93 par exemple) avec les grilles. La transformation via les codes EPSG étant incorrecte car ne prenant pas en compte la grille d'interpolation bilinéaire nécessaire pour corriger le changement de géoïde.

Idéalement, il faudrait usiner un script pour fabriquer automagiquement les registres IGNF (PROJ, WKT et PostGIS). J'ai un tel script XSLT qui s'occupe uniquement de PROJ et qui date de ... 2008 (mais la structure du IGNF.xml n'a pas changé, donc ça devrait le faire encore) !

Le véritable enjeu de la transformation du registre IGNF (xml ISO 19139) en quelque chose de consommable par PROJ et ces consommateurs, c'est celui des grilles car il en existe un paquet ... Elles sont toutes accessibles via https://geodesie.ign.fr/index.php?page=documentation#titre6 qui donne aussi bien la grille NTF RGF93 (Cf. https://geodesie.ign.fr/contenu/fichiers/gr3df97a.txt ) que les grilles de conversion altimétriques :
* http://geodesie.ign.fr/contenu/fichiers/documentation/grilles/outremer/ggm00.txt
* http://geodesie.ign.fr/contenu/fichiers/documentation/grilles/outremer/ggg00_ls.txt
* ggg00_lsv2.mnt
* http://geodesie.ign.fr/contenu/fichiers/documentation/grilles/outremer/ggg00_sb.txt 
* ...
Elles sont toutes là : https://geodesie.ign.fr/index.php?page=grilles

Le hic, c'est :

1) IGNF.xml en référence certaines complètement (URL), certaines par le nom (e.g. ggg00_lsv2.mnt)
2) IGNF.xml en référence certaines par un format (.txt), certaines par un autre format (.mnt)
    (Cf. https://geodesie.ign.fr/contenu/fichiers/documentation/grilles/notices/Grilles-MNT-TXT_Formats.pdf)
3) IGNF donne des noms qui ne sont pas très "parlants" !

Il faut donc transformer ces grilles dans un format consommable par PROJ (c'est ce que l'IGN a fait à l'époque pour la grille NTF <-> RGF93) ... et fabriquer ainsi les bonnes chaînes WKT et PROJ (et mettre à jour le registre IGNF dans PROJ avec les quelques nouveaux systèmes sur les îles entre autres).

Voilà, si on peut effectivement avancer collectivement sur la prise en compte de tout cela, ça serait hyper-cool !

@+
--
RICHARD Didier - Chef du service ValiLab
http://fr.linkedin.com/pub/didier-richard/98/2a3/a8/ - https://www.osgeo.org/member/didier/
6/8 avenue Blaise Pascal - BP Champs-sur-Marne - 77455 MARNE-LA-VALLÉE CEDEX 2
Tél : +33 (0) 1 43 98 83 23


________________________________________
De : Francophone [[hidden email]] de la part de Even Rouault [[hidden email]]
Envoyé : mardi 25 septembre 2018 10:33
À : Régis Haubourg
Cc : Francophone local chapter discussions
Objet : Re: [Francophone] Statut registre IGNF dans PostGIS

On mardi 25 septembre 2018 10:07:04 CEST Régis Haubourg wrote:
> Merci Even pour les précisions, la cible pour PostGIS3 me parait assez
> claire.
>
> Plus je creuse en amont et moins je comprends à quel point l'utilisation de
> grille est décrit par les standards EPSG/OGC.

Quelques liens "utiles":

- OGC Topic 2 - Spatial referencing by coordinates / ISO 19111:2017
http://portal.opengeospatial.org/files/?artifact_id=39049
C'est la modélisation théorique des CRS et des notions de transformation de coordonnées

- WKT 2: http://docs.opengeospatial.org/is/12-063r5/12-063r5.html
Une implémentation basée sur cette modélisation abstraite

- EPSG Guidance Note 7-2
https://www.iogp.org/bookstore/product/coordinate-conversions-and-transformation-including-formulas/
qui décrit les différents types de transformation possibles

>
> Un exemple pour OSGB 1936
>  -  http://spatialreference.org/ref/epsg/4277/ ne mentionne aucune grille.

Comme son nom l'indique :-), spatialreference.org n'est ni un site de référence
ni maintenu depuis une bonne dizaine d'années.
Ceci dit il est normal qu'une définition de CRS ne contienne pas de grille.
Un CRS existe en tant que lui-même. Il n'est pas défini par rapport à un autre.
La notion de noeu TOWGS84 ou EXTENSION["PROJ4_GRIDS", "..."] dans le WKT1 ou
dans les chaines PROJ.4 est un "hack" pour faciliter la vie en passant
par un système WGS84 pivot, ce qui est loin d'être idéal car induit des pertes
de précision.
Cf diapos 26 et 27 de
https://download.osgeo.org/gdal/presentations/GDAL%202.3%20(FOSS4G-E%202018)%20-%2020%20year%20already%20and%20heading%20to%20the%20cloud.pdf
pour quelques limitations de cette approche dite "early binding" vs
l'approche "late binding" où on a d'une part les définitions de CRS et d'autre
part un catalogue de transformations dispoibles pour des couples (src_srs, dst_srs).

>  -  EPSG.io, maintenu par Klokantech,  mentionne  qu'il y a une grille de
> type NTV2 qui permet des reprojection à 1m.Le nom de la grille est fourni
> dans la page, mais n'est disponible dans aucune des chaînes de définition
> EPSG / OGC / Proj, ESRI, etc..

Tu parles de OSTN02_NTv2.gsb ?
C'est discuté dans https://github.com/OSGeo/proj-datumgrid/issues/21
la grille est dispo
https://www.ordnancesurvey.co.uk/business-and-government/help-and-support/navigation-technology/os-net/ostn02-ntv2-format.html

PROJ a maintenu un dépot dédié avec plusieurs paquets de grilles: un paquet
mondial de taille modeste avec les grilles les plus courantes et basse résolution,
et des paquets continentaux/régionaux avec des grilles plus précises:
https://github.com/OSGeo/proj-datumgrid/

Mais oui de manière générale, il peut y avoir des écarts dans le nommage des grilles ou le format effectivement
utilisé. D'où mon idée dans mes travaux à venir d'avoir une sorte de table
d'alias pour faire l'adaptation entre le nom/format du registre officiel et
celui effectivement utilisé.

>
> Est-ce que cela signifie qu'aucun organisme ne standardise cette notion de
> grille?
> Est-ce que cela implique que c'est à l'utilisateur, comme dans Geoserver
> [0], d'ajouter lui même les transformations qu'il souhaite?
> Est-ce que cela nous autorise arbitrairement à modifier les définitions
> EPSG Lambert pour ajouter la grille ign ?

C'est ce qui est fait dans le fichier IGNF de PROJ avec les chains +proj= qui
contiennent un +nadgrids.

> Cela serait bien le plus simple
> pour attendre un postGIS3 plus propre au niveau de la gestion des registres
> et des transformations.
>
> Régis (en croisade pour une utilisation des grilles simple et à la portée
> de tous)

Bonne chance !

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
Reply | Threaded
Open this post in threaded view
|

Re: Statut registre IGNF dans PostGIS

Régis Haubourg
Salut Didier,
merci pour ta réponse, ça commence à s'éclaircir un peu pour moi (qui ne
suit pas géodésien pour un sous).

J'ai regardé le fichier ISO19139, il pointe vers un fichier texte de grille
qui est mort:

https://geodesie.ign.fr/contenu/fichiers/documentation/rgf93/gr3df97a.txt

>Le hic, c'est :
>
>1) IGNF.xml en référence certaines complètement (URL), certaines par le nom
(e.g. ggg00_lsv2.mnt)
>2) IGNF.xml en référence certaines par un format (.txt), certaines par un
autre format (.mnt)
>   (Cf.
> https://geodesie.ign.fr/contenu/fichiers/documentation/grilles/notices/Grilles-MNT-TXT_Formats.pdf)
>3) IGNF donne des noms qui ne sont pas très "parlants" !

Ouille le sac de noeud, je m'étais uniquement focalisé sur la grille
Métropole NTF->RGF93, merci pour l'info.
Ce coup de ménage du registre des transformations et des grilles, c'est un
chantier IGN essentiellement si je comprends bien?


> Voilà, si on peut effectivement avancer collectivement sur la prise en
> compte de tout cela, ça serait hyper-cool !

Oh yes! Je pense qu'on a un beau chantier pour Proj5 avec la prise en compte
d'une vrai base de données de transformations possibles, et l'adaptation des
outils aval comme QGIS, PostGIS, Geoserver etc...

Concernant la situation actuelle dans postGIS 2, et QGIS, on est pas en
cohérence. Le registre IGNF est déjà dans la base de QGIS, mais pas dans
PostGIS. Dans tous les cas, peu d'utilisateurs connaissent le registre IGNF,
et la plupart des admin SIG ont besoin d'une cohérence entre srid dans
PostGIS et QGIS. Je me pose la question d'aller modifier les chaines proj4
dans les registres EPSG de QGIS et PostGIS pour qu'au moins les
transformations utilisant des définitions EPSG (ie la majorité dans les
faits) se déroulent bien.

Que pense tu de cette étape intermédiaire pour limiter la casse en attendant
un registre IGNF homogène et des outils gérant les transformations
proprement?



--
Sent from: http://osgeo-org.1560.x6.nabble.com/OSGeo-French-Local-Chapter-f3726325.html
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
Reply | Threaded
Open this post in threaded view
|

Re: Statut registre IGNF dans PostGIS

Even Rouault-2
In reply to this post by Didier Richard
Salut Didier,

Merci pour ces infos très précieuses.

Pour l'instant, dans le cadre de mes travaux pour PROJ 6, j'avais fait il y a
quelques jours une moulinette d'ingestion du fichier "IGNF" qui contient les
chaines PROJ.4 pour les mettre dans un formalisme compatible de la
structuration ISO-19111 (telle qu'employée par la base de données EPSG), qui
sera utilisé pour la nouvelle base de données de CRS et de transformations de
coordonnées

Le résultat est là
https://github.com/rouault/proj.4/blob/iso19111/data/sql/ignf.sql

Mais il est clair qu'il aurait été mieux de repartir
de https://registre.ign.fr/ign/IGNF/IGNF/ si j'avais su. Pour une prochaine
itération...

Plus de détails et contexte général dans
https://github.com/OSGeo/proj.4/pull/1149
http://even.rouault.free.fr/proj_cpp_api/rfc-2.html#database

Exemple:

- Requête de la définition d'IGNF:LAMB1 en chaine WKT2

$ projinfo IGNF:LAMB1 -o WKT2_2018

WKT2_2018 string:
PROJCRS["Lambert I",
    BASEGEOGCRS["Nouvelle Triangulation Francaise Paris grades",
        DATUM["Nouvelle Triangulation Francaise Paris grades",
            ELLIPSOID["Clarke 1880 (IGN)",6378249.2,293.466021293627,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Paris",2.5969213,
            ANGLEUNIT["grad",0.0157079632679489]]],
    CONVERSION["Conversion for Lambert I",
        METHOD["Lambert Conic Conformal (1SP)",
            ID["EPSG",9801]],
        PARAMETER["Latitude of natural origin",49.5,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.99987734,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",600000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",200000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["easting (X)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["northing (Y)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["unknown"],
        AREA["World"],
        BBOX[-90,-180,90,180]],
    ID["IGNF","LAMB1"]]

- Requête des transformations possibles de IGNF:LAMB1 vers EPSG:4326 sous
forme de pipeline de transformation compatible PROJ5

$ projinfo -s IGNF:LAMB1 -t EPSG:4326 -o PROJ
-------------------------------------
Operation n°1:

PROJ string:
+proj=pipeline +step +inv +proj=lcc +lat_1=49.5 +lat_0=49.5 +lon_0=0
+k_0=0.99987734 +x_0=600000 +y_0=200000 +ellps=clrk80ign +pm=paris +step
+proj=hgridshift +grids=ntf_r93.gsb +step +proj=unitconvert +xy_in=rad
+xy_out=deg +step +proj=axisswap +order=2,1

-------------------------------------
Operation n°2:

PROJ string:
+proj=pipeline +step +inv +proj=lcc +lat_1=49.5 +lat_0=49.5 +lon_0=0
+k_0=0.99987734 +x_0=600000 +y_0=200000 +ellps=clrk80ign +pm=paris +step
+proj=cart +ellps=clrk80ign +step +proj=helmert +x=-168 +y=-60 +z=320 +step
+inv +proj=cart +ellps=WGS84 +step +proj=unitconvert +xy_in=rad +xy_out=deg
+step +proj=axisswap +order=2,1

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone
Reply | Threaded
Open this post in threaded view
|

Re: Statut registre IGNF dans PostGIS

Even Rouault-2
Bonsoir,

>
> Pour l'instant, dans le cadre de mes travaux pour PROJ 6, j'avais fait il y
> a quelques jours une moulinette d'ingestion du fichier "IGNF" qui contient
> les chaines PROJ.4 pour les mettre dans un formalisme compatible de la
> structuration ISO-19111 (telle qu'employée par la base de données EPSG),
> qui sera utilisé pour la nouvelle base de données de CRS et de
> transformations de coordonnées
>

Petite mise à jour concernant ce sujet:
- les travaux dans PROJ que je mentionnais il y a quelques semaines ont été
fusionnés dans le 'master' PROJ
- grâce à l'aide de Didier qui a éclairci la license du registre et des
grilles IGNF, la base de données de PROJ intègre un import de la dernière
version du registre (depuis le registre XML donc) et le paquet proj-datumgrid-
europe
(https://github.com/OSGeo/proj-datumgrid/tree/master/europe ) contient
désormais l'ensemble des grilles verticales converties au format GTX
utilisable par PROJ.

Par exemple conversion de Lambert II étendu vers Lambert 93, si vous disposez
de la grille ntf_r93.gsb (fournie par le paquet général de grilles https://
download.osgeo.org/proj/proj-datumgrid-1.8.zip ) dans le répertoire data de
l'installation de PROJ, l'utilisation des codes EPSG ou IGNF donnera le même
résultat.

$ PROJ_LIB=data src/projinfo -s EPSG:27572 -t EPSG:2154 | head
-------------------------------------
Operation n°1:

unknown id, Inverse of Lambert zone II + NTF (Paris) to NTF (1) + Inverse of
RGF93 to NTF (2) + Lambert-93, 1 m, France - onshore - mainland and Corsica

PROJ string:
+proj=pipeline +step +inv +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
+k_0=0.99987742 +x_0=600000 +y_0=2200000 +ellps=clrk80ign +pm=paris +step
+proj=hgridshift +grids=ntf_r93.gsb +step +proj=lcc +lat_0=46.5 +lon_0=3
+lat_1=49 +lat_2=44 +x_0=700000 +y_0=6600000 +ellps=GRS80

vs

$ PROJ_LIB=data src/projinfo -s IGNF:LAMBE -t IGNF:LAMB93 | head
-------------------------------------
Operation n°1:

unknown id, Inverse of LAMBERT II ETENDU + NTF geographiques Paris (gr) vers
NTF GEOGRAPHIQUES GREENWICH (DMS) + NOUVELLE TRIANGULATION DE LA FRANCE (NTF)
vers RGF93 (ETRS89) + LAMBERT-93, unknown accuracy, FRANCE METROPOLITAINE

PROJ string:
+proj=pipeline +step +inv +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
+k_0=0.99987742 +x_0=600000 +y_0=2200000 +ellps=clrk80ign +pm=paris +step
+proj=hgridshift +grids=ntf_r93.gsb +step +proj=lcc +lat_0=46.5 +lon_0=3
+lat_1=44 +lat_2=49 +x_0=700000 +y_0=6600000 +ellps=GRS80


Ceux qui se sentent de compiler PROJ master depuis les sources
( https://github.com/OSGeo/proj ) sont invités à le faire et signaler les
éventuels problèmes détectés.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Francophone mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/francophone