Wrong spatial reference name

[yanchen]

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.

[yanchen]

2. assign NAD_1927_StatePlane_Maryland_FIPS_1900 to the img file, the name is changed to NAD1927\Maryland

3. 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"

5. read SR as Lambert Conformal Conic, should be North_America_Lambert_Conformal_Conic

6. Lambert Azimuthal Equal-area, should be Lambert_Azimuthal_Equal_Area

[yanchen]

IMAGINE files for problem 1

[warmerdam]

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.

[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.

[yanchen]

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

[yanchen]

TIFF file for problem1

[yanchen]

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

[yanchen]

data for problem3

[yanchen]

7. failed to read Gauss projection for IMAGINE (hfadataset.cpp misses the handling for EPRJ_GAUSS_KRUGER). Data cr30744_v93.img is attached. (problem7.zip)

[yanchen]

data for problem 7

[yanchen]

data for Problem4: IMAGINE and TIFF

[warmerdam]

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.

[warmerdam]

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.

[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.

[warmerdam]

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

[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.

[yanchen]

Problem2.zip, problem3.zip are the data.

[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.

[warmerdam]

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.

[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.

[yanchen]

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