[Gdal-dev] RFC 4 - Geolocation Arrays

[Andrey Kiselev]

On Wed, Aug 02, 2006 at 10:39:16AM -0400, Frank Warmerdam wrote:
> I have prepared RFC4 in an effort to address adding geolocation array
> support to GDAL in a reasonably comprehensive manner.  Currently the
> RFC is still considered to be "under development", but I thought it
> wouldn't hurt to put it out there for feedback from the community.

Hi Frank,

Just two notes from my side.

1. The third coordinate should be added, i.e. Z_DATASET/Z_BAND metadata
records. Some products contain the third value (MODIS). Well, it is
possible to have more geolocation arrays in the HDF file, so it is worth
to add X_NAME/Y_NAME/Z_NAME field with a name of parameter
("Latitude"/"Longitude"/"Height"). With these names we need only one
step to add geolocation/data maps and completely mimic the HDF-EOS
structure :-)

2. It should be noted that both OFFSET and STEP parameters could be
negative in which case we have geolocation array larger than
corresponding data array. The following is a quote from the HDF-EOS
manual:

	"In many cases, the size of a geolocation dimension will be
	different from the size of the corresponding data dimension. To
	take care of such occurrences, there are two pieces of
	information that must be supplied when defining a dimension map:
	the offset and the increment.  The offset tells how far along a
	data dimension you must travel to find the first point to have a
	corresponding entry along the geolocation dimension. The
	increment tells how many points to travel along the data
	dimension before the next point is found for which there is a
	corresponding entry along the geolocation dimension. Figure 5-3
	depicts a dimension map.

	The "data skipping" method described above works quite well if
	there are fewer regularly spaced geolocation points than data
	points along a particular pair of mapped dimensions of a Swath.
	It is conceivable, however, that the reverse is true ­ that
	there are more regularly spaced geolocation points than data
	points. In that event, both the offset and increment should be
	expressed as negative values to indicate the reversed
	relationship. The result is shown in Figure 5-4. Note that in
	the reversed relationship, the offset and increment are applied
	to the geolocation dimension rather than the data dimension."

I haven't never seen such arrays "in wild", but everything is possible
in the HDF world. Also negative offset is a common thing in ASTER
products.

Translating geolocation arrays is an interesting task. The one approach
could be a "-geolocation <name>" option of gdal_translate. When this option
supplied, the all other options (-of,-ot,-scale,dst_dataset etc.) tells
how the input geolocation array should be saved. The question is: do we
need to support translating HDF-EOS datasets into the valid another
HDF-EOS with all geolocations properly transferred? If not, that simple
approach should work.

Best regards,
Andrey

PS.
I can take responsibility to add geolocation support to HDF4 and L1B
drivers.

-- 
Andrey V. Kiselev
ICQ# 26871517