#3292 closed defect (fixed)
[PATCH] MITAB: some French EPSG code doesn't seems to be supported
Reported by: | yjacolin | Owned by: | Daniel Morissette |
---|---|---|---|
Priority: | normal | Milestone: | 2.3.0 |
Component: | OGR_SRS | Version: | unspecified |
Severity: | normal | Keywords: | srs, projection |
Cc: | yjacolin@…, mathieu.rajerison@…, Even Rouault, warmerdam |
Description
Here is an issue showed by a french user on GeoRezo Portail (http://georezo.net/forum/viewtopic.php?pid=155606)
Hello,
When transforming a MapInfo File from one coordinate Reference System to the following EPSG codes EPSG:27584, 27574, 27572, the result is a reprojected file with a false header. The header contains "nonearth" information. When transforming into RGF93 (EPSG:2154), the result is a header that contains WGS84 srs projection information.
The issue is about the header writing for these coordinate reference systems. These are the only ones that I've tested until now.
Best,
Mathieu
Attachments (2)
Change History (10)
comment:1 by , 14 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Summary: | Some French EPSG code doesn't seems to be supported → MITAB: some French EPSG code doesn't seems to be supported |
comment:2 by , 13 years ago
Hello,
I attach a zip file contening two mapinfo file, maTable.* is a sample dataset in Lambert 93 srs from Mapinfo and MATAble_EPSG2154 made by QGIS after opening the first dataset and save it to MapInfo file.
Hope it helps,
Y.
comment:3 by , 13 years ago
Cc: | added |
---|
The 'tabdump' program returns the following info from the header of the MaTable.MAP file in the attached ZIP:
m_sProj.nDatumId = 33 m_sProj.nProjId = 3 m_sProj.nEllipsoidId = 0 m_sProj.nUnitsId = 7 m_sProj.adProjParams = 3 46.5 44 49 700000 6.6e+06 m_sProj.dDatumShiftX = 0 m_sProj.dDatumShiftY = 0 m_sProj.dDatumShiftZ = 0 m_sProj.adDatumParams = 0 0 0 0 0
ProjId == 3 is already handled as LCC on read by calling OGRSpatialReference::SetLCC() in mitab_spatialref.cpp's TABFile::GetSpatialRef(). How can we tell OGR to treat the projection as LCC_1SP instead of LCC_2SP which seems to happen by default?
comment:4 by , 13 years ago
Summary: | MITAB: some French EPSG code doesn't seems to be supported → [PATCH] MITAB: some French EPSG code doesn't seems to be supported |
---|
I've attached a patch to address the GRS_80 vs GRS_1980 issue, map Reseau_Geodesique_Francais_1993 to GRS_80 (since apparently there's no difference in the file between the 2 datums), and avoid 0 to be turned into -0 in TOWGS84 . This doesn't solve the LCC_1SP vs LCC_2SP issue.
by , 13 years ago
Attachment: | ticket_3292_datum_issue_part.patch added |
---|
Patch to map Reseau_Geodesique_Francais_1993 to GRS_80, and avoid 0 to be turned into -0 in TOWGS84
comment:5 by , 13 years ago
I've removed the GRS_1980 alias. I must have messed up something in my test. It is likely unnecessary.
comment:8 by , 6 years ago
Milestone: | → 2.3.0 |
---|
Daniel,
A quick analysis shows that all those EPSG codes are based on the "Lambert_Conformal_Conic_1SP" projection method, whereas the MITAB code only seems to handle LCC_2SP
For EPSG:2154, the expansion of the code gives "Reseau_Geodesique_Francais_1993" for the datum name. This datum is not listed in the asDatumInfoList[] array, so it defaults to using WGS84.