Le portail francophone de la géomatique

Ferraton · Thu 25 August 2011 16:38

Bonjour,

J'ai un (gros) problème avec l'export des couches QGIS vers le format TAB en ce qui concerne les projections Lambert 93.

Je pars fichier d'un fichier COMMUNEL93.TAB sous MapInfo en Lambert 93. (système de coordonnées français - Lambert 93 français)

sous MIF la codification est la suivante :
CoordSys Earth Projection 3, 33, "m", 3, 46.5, 44, 49, 700000, 6600000 Bounds (-112761336.458, -100805724.408) (114161336.458, 126116948.507)

un ogrinfo -so COMMUNEL93.TAB COMMUNEL93 renvoi les élements de projections (WKT) suivants :

Code:

Layer name: COMMUNEL93
Geometry: Unknown (any)
Feature Count: 221
Extent: (276224.971785, 6649968.037969) - (404193.020878, 6757884.972759)
Layer SRS WKT:
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]]
INSEE_Région: String (2.0)
Nom_Région: String (30.0)
INSEE_Département: String (2.0)
Nom_Département: String (30.0)
INSEE_Arrondissement: String (1.0)
INSEE_Canton: String (2.0)
Id_BDCarto: Integer (0.0)
Nom_Commune: String (50.0)
INSEE_Commune: String (5.0)
Statut: String (20.0)
Abscisse_Commune: Integer (0.0)
Ordonnée_Commune: Integer (0.0)
Superficie: Integer (0.0)
Population: Integer (0.0)
EXTRACTION_IGN: String (16.0)
RECETTE: Date (10.0)

Dans lequel on notera en particulier le DATUM = GRS80 et les parallèles standards l1=44 et l2=49

si on ouvre ce fichier sous QGIS (format MapInfo) la projection est
USER:100004 - * SCR généré (+proj=lcc +lat_1=44 +lat_2=49 +lat_0=46.5 +lon_0=3 +x_0=700000 +y_0=6600000 +ellps=GRS80 +towgs84=0,0,0,-0,-0,-0,0 +units=m +no_defs)

QGIS ne reconnait pas la projection Lambert93 EPSG2154 qui a elle pour chaine
+proj=lcc +lat_1=49 +lat_2=44 +lat_0=46.5 +lon_0=3 +x_0=700000 +y_0=6600000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
en particulier parce que dans la définition EPSG il y a une inversion des paramètres lat_1 et lat_2

Si maintenant je sauvegarde sans aucune modification le fichier ouvert sous QGIS sous le nom COMMUNEL93_QGIS en gardant le SCR origine
et que j'effectue le même ogrinfo j'obtiens le résultat suivant

Code:

Layer name: COMMUNEL93_QGIS
Geometry: Unknown (any)
Feature Count: 221
Extent: (276224.970000, 6649968.045000) - (404193.030000, 6757884.975000)
Layer SRS WKT:
PROJCS["unnamed",
    GEOGCS["unnamed",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563],
            TOWGS84[0,0,0,-0,-0,-0,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",49],
    PARAMETER["standard_parallel_2",44],
    PARAMETER["latitude_of_origin",46.5],
    PARAMETER["central_meridian",3],
    PARAMETER["false_easting",700000],
    PARAMETER["false_northing",6600000],
    UNIT["Meter",1.0]]
INSEE_Région: String (2.0)
Nom_Région: String (30.0)
INSEE_Département: String (2.0)
Nom_Département: String (30.0)
INSEE_Arrondissement: String (1.0)
INSEE_Canton: String (2.0)
Id_BDCarto: Integer (0.0)
Nom_Commune: String (50.0)
INSEE_Commune: String (5.0)
Statut: String (20.0)
Abscisse_Commune: Integer (0.0)
Ordonnée_Commune: Integer (0.0)
Superficie: Integer (0.0)
Population: Integer (0.0)
EXTRACTION_IGN: String (16.0)
RECETTE: String (10.0)

Dans lequel on notera que le Datum est devenu WGS_1984 et que l1=49 et l2=44
en ouverture sous MapInfo la projection n'est pas reconnue.

Si maintenant j'affecte la projection Lambert 93 EPSG 2154 à ma couche sous QGIS avant de la sauvegarder le résultat est le même
datum=WGS84 et l1=49 et l2=44
si j'essaye avec la projection IGNF:LAMB93 le résultat est
datum=WGS84 et l1=44 et l2=49... dans ce cas l'ordre des parallèles standards est correct mais pas le DATUM.

Dans tous les cas la projection n'est pas reconnue par MapInfo qui attend un code 33 (GRS80) pour le datum au lieu de 104 (WGS84)

En fait si on liste les datum de proj4 avec un ordre de type proj -ld on obtient

Code:

__datum_id__ __ellipse___ __definition/comments______________________________
       WGS84 WGS84        towgs84=0,0,0                 
      GGRS87 GRS80        towgs84=-199.87,74.79,246.62  
                          Greek_Geodetic_Reference_System_1987
       NAD83 GRS80        towgs84=0,0,0                 
                          North_American_Datum_1983
       NAD27 clrk66       nadgrids=@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat
                          North_American_Datum_1927
     potsdam bessel       towgs84=606.0,23.0,413.0      
                          Potsdam Rauenberg 1950 DHDN
    carthage clark80      towgs84=-263.0,6.0,431.0      
                          Carthage 1934 Tunisia
hermannskogel bessel       towgs84=653.0,-212.0,449.0    
                          Hermannskogel
       ire65 mod_airy     towgs84=482.530,-130.596,564.557,-1.042,-0.214,-0.631,8.15
                          Ireland 1965
      nzgd49 intl         towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993
                          New Zealand Geodetic Datum 1949
      OSGB36 airy         towgs84=446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894
                          Airy 1830

dans lequel ne figure par le GRS80...

En conclusion ogr2ogr ne semble pas exporter correctement les projections Lambert93 vers MapInfo (chaine proj4 inversant les paramètres lat1 et lat2 et datum WGS84 au lieu de GRS80.

est-ce que quelqu'un aurait une idée et éventuellement une suggestion pour reporter ce problème sur le forum qui va bien (qgis-dev ? gdal-dev,...) ???

Ferraton · Fri 26 August 2011 11:05

Un petit complément plus simple pour comprendre le pb....

sous QGIS sauvegarder une couche (enregistrer sous) en Lambert93 EPSG2154 en format MapInfo (TAB), puis la réouvrir sous QGIS...

QGIS ne reconnait pas la projection ! la cause en est que dans la chaine proj4 il y a entre autre +ellps=WGS84 au lieu de +ellps=GRS80...
(pour les calculs de projection çà ne change pas grand chose puisque les 2 datums sont presque identiques)

Je suis toujours preneur d'information (bug connu ? sinon ou déposer un ticket ?)... a priori çà doit plutôt venir de ogr2ogr

nb : même si on tente de forcer la projection du .TAB avec
ogr2ogr -a_srs 2154.prj -f "MapInfo File" MaTable_new.TAB MaTable.tab

avec 2154.prj contenant

Code:

PROJCS["unnamed",
    GEOGCS["unnamed",
        DATUM["GRS_80",
            SPHEROID["GRS80",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",49],
    PARAMETER["standard_parallel_2",44],
    PARAMETER["latitude_of_origin",46.5],
    PARAMETER["central_meridian",3],
    PARAMETER["false_easting",700000],
    PARAMETER["false_northing",6600000],
    UNIT["Meter",1]]

QGIS ne reconnait pas la projection... la comparaison des chaines proj4 donne :
chaine lue =
+proj=lcc +lat_1=49 +lat_2=44 +lat_0=46.5 +lon_0=3 +x_0=700000 +y_0=6600000 +ellps=GRS80 +towgs84=0,0,0,-0,-0,-0,0 +units=m +no_defs
Chaine lambert93
+proj=lcc +lat_1=49 +lat_2=44 +lat_0=46.5 +lon_0=3 +x_0=700000 +y_0=6600000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Bizarrement la différence est sur le towgs84 qui contient des -0 ou -0.0 !!!!

Alain

Yves · Fri 26 August 2011 11:31

Bonjour,

Peux tu m'envoyer un exemple de fichier j'essayerai de reproduire et de faire remonter le ticket à qui de droit (gdal/proj/QGIS). Est ce que je pourrai mettre ces fichiers dans le ticket ? Par contre ca ne sera pas avant lundi soir, sauf s'il fait mauvais dans le sud

Merci,

Y.

Ferraton · Fri 26 August 2011 12:40

Bonjour Yves,

je te fais passer dans le ZIP joint les fichiers
MaTAble en Lambert 93 issu de MapInfo
MATAble_EPSG2154 issu de la sauvegarde avec QGIS de la 1ère table préalablement chargée sous QGIS.

Ces tables peuvent être communiquées....

merci
Alain

Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

Yves · Sat 27 August 2011 15:39

Bonjour,

Je reproduit le problème directement avec ogr2ogr, par contre ce problème touche seulement les fichiers mapinfo, je n'ai pas pu le reproduire avec un export en shapefile (avec QGIS).

Je vais remonter le problème à la liste gdal pour voir si le soucis ne vient pas de proj et s'il peut être corrigé.

Y.

Ferraton · Mon 29 August 2011 09:39

Bonjour,

sur http://www.epsg-registry.org/ pourle code 2154 on a comme
commentaire sur 'latitude of 1st standard parrallel'

'...It is normally but not necessarily that nearest to the pole'

pour EPSG c'est donc le parallèle le plus proche du pole alors que pour
l'IGN c'est le contraire (cf définition dans IGNF:LAMB93). C'est
probablement une source de confusion...

Les problèmes qui sont effectivement rencontrés uniquement avec les
fichiers MapInfo proviennent peut-être in fine de la bibliothèque MITAB
http://mitab.maptools.org/
C'est une hypothèse qu'il faudrait vérifier...

Dans l'attente de tes retours de la liste gdal...

Cordialement
Alain

Yves · Tue 30 August 2011 09:00

Bonjour,

J'ai eu une réponse d'Even Roualt qui passe sur le forum parfois

Il m'a retrouvé un ticket que j'ai rempli pour un autre utilisateur de GeoRezo (http://trac.osgeo.org/gdal/ticket/3292 le lien vers le thread de GeoRezo y est inclus).

Je vais rajouter le fichier zip que tu m'as fournie. Le ticket est assigné à Daniel Morisette qui est le développeur de la bibliothèque Mitab.

À suivre.

Y.

Gérard LA · Wed 12 October 2011 15:15

J'ai le même soucis avec mes tables produites sous MI en L93. Elles sont affichées sous QGIS mais dans une mauvaise localisation.

J'ai cru comprendre que Rouault a emis un patch sur la fonction MITAB de la bibliotheque GDAL utilisée par QGis, savez vous combien de temps peux s'écouler entre l'émission d'un patch et son application, ensuite faut il attendre que QGis repercute la modif ou faut il mettre à jour OGR chez soi?

Merci

rouault · Wed 12 October 2011 19:53

Il peut s'écouler un temps infini, tant que le patch n'est pas intégré. Peut être qu'en ajoutant un petit commentaire dans le ticket suffira à le rappeler au bon souvenir de Daniel. Sinon il faudra probablement passer à la vitesse supérieure et lui offrir une bière au prochain FOSS4G ;-)

Dernière modification par rouault (Wed 12 October 2011 19:53)

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Sites amis	Agenda Biblio Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

Annonce

#1 Thu 25 August 2011 16:38

QGIS 1.x : Non reconnaissance des projections L93 export vers MapInfo

Code:

Code:

Code:

#2 Fri 26 August 2011 11:05

Re: QGIS 1.x : Non reconnaissance des projections L93 export vers MapInfo

Code:

#3 Fri 26 August 2011 11:31

Re: QGIS 1.x : Non reconnaissance des projections L93 export vers MapInfo

#4 Fri 26 August 2011 12:40

Re: QGIS 1.x : Non reconnaissance des projections L93 export vers MapInfo

#5 Sat 27 August 2011 15:39

Re: QGIS 1.x : Non reconnaissance des projections L93 export vers MapInfo

#6 Mon 29 August 2011 09:39

Re: QGIS 1.x : Non reconnaissance des projections L93 export vers MapInfo

#7 Tue 30 August 2011 09:00

Re: QGIS 1.x : Non reconnaissance des projections L93 export vers MapInfo

#8 Wed 12 October 2011 15:15

Re: QGIS 1.x : Non reconnaissance des projections L93 export vers MapInfo

#9 Wed 12 October 2011 19:53

Re: QGIS 1.x : Non reconnaissance des projections L93 export vers MapInfo

Pied de page des forums