Le portail francophone de la géomatique

Je dirais qu'il faudrait plutôt employer l'option -s_srs srs_def : écrase la source SRS.

http://georezo.net/wiki/main:logiciels: … gr_ogr2ogr

C'est t_srs les reprojections.

Si tu regardes les dates des fichiers, est-ce que tu peux remarquer que ogr2ogr écrit bien les infos demandées ? À voir si ogr2ogr ne peut que écrire un nouveau jeu de données, et non le mettre à jour, et donc essayer de mettre un jeu de données de destination, quitte à renommer ensuite quelques fichiers.

Je parlais des infos de porjections que tu demandes à être écrites.

Ce que je disais c'est si tu fais

ogr2ogr -f "MapInfo File" -s_srs "EPSG:27572" couche_27572.TAB couche.TAB

C'est

ogrinfo couche.TAB -al

qui t'intéresse !

La commande 'ogr2ogr -f "MapInfo File" -s_srs "EPSG:2154" -t_srs "EPSG:27572" D:\tests\BDCARTO\PROJECTIONS-AUTRES\couche_27572.TAB D:\tests\BDCARTO\couche_2154.TAB' est tout à fait correcte. Le fichier destination est bien le 1er fichier dans la ligne (c'est une des bizarreries célèbres de ogr2ogr)

Un coup d'oeil rapide au code chargé de gérer les systèmes de coordonnées dans le driver MapInfo (http://trac.osgeo.org/gdal/browser/trun … ordsys.cpp) me laisse penser que la projection Lambert Conformal Conic utilisée par EPSG:27572 n'est pas prise en charge - en écriture au moins - par le driver (par contre Lambert Conformal Conic 2SP semble prise en compte).

Limitation intrinsèque du format ou driver perfectible ? Je ne saurais dire. Il peut être pertinent toutefois d'ouvrir un ticket GDAL dans Trac : http://trac.osgeo.org/gdal/newticket

Dernière modification par rouault (Wed 16 December 2009 16:34)

Essayer avec un autre SRS connu pour marcher peut être une solution. C'est ce que j'ai fait d'ailleurs en utilisant le célèbre EPSG:4326 et ça fonctionnait bien, alors qu'avec EPSG:27572 non, ce qui, en plus de matter le code source, me fait dire que la projection Lambert Conformal Conic n'est pas gérée actuellement.

J'ajouterais qu'il est inutile d'essayer -update pour agir sur le SRS, car le SRS d'un layer OGR ne peut être affecté qu'à sa création. -update ne permet que d'ouvrir en mode mis à jour, pour suivant les capacités du driver, mettre à jour des "features" existant, en ajouter ou en supprimer.

baobazz,

Tu peux faire confiance à rouault à mon avis

Y.

mea culpa, rouault, j'avais mal lu ton post
je n'avais pas remarqué le moment où tu disais que 27572 n'était ptet pas pris en charge pour l'opération que je souhaitais faire
est-ce que ça vaut le coup d'ouvrir un ticket pour signaler ce problème?

Dernière modification par baobazz (Thu 17 December 2009 15:40)

Mince il faut un compte spécial pour déposer des tickets...

OK je vais te donner ça mais avant, je vais dire comment j'ai résolu mon souci. Vous connaissez sûrement la manip' mais ça peut aider d'autres personnes.

Pour les couches reprojetées en RGF93 et pour lesquelles ogrinfo indiquait un srs WGS84 (alors qu'elles étaient bien en RGF93), j'ai effectué la manip' suivante:

Copie du contenu du WKT de RGF93 dans un fichier txt appelé RGF93

Le WKT est le suivant:

PROJCS["unnamed",
    GEOGCS["unnamed",
        DATUM["GRS_80",
            SPHEROID["GRS 80",6378137,298.257222101],
            TOWGS84[0,0,0,0,0,0,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",44],
    PARAMETER["standard_parallel_2",49],
    PARAMETER["latitude_of_origin",46.5],
    PARAMETER["central_meridian",3],
    PARAMETER["false_easting",700000],
    PARAMETER["false_northing",6600000],
    UNIT["Meter",1.0]]

Puis lancement de la commande:

ogr2ogr -a_srs "RGF93.txt" macouche_2154_2.TAB macouche_2154.TAB -f "MapInfo File"

Cette fois, le

ogrinfo -al -where fid=1 macouche_2154_2.TAB

(cela permet de restreindre la fenêtre d'affichage) me donne bien le RGF93

Dernière modification par baobazz (Thu 17 December 2009 17:32)

C'est décrit les différnetes documentations de la syntax de proj

Yves, je t'ai envoyé le ticket en message privé.
Merci beaucoup.

"Pour ce qui est des srs connux, 27572 et 2154 sont des standards à présent"

Hum, comment dire ? ... standard ... pour les utilisateurs français ... D'une manière générale, la gestion des SRS est quelque chose qui n'est pas parfait et qui ne le sera probablement jamais. C'est un des aspects les plus cauchemardesques à gérer pour un logiciel comme GDAL/OGR : multitudes de systèmes de projection, multitudes de datum, multitudes de géoides... sans parler des variantes orthographiques qui se retrouvent dans la nature pour des SRS, datum ou géoides identiques (il suffit de penser que rien que pour le WKT il y a le OGC WKT, le ESRI WKT, le ORACLE WKT... les curieux liront http://home.gdal.org/projects/opengis/wktproblems.html pour apprécier la difficulté de l'exercice). Qui plus est, tout cela est géré de façon différente pour chaque format (format propriétaire pour MapInfo, , donc il ne faut pas être surpris que tel SRS marche et pas tel autre, et avec tel format mais pas avec tel autre.

Le signaler par un ticket est une bonne façon que ça soit au moins connu et répertorié, et dans les jours fastes corrigé (je ne veux pas donner trop d'espoir. La probabilité est toutefois nettement augmentée quand un patch correctif est attaché au ticket ;-) ).

Concernant le fait de devoir passer par un rgf93.txt, l'explication est la suivante. Visiblement, l'encodage d'un datum au format interne MapInfo se fait en identifiant la chaine du datum et en la remplaçant par l'entier correspondant dans une table de référence. Elle se trouve ici : http://trac.osgeo.org/gdal/browser/trun … ialref.cpp . La chaine "GRS_80" se trouve bien à la ligne 242, donc c'est OK. Par contre, l'expansion de EPSG:2154 donne "Reseau_Geodesique_Francais_1993" comme nom de datum, qui n'existe pas dans la table, et dans ce cas à défaut de correspondance exacte, le code se rabat sur WGS84. Reste à savoir si la table est incomplète ou si Mapinfo ne prévoit tout simplement pas ce datum !

Des questions spécifiques sur les problématiques liées au format MapInfo peuvent être également adressées directement à la mailing list MITAB (qui est la librairie intégrée à OGR pour gérer le format MapInfo) : http://tech.groups.yahoo.com/group/mitab/

(Au fait, mon prénom, c'est Even)

Dernière modification par rouault (Thu 17 December 2009 22:41)

Chouette, M. Rouault nous fait connaitre son prénom !

Even,

MapInfo connait bien les standards français en matière de SRS.

J'ai quand même l'impression que le problème est avant tout de savoir les choix qu'à fait MITAB/OGR/GDAL/PROJ/... comme par exemple se rabattre sur WGS84. À propos du passage entre 27572 et 2154, une des informations la plus importante est de savoir que la méthode towgs84 indiqué a bien été appliqué (utilisation de la "nadgrid" de l'IGN) ou si elle n'a pas été trouvée si ce sont les paramètres standard.

GDAL n'est pas assez bavard, et lorsqu'il y a des soucis, on ne s'en aperçoit qu'après des opérations de vérifications supplémentaires