[Gdal-dev] RFC 4 - Geolocation Arrays

Andrey Kiselev dron at ak4719.spb.edu
Wed Aug 2 14:43:35 EDT 2006


On Wed, Aug 02, 2006 at 01:58:12PM -0400, Frank Warmerdam wrote:
> >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:
...
> I am not clear why negative values need to express something special.
> I have been working with the assumption that the offset could be
> negative if the geolocation information extends beyond the data it is
> geolocating, and that the offset and step could be floating point
> values.  So for instance, if we have denser geolocation information
> than the data itself the step would be between 0.0 and 1.0.

Yes, we can achieve the same goal with floating point values. But I will
recommend to avoid serialization of floating point values in ASCII when
it is possible. Do you remember that i18n problem with dot/comma
delimiter in floating point values? It can be solved with CPLatof()
(BTW, there isn't CPLsnprintf() implementation yet), but it is better to
avoid problem at all than try to catch it.

> It seems to me that the "negative option" in HDF EOS can be translated
> back into "forward facing" offset/step values without too much work if
> we encounter it.  I'd rather not incorporate this unnecessary
> complexity (of a negative option) into the gdal data model if
> possible.

The only reason in this complication is to avoid floating point. It is
discussible what approach has worse side effects.

> >I can take responsibility to add geolocation support to HDF4 and L1B
> >drivers.
> 
> I've addressed this for the HDF4's drivers EOS_SWATH handler already
> (and now this change is committed).  I introduced a new "subtype"
> called EOS_SWATH_GEOL which provides "raw" access to swath fields without
> all the metadata, gcps and so forth.  So the "GEOLOCATION" metadata for
> a dataset can look like this:

Great! I will take a look at the code tomorrow.

> I would also love to have it in the L1B driver.   I was thinking of
> taking a crack at it, but I'd be most comfortable if you could do it.

Ok.

Regards,
Andrey

-- 
Andrey V. Kiselev
ICQ# 26871517



More information about the Gdal-dev mailing list