Problem creating IMG Transverse Mercator files

[sam.gillingham@…]

They wind up being UTM files. Problem is in frmts/hfa/hfadataset.cpp line 1070,
oSRS.getUTMZone() succeeds for Transverse Mercator when it maybe should only for
UTM which are distinct in Imagine. Maybe this check should be last after the
string comparisons?

[warmerdam]

Sam,

Can you provide more details?  Is the Transverse Mercator coordinate
system you are trying to write to a .img file an exact match for a UTM
zone definition?  If so, it is inevitable that I cannot distinguish them
since OGC took the unfortunately approach of specifying UTM coordinate
systems just based on their underlying transverse mercator definitions. 

[sam.gillingham@…]

File Containing Correct Transverse Mercator Coordinate System

[sam.gillingham@…]

Hi Frank,

Yes, the coord system I am trying to use is an exact match for a UTM definition.
What we are trying to do is replace some ERDAS C toolkit programs with GDAL ones
(and be platform independent, yay!). As it stands, GDAL creates files which
match our existing files spatially, but the coordinate definition shown in
Imagine Image Info is different (UTM, rather than Transverse Mercator). I
suppose what I don't understand is that there is a test for "Transverse
Mercator" in the code which does the right thing, but it never gets run because
the test for a UTM zone succeeds. Obviously, I am a little out of my depth here,
so feel free to disregard anything I say. 

The WKT I am trying to use is "PROJCS["Transverse
Mercator",GEOGCS["GDA94",DATUM["GDA94",SPHEROID["GRS
1980",6378137,298.2572220960422],TOWGS84[-16.237,3.51,9.939,1.4157e-06,2.1477e-06,1.3429e-06,1.91e-07]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],UNIT["meters",1],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",153],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northingr",10000000]]"

As it stands GDAL will create a file that appears in Imagine as UTM (maybe this
is correct behaviour?).

Attached is an example output file with that info applied correctly (same file
as the other floating point bug). 

Let me know what you think, and thanks again for your time.

Sam.

[warmerdam]

Sam,

Generally speaking producing a file with a UTM definition that corresponds 
exactly to the Transverse Mercator coordinate system you have defined should
be harmless .. they are mathematically the same.  If you still feel a strong
need to be able to avoid this, let me know and I will add a special option 
just for you to avoid the UTM logic. 

The issue, as noted, is that in the OGC WKT world UTM is represented via its
underlying TM definition so I can't tell what was intended to be UTM except by 
it's parameters matching a UTM definition.

[sam.gillingham@…]

Frank,

After thinking about this, it is necessary for us to be able to produce files
that appear in Imagine as "Transverse Mercator" so as not to confuse our
existing processing. Obviously, we may be the only ones that ever come up
against this, so of course it is completely up to you but we would definitely
use an option were you to put it in. 

[warmerdam]

Sam,

I have committed changes adding support for the IGNOREUTM creation option 
when using the Create() or CreateCopy() methods for Imagine files. 

eg. 

gdal_translate -of HFA -co IGNOREUTM=YES utm.tif tm.img

You should be able to grab the CVS snapshot after the CVS snapshot rebuilt
in the early morning hours (early morning eastern time).  If you aren't in a
big hurry you could pick up the CVS snapshot on Monday. 

I don't intend to document this option since I don't see it as being of
broad interest but hopefully it will survive in the software pretty much
indefinately.