Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#2422 closed task (fixed)

Wrong spatial reference name

Reported by: yanchen Owned by: warmerdam
Priority: high Milestone: 1.5.3
Component: GDAL_Raster Version: 1.5.1
Severity: normal Keywords: HFA morphToESRI
Cc: gaopeng

Description

The name of spatial reference is wrong. It shows as the projection name. The spatial reference of the attached IMAGINE should be: NAD_1983_StatePlane_Ohio_South_FIPS_3402_Feet

Instead, it shows: Lambert_Conformal_Conic

There could be a name conversion missing.

Attachments (6)

IMG1.rar (926.6 KB) - added by yanchen 11 years ago.
IMAGINE files for problem 1
prob1tif.rar (918.0 KB) - added by yanchen 11 years ago.
TIFF file for problem1
problem2.zip (187.0 KB) - added by yanchen 11 years ago.
onebitcopy.img, assign the spatial reference, and doesn't work
problem3.zip (818.9 KB) - added by yanchen 11 years ago.
data for problem3
problem7.zip (85.2 KB) - added by yanchen 11 years ago.
data for problem 7
problem4.zip (106.7 KB) - added by yanchen 11 years ago.
data for Problem4: IMAGINE and TIFF

Change History (21)

comment:1 Changed 11 years ago by yanchen

Component: defaultGDAL_Raster
  1. assign NAD_1927_StatePlane_Maryland_FIPS_1900 to the img file, the name is changed to NAD1927\Maryland
  1. the spatial reference of the img is read as Albers Conical Equal Area, it should be North_America_Albers_Equal_Area_Conic

4.the name of the spatial reference should be ESRI style, not " UTM Zone 11, Northern Hemisphere"

  1. read SR as Lambert Conformal Conic, should be North_America_Lambert_Conformal_Conic
  1. Lambert Azimuthal Equal-area, should be Lambert_Azimuthal_Equal_Area

Changed 11 years ago by yanchen

Attachment: IMG1.rar added

IMAGINE files for problem 1

comment:2 Changed 11 years ago by warmerdam

Keywords: HFA morphToESRI added; spatial reference name wrong removed
Status: newassigned

I'm not clear on what is going wrong. Is it the creation of the .img file using GDAL or the reading of the file? The file does not currently have any information which would allow GDAL to automatically recognise it is a state plane coordinate system short of comparing to all state plane coordinate systems.

If the problem is that this file was created with GDAL from some other file, and the state plane nature of the coordinate system was lost, then I will need the original file. Note, that I do have a copy of ArcMap?, ArcGIS, etc, and so I cannot try and follow steps involving those software packages. I need to be able to reproduce the problem with gdal_translate, or some other sort of code sample.

comment:3 Changed 11 years ago by yanchen

for Problem 1: This .img was created from a .tif.

But this .img is read correctly as state plane coordinate system in RDO (not using GDAL). RDO is the one replaced by GDAL for reading IMAGINE. That's the reason that I thought it is a reading error of GDAL. I will update with gdal_translate utilities if there is creation problems for others.

comment:4 Changed 11 years ago by yanchen

Cc: pgao@… removed

Here is the script for problem 1: gdal_translate -of HFA intogdb.tif intogrdbi.img

Changed 11 years ago by yanchen

Attachment: prob1tif.rar added

TIFF file for problem1

Changed 11 years ago by yanchen

Attachment: problem2.zip added

onebitcopy.img, assign the spatial reference, and doesn't work

Changed 11 years ago by yanchen

Attachment: problem3.zip added

data for problem3

comment:5 Changed 11 years ago by yanchen

Cc: pgao@… added
  1. failed to read Gauss projection for IMAGINE (hfadataset.cpp misses the handling for EPRJ_GAUSS_KRUGER). Data cr30744_v93.img is attached. (problem7.zip)

Changed 11 years ago by yanchen

Attachment: problem7.zip added

data for problem 7

Changed 11 years ago by yanchen

Attachment: problem4.zip added

data for Problem4: IMAGINE and TIFF

comment:6 Changed 11 years ago by warmerdam

Cc: gaopeng added; pgao@… removed
Resolution: wontfix
Status: assignedclosed

I have reviewed the .img, .img.aux.xml, .img.vat.dbf, and .img.xml files and I can't see anything here that identifies the dataset as being a particular state plane coordinate system. I'm left concluding that RDO must compare all the parameters to a big dictionary, and if they exactly match a dictionary definition it substitutes in the corresponding name.

I'm not sure how practical it is for me to do that, and for the purposes of most GDAL software there is no real value to doing so. Perhaps it would make sense to do such a lookup at a higher level in your own code?

I haven't looked at the other problems in this ticket closely. Several of them seem to be the same sort of thing - a failure to recognise that a particular set of projection parameters can be equated with a well known name. But it looks like item 6 may be something different. That is I get the impression it represents a mistake in the PROJECTION[] keyword as opposed to the PROJCS name. If so, please re-file it as a distinct ticket, and I'll dig into it more deeply.

I'm closing this as WONTFIX, but please don't hesitate to discuss it further with me.

comment:7 Changed 11 years ago by warmerdam

Priority: normalhigh
Resolution: wontfix
Status: closedreopened

Gao suggests:

""" I think one way to approach it is to try to preserve the projcs name in HFA when saving spatial reference. For example, there are two HFA objects, MapInfo?, and Pro (projection parameters). Both have a name. The mapinfo name can be the projcs name, and Pro name be the projection name if they don't have to be the same. If that break HFA rule, we could store the projcs name in its own HFA entry. """

Reopening to pursue from this angle.

comment:8 Changed 11 years ago by warmerdam

I have applied code changes to preserve the PROJCS[] is the sMapInfo.proName, and to try and use that preferentially as the PROJCS[] name when reading back from .img. Note, this only works currently for projected coordinate systems - not geographic coordinate systems, and it does not work for UTM which has special logic to set the PROJCS[] name.

I have applied the changes in trunk (r14755) and merged into 1.5 branch (r14757). I have also added a test in trunk (r14756+r14758).

I am holding off on closing this ticket to test if it also resolves some of the other issues in this ticket. Any testing would be appreciated as making core changes like this scares me a bit.

comment:9 Changed 11 years ago by warmerdam

Slight correction. The 1.5 branch change is actually r14758 (I failed to commit it the first pass).

comment:10 Changed 11 years ago by warmerdam

Problems 2 and 3 are likely the same class as problem 1, but without the original input files it is hard to tell if the fix works for them.

comment:11 Changed 11 years ago by yanchen

Problem2.zip, problem3.zip are the data.

comment:12 Changed 11 years ago by warmerdam

Problem 4 seems a bit different again. The input GeoTIFF file has a PROJCS[] formatted by GDAL looking like "UTM Zone 17, Northern Hemisphere". When written to .img and read back it is the same, though really only because this is the particular format the OGRSpatialReference::SetUTM() applies to the coordinate system name.

I'm guessing you would like to see something like "WGS_1984_UTM_Zone_59N", is that right? Is there a reason that the .img driver in particular ought to return coordinate system names formatted this way? Is this something we ought to try and incorporate into the OGRSpatialReference::morphToESRI() method (as opposed to addressing piecemeal in format drivers) ?

I think this is a distinct issue from the "preserve the source PROJCS name" issue addressed in this ticket. I would therefore suggest if we want to pursue this issue that we launch it into it's own ticket.

comment:13 Changed 11 years ago by warmerdam

Resolution: fixed
Status: reopenedclosed

Problem 7 is a distinct issue. Migrated to ticket #2439.

The other problems without test data seem similar to problem 1. So I'm closing this ticket as fixed, but please do some checking and reopen if there are still issues.

comment:14 Changed 11 years ago by yanchen

Problem 3 is different from Problem 1&2 which have been fixed. Problem 3 doesn't involves the "Saving to img", and it is simply the spatial reference string conversion.

the spatial reference of the problem3 is read as Albers Conical Equal Area, it should be North_America_Albers_Equal_Area_Conic. Seems all the parameters are already there, so in morphToESRI() method we need add "North_America_" in the front, changing empty space" " to underscore "_".

If you think this is a different issue, I can open a new ticket.

comment:15 Changed 11 years ago by yanchen

problem 3 and problem 4 are migrated to ticket #2441.

Note: See TracTickets for help on using tickets.