Opened 16 years ago

Closed 16 years ago

Last modified 16 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 16 years ago.
IMAGINE files for problem 1
prob1tif.rar (918.0 KB ) - added by yanchen 16 years ago.
TIFF file for problem1
problem2.zip (187.0 KB ) - added by yanchen 16 years ago.
onebitcopy.img, assign the spatial reference, and doesn't work
problem3.zip (818.9 KB ) - added by yanchen 16 years ago.
data for problem3
problem7.zip (85.2 KB ) - added by yanchen 16 years ago.
data for problem 7
problem4.zip (106.7 KB ) - added by yanchen 16 years ago.
data for Problem4: IMAGINE and TIFF

Change History (21)

comment:1 by yanchen, 16 years ago

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

by yanchen, 16 years ago

Attachment: IMG1.rar added

IMAGINE files for problem 1

comment:2 by warmerdam, 16 years ago

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 by yanchen, 16 years ago

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 by yanchen, 16 years ago

Cc: pgao@… removed

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

by yanchen, 16 years ago

Attachment: prob1tif.rar added

TIFF file for problem1

by yanchen, 16 years ago

Attachment: problem2.zip added

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

by yanchen, 16 years ago

Attachment: problem3.zip added

data for problem3

comment:5 by yanchen, 16 years ago

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)

by yanchen, 16 years ago

Attachment: problem7.zip added

data for problem 7

by yanchen, 16 years ago

Attachment: problem4.zip added

data for Problem4: IMAGINE and TIFF

comment:6 by warmerdam, 16 years ago

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 by warmerdam, 16 years ago

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 by warmerdam, 16 years ago

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 by warmerdam, 16 years ago

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

comment:10 by warmerdam, 16 years ago

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 by yanchen, 16 years ago

Problem2.zip, problem3.zip are the data.

comment:12 by warmerdam, 16 years ago

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 by warmerdam, 16 years ago

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 by yanchen, 16 years ago

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 by yanchen, 16 years ago

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

Note: See TracTickets for help on using tickets.