[GeoTIFF] Geotiff SOM projection

[geotiff-admin at remotesensing.org]

Hello All,

I won't pretend to tell Frank what to do about this, but will at least
provide a little reaction to the proposal.  Hopefully that will get some
discussion going.

As I understand, this involves adding a new projection type for a "generic"
form of the Space Oblique Mercator projection and new GeoKeys for these
additional parameters:

 Inclination of orbit ascending node
 Longitude of ascending orbit at equator
 Period of satellite revolution
 Satellite ratio
 End-of-path flag

The discusion a while back related these parameters to the GCTP package
(code found at USGS web site).  I've looked at some of the GCTP code and
code in my own system (code supporting Intergraph GIS and Photogrametry
applications, written over a decade ago by someone other than me).  My
initial observations are:

a) The GCTP code does not seem to actually pass in satellite ratio as a
parameter.  Although it is listed in the appendixA.txt posted earlier, the
code in for_init.c does not extract it from the parameter array.  Instead,
the code in somfor.c and sominv.c hard-codes it as the "LANDSAT_RATIO".  A
colleague of mine who was more involved with SOM some years ago produced a
binder in which there was a printout of an older Fortran version of the GCTP
code - that old version does seem to extract the ratio from the parameter
array.  Perhaps when they converted to C they realized the value never
changed, at least for their intended usage (Landsat-related?).  Anyway, the
Intergraph code does not have such a parameter as a requirement to define
SOM.  I think we can drop it, unless others see a need.

b) I do think that something like the end-of-path flag is necessary for some
cases.  My code doesn't have this flag, but it has another parameter we call
"orbit offset" that is used, in conjunction with an explicit designation of
northern or southern hemisphere to make the same adjustment that the GCTP
code uses the end-of-path flag to make.  I think that I can convert between
the GCTP parameter set and my own.

c) We may need some clarification on the intended definitions of the x and y
axes.  The GCTP code has a comment in somfor.c that says "Negate x & swap
x,y".  However, the code only swaps x and y, it does not negate x!
Intergraph's generic version of SOM did not alter the standard definitions
of x and y.  However, we have a version (similar to GCTP having SOM-B) that
presets parameters for the original 5 Landsat satellites.  This
Landsat-specific version does the x,y swap and we do actually negate the x
value.  I would be very interested to know what the end-user community
actually wants.  Apparently both the Intergraph code and the GCTP code have
been out there for about a decade with no complaints about the axes
definitions, despite the difference in whether or not x is negated.  I can't
explain this, but would welcome further discussion on what the GeoTIFF
definition of the axes should be.  How do other packages treat this?

Finally, my picky contributions to naming:

Projection code:
  CT_SpaceObliqueMercator  (I prefer this so that we wouldn't confuse SOM as
just another variation on Oblique Mercator.  I think we can drop the "A"
since by default most of these CT_xxx codes are generic.)

Parameter keys:
  ProjInclinationAscendingGeoKey  (type Double)
  ProjLongAscendingGeoKey  (type Double)
  ProjOrbitPeriodGeoKey  (type Double)
  ProjEndOfPathGeoKey  (type Short)


Best regards,
John Czachurski
Intergraph Corp.


-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com]
Sent: Sunday, April 04, 2004 11:49 AM
To: Norman Barker
Cc: geotiff at remotesensing.org
Subject: [GeoTIFF] Re: Geotiff SOM projection


Do you have any comments on the proposed SOM parameter set?  I have been
dragging my feet because it isn't like any SOM parameter set I had run into
before, though I understand it does have precident in ENVI.

Over the years, I have encountered lots of confusion converting between the
SOM definitions of different systems.  I don't want to make the situation
worse by adopting a SOM definition that conflicts, or is hard to translate
from other SOM definitions.

On the other hand, I feel quite bad about dragging my feet on this for so
long.  If I had some confidence that the approach proposed made sense and
could be supported reasonably by various product vendors I would be happy
to include it and issue a new libgeotiff with it included.

So, to the list as a whole ... feedback on the SOM proposal is welcome!
Tell
me what I should do.

Best regards,
-- 
---------------------------------------+------------------------------------
--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

----------------------------------------
Subscription and other info:
http://www.remotesensing.org/geotiff/geotiff.html