User defined datum: Transformation parameters

[Christian Zietz]

Hi,

as far as I know there exists no official way to store transformation
parameters (e.g. for a 7-parameter Helmert transformation) for a user
defined datum in a GeoTIFF.

So, before I go ahead and implement a solution using a private key ID:
Did someone do this before? Is there an unofficial specification I can
adhere to?

Christian




_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Bruce Raup-2]

Christian and others,

I haven't worked on this, but a closely related issue is that GeoTIFF
doesn't not seem to be able to separate the concepts of datum (used to
define longitude and latitude) and projection ellipsoid (used to map from
lon/lat to projected coordinates).

Petabytes of satellite image are stored in NASA archives where the
underlying lon/lat coordinates are based on the WGS-84 datum, but where
the projection ellipsoid is something else, such as a sphere.

The problem with only being able to store parameters for one ellipsoid is
that software can erroneously "decide" that it needs to do datum
conversion on unprojected lon/lat coordinates when display lon/lat or when
reprojecting, because it thinks that the lon/lat coordinates are defined
on the spheroid rather than WGS-84.

I'm wondering how well known this problem is, and whether there are plans
to augment the GeoTIFF spec to store the datum and projection ellipsoid
separately.  Or if I'm wrong about this gap in the spec, I would love to
be shown that as well.

Best regards,
Bruce

On 2008-02-23 20:28 +0100,  Christian Zietz wrote:

> Hi,
>
> as far as I know there exists no official way to store transformation
> parameters (e.g. for a 7-parameter Helmert transformation) for a user
> defined datum in a GeoTIFF.
>
> So, before I go ahead and implement a solution using a private key ID:
> Did someone do this before? Is there an unofficial specification I can
> adhere to?
>
> Christian
>
>
>
>
> _______________________________________________
> Geotiff mailing list
> Geotiff@...
> http://lists.maptools.org/mailman/listinfo/geotiff
>

--
Bruce H. RAUP
National Snow and Ice Data Center
University of Colorado
449 UCB,  Boulder, CO 80309
Phone:  [phone]
http://cires.colorado.edu/~braup/
_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Bruce Raup-2]

On 2008-02-23 13:01 -0700,  Bruce Raup wrote:

> I haven't worked on this, but a closely related issue is that GeoTIFF
> doesn't not seem to be able to separate the concepts of datum (used to

doesn't not = does not

--
Bruce H. RAUP
National Snow and Ice Data Center
University of Colorado
449 UCB,  Boulder, CO 80309
Phone:  [phone]
http://cires.colorado.edu/~braup/
_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Frank Warmerdam]

Christian Zietz wrote:
> Hi,
>
> as far as I know there exists no official way to store transformation
> parameters (e.g. for a 7-parameter Helmert transformation) for a user
> defined datum in a GeoTIFF.
>
> So, before I go ahead and implement a solution using a private key ID:
> Did someone do this before? Is there an unofficial specification I can
> adhere to?

Christian,

I am not aware of any way to store preferred datum shifting parameters
in GeoTIFFs in a standardized way.  If you prepare one, it might be
worth considering writing it up and offering it as an extension.

In theory it should be possible to pick a geotag # for it, and store it
within the geotiff info though I'm not aware of any other multi-value
floating point values handled as geokeys.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Frank Warmerdam]

Bruce Raup wrote:

> Christian and others,
>
> I haven't worked on this, but a closely related issue is that GeoTIFF
> doesn't not seem to be able to separate the concepts of datum (used to
> define longitude and latitude) and projection ellipsoid (used to map from
> lon/lat to projected coordinates).
>
> Petabytes of satellite image are stored in NASA archives where the
> underlying lon/lat coordinates are based on the WGS-84 datum, but where
> the projection ellipsoid is something else, such as a sphere.
>
> The problem with only being able to store parameters for one ellipsoid is
> that software can erroneously "decide" that it needs to do datum
> conversion on unprojected lon/lat coordinates when display lon/lat or when
> reprojecting, because it thinks that the lon/lat coordinates are defined
> on the spheroid rather than WGS-84.
>
> I'm wondering how well known this problem is, and whether there are plans
> to augment the GeoTIFF spec to store the datum and projection ellipsoid
> separately.  Or if I'm wrong about this gap in the spec, I would love to
> be shown that as well.

Bruce,

I'm quite painfully familiar with this issue. When expressing such data
in a system that supports recording datum shift information I normally
express the ellipsoid as a sphere, make up a bogus datum identity (user
defined in geotiff terminology) and attach a preferred TOWGS84 shift
transformation of 0,0,0.

This is basically defining the coordinate system as the projection on the
sphere, but claiming the datum on that should be treated as WGS84.

If we did have a way of encoding a preferred shift to WGS84 we would be
able to do this quite easily in GeoTIFF.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Christian Zietz]

Frank Warmerdam schrieb:

> In theory it should be possible to pick a geotag # for it, and store it
> within the geotiff info though I'm not aware of any other multi-value
> floating point values handled as geokeys.

And that's exactly where I'm having problems right now. Whenever I try
to store multiple double values, an access violation occurs somewhere
inside GTIFKeySet. I didn't have the time to investigate it, yet, but it
looks like something with the va_arg handling is going wrong.

Christian
--
Christian Zietz  -  CHZ-Soft  -  czietz@...
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Christian Zietz]

Christian Zietz schrieb:

> And that's exactly where I'm having problems right now. Whenever I try
> to store multiple double values, an access violation occurs somewhere
> inside GTIFKeySet.

And a follow-up question/remark: Is it correct that multiple doubles
have to be passed as an array? When I do something like

double d[7];
d[0] = 1; d[1] = 2; d[2] = 3; d[3] = 4;
d[4] = 5; d[5] = 6; d[6] = 7.1;
GTIFKeySet(gtif, MY_KEY, TYPE_DOUBLE, 7, d);

everything works as expected. No access violation and listgeo confirms
that the key is correctly set.

Christian
--
Christian Zietz  -  CHZ-Soft  -  czietz@...
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[noel khan]

Christian,

    DISCLAIMER: My perpective if the only the GeoTiff spec. I am not familiar with the library you are using, which contains the call "GTIFKeySet."


    Please refer to the GeoTif specsection 2.4.


    From my understanding, GeoTiff keys can either

    [1] store a single SHORT value within the KeyEntry

xor

    [2] store values in a TIFF-tag, which means that both [a] the TiffTagLocation must be set to a nonzero value and [b] the Value_Offset must be set to the location of the TIFF-tag containing your value(s).


Therefore, it appears that your implementation should involve:

[1] Storing your array of doubles within a TIFF tag that can accomodate those values. NOTE: Upon storage, I presume you necessarily know the base-0 position of that array within the TIFF file (hereinafter "*ptrToTiffTagContainingDoubleValues").

[2] Set your GeoTiff KeyEntry {KeyID, TiffTagLocation, Count,Value_Offset} = {<CustomTransformationKeyID>, 34736, 7, *ptrToTiffTagContainingDoubleValues}.

NOTE: The spec has that "all key-values that are not of type SHORT are to be stored in one of the following two tags, based on their format: ..." GeoDoubleParamsTag (34736) or GeoAsciiParamsTag (34737).

Finally, regarding "Is it correct that multiple doubles have to be passed as an array" -- this is my understanding.

Best Regards,
Noel

Christian Zietz wrote:

Christian Zietz schrieb:

> And that's exactly where I'm having problems right now. Whenever I try
> to store multiple double values, an access violation occurs somewhere
> inside GTIFKeySet.

And a follow-up question/remark: Is it correct that multiple doubles
have to be passed as an array? When I do something like

double d[7];
d[0] = 1; d[1] = 2; d[2] = 3; d[3] = 4;
d[4] = 5; d[5] = 6; d[6] = 7.1;
GTIFKeySet(gtif, MY_KEY, TYPE_DOUBLE, 7, d);

everything works as expected. No access violation and listgeo confirms
that the key is correctly set.

Christian
--
Christian Zietz  -  CHZ-Soft  -  [e-mail]
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
_______________________________________________
Geotiff mailing list
[e-mail]
http://lists.maptools.org/mailman/listinfo/geotiff

[Christian Zietz]

noel khan schrieb:

>     DISCLAIMER: My perpective if the only the GeoTiff spec. I am not
> familiar with the library you are using, which contains the call
> "GTIFKeySet."

Sorry, I forgot to mention it. I'm using libgeotiff. I know that the
values are to be stored in the GeoTIFF file itself just as you described it.

My question was and still is about the correct way to use libgeotiff to
store such values. Its documentation doesn't give specific details about
the way to store multiple values.

Christian
--
Christian Zietz  -  CHZ-Soft  -  czietz@...
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Frank Warmerdam]

Christian Zietz wrote:

> Christian Zietz schrieb:
>
>> And that's exactly where I'm having problems right now. Whenever I try
>> to store multiple double values, an access violation occurs somewhere
>> inside GTIFKeySet.
>
> And a follow-up question/remark: Is it correct that multiple doubles
> have to be passed as an array? When I do something like
>
> double d[7];
> d[0] = 1; d[1] = 2; d[2] = 3; d[3] = 4;
> d[4] = 5; d[5] = 6; d[6] = 7.1;
> GTIFKeySet(gtif, MY_KEY, TYPE_DOUBLE, 7, d);
>
> everything works as expected. No access violation and listgeo confirms
> that the key is correctly set.

Christian,

Yes, this is the correct way to pass a list of values.  I see the documentation
does not address the difference for passing single vs. multiple values.
Unfortunately this makes it awkward to pass an array that just happens to
have only one value.  Grr.

I'll update the docs a bit to reflect this.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Christian Zietz]

Below is what I implemented now. I wrote some documentation so that
other people facing the same problem can use this solution. The key ID
was chosen at random but since there is no registry for geokeys I can't
guarantee that it is not in use elsewhere.

GeogToWGS84GeoKey

KeyID = 35459
Type = 7 * DOUBLE
Values = dX, dY, dZ, Rx, Ry, Rz, dS

This key allows the specification of a position vector 7 parameter
transformation (as defined by EPSG:9606) between the coordinate
reference system of the file and the WGS84 system. dX, dY and dZ define
the translation vector and are given in meters. Rx, Ry and Rz define the
rotation in seconds of an arc. dS is the scale correction expressed in
parts per million.

Note that there exists another 7 parameter transformation (the
coordinate frame rotation, EPSG:9607) which differs from the method used
here only in the signs of the rotation parameters Rx, Ry, Rz.

Also the more simple 3 parameter transformation (geocentric translation,
EPSG:9603) can be expressed with this geokey by simply setting Rx, Ry,
Rz and dS to zero.

------

Cookbook for expressing a user defined datum:

Step 1: Set the GeogGeodeticDatumGeoKey to KvUserDefined (32767).

Step 2: Set the GeogEllipsoidGeoKey either to a well known ellipsoid
        code or to KvUserDefined (32767). In the latter case define the
        ellipsoid by setting GeogSemiMajorAxisGeoKey and either
        GeogSemiMinorAxisGeoKey or GeogInvFlatteningGeoKey.

Step 3: Define the transformation parameters between your coordinate
        system and WGS84 by setting GeogToWGS84GeoKey.

Step 4: Give a textual description of the datum in GeogCitationGeoKey.

------

Note for libgeotiff users:

The GTIFKeySet function expects a pointer to an array containg the 7
parameters as last argument, not the 7 parameters itself. Correct syntax
to set GeogCitationGeoKey:

double data[7];
// set the parameters, dX is data[0], dS is data[6]
GTIFKeySet(gtif, 35459, TYPE_DOUBLE, 7, data);

------

Revision 0.1 - Christian Zietz - czietz(at)gmx.net
--
Christian Zietz  -  CHZ-Soft  -  czietz(at)gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Frank Warmerdam]

Christian Zietz wrote:

> Below is what I implemented now. I wrote some documentation so that
> other people facing the same problem can use this solution. The key ID
> was chosen at random but since there is no registry for geokeys I can't
> guarantee that it is not in use elsewhere.
>
> GeogToWGS84GeoKey
>
> KeyID = 35459
> Type = 7 * DOUBLE
> Values = dX, dY, dZ, Rx, Ry, Rz, dS
>
> This key allows the specification of a position vector 7 parameter
> transformation (as defined by EPSG:9606) between the coordinate
> reference system of the file and the WGS84 system. dX, dY and dZ define
> the translation vector and are given in meters. Rx, Ry and Rz define the
> rotation in seconds of an arc. dS is the scale correction expressed in
> parts per million.
>
> Note that there exists another 7 parameter transformation (the
> coordinate frame rotation, EPSG:9607) which differs from the method used
> here only in the signs of the rotation parameters Rx, Ry, Rz.
>
> Also the more simple 3 parameter transformation (geocentric translation,
> EPSG:9603) can be expressed with this geokey by simply setting Rx, Ry,
> Rz and dS to zero.

Christian,

Would you consider switching to using 2062 for GeogToWGS84GeoKey?  This
puts it in the "geographic sc parameter keys" range.  I'm also leery about
using a 2^7 value for a geokey.

With that minor adjustment I'd be happy to post this as a technical note
on the geotiff web site, and also incorporate it in GDAL as well as add
support in the "normalize" machinery in libgeotiff for it.

It would be convenient if you could also supply a small sample file
demonstrating the new geokey.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Christian Zietz]

Frank,

> Would you consider switching to using 2062 for GeogToWGS84GeoKey?  This
> puts it in the "geographic sc parameter keys" range.

Sure, that's not a problem since neither the software nor any of the
data files using the new key has left my computer until now.

So, now it is

GeogToWGS84GeoKey

KeyID = 2062
Type = 7 * DOUBLE
Values = dX, dY, dZ, Rx, Ry, Rz, dS

> With that minor adjustment I'd be happy to post this as a technical note
> on the geotiff web site, and also incorporate it in GDAL as well as add
> support in the "normalize" machinery in libgeotiff for it.

That would be great. Thanks!

> It would be convenient if you could also supply a small sample file
> demonstrating the new geokey.

I'll see what I can do. I can't release the files I'm using here into
the public but I'll try to get some public domain data  (or make
something up).

Christian
--
Christian Zietz  -  CHZ-Soft  -  czietz@...
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Christian Zietz]

Frank Warmerdam schrieb:

> It would be convenient if you could also supply a small sample file
> demonstrating the new geokey.

OK, here is a sample file for GeogToWGS84GeoKey placed into the public
domain: <http://www.chzsoft.com.ar/storage/GeogToWGS84GeoKey5.zip>

Note however, that the file won't stay at that URL indefinitely.

BTW: Can it be that the calculation of the corner coordinates by listgeo
is wrong for RasterPixelIsPoint files? I switched to RasterPixelIsArea
for my test file to avoid any ambiguities.

Christian
--
Christian Zietz  -  CHZ-Soft  -  czietz@...
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Pierre Soille]

Hello Christian,

Christian Zietz wrote:

> Frank Warmerdam schrieb:
>
>  
>> It would be convenient if you could also supply a small sample file
>> demonstrating the new geokey.
>>    
>
> OK, here is a sample file for GeogToWGS84GeoKey placed into the public
> domain: <http://www.chzsoft.com.ar/storage/GeogToWGS84GeoKey5.zip>
>
> Note however, that the file won't stay at that URL indefinitely.
>
> BTW: Can it be that the calculation of the corner coordinates by listgeo
> is wrong for RasterPixelIsPoint files? I switched to RasterPixelIsArea
> for my test file to avoid any ambiguities.
>
>  

I also believe that the corner coordinates generated by listgeo
are wrong for RasterPixelIsPoint.  This issue is still pending,
see the previous threads (with a tentative patch in the second):

http://lists.maptools.org/pipermail/geotiff/2006-January/000212.html
http://lists.maptools.org/pipermail/geotiff/2006-January/000213.html

I submitted the error report along with my patch to

http://bugzilla.remotesensing.org/enter_bug.cgi?product=libgeotiff

but the link/ http://bugzilla.remotesensing.org/show_bug.cgi?id=1040/ does not seem
to be active anymore.

See also comments on this issue by Frank in
http://lists.maptools.org/pipermail/geotiff/2006-March/000259.html


Regards,

Pierre



_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Frank Warmerdam]

Pierre Soille wrote:

> I also believe that the corner coordinates generated by listgeo
> are wrong for RasterPixelIsPoint.  This issue is still pending,
> see the previous threads (with a tentative patch in the second):
>
> http://lists.maptools.org/pipermail/geotiff/2006-January/000212.html
> http://lists.maptools.org/pipermail/geotiff/2006-January/000213.html
>
> I submitted the error report along with my patch to
>
> http://bugzilla.remotesensing.org/enter_bug.cgi?product=libgeotiff
>
> but the link/ http://bugzilla.remotesensing.org/show_bug.cgi?id=1040/ 
> does not seem
> to be active anymore.
>
> See also comments on this issue by Frank in
> http://lists.maptools.org/pipermail/geotiff/2006-March/000259.html

Folks,

The bugzilla.remotesensing.org server is gone and I'm not sure if I will
be able to recover the bug database.  (this also affects PROJ.4 and libtiff).

On the pixel-is-point issue, we seem to lack a mechanism to resolve the
issue, and I find I'm still not keen on the proposed interpretation.
Lacking any sort of specification or library governance mechanism, my
disinclination to act means nothing changes.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Geotiff mailing list
Geotiff@...
http://lists.maptools.org/mailman/listinfo/geotiff

[Christian Zietz]

Frank Warmerdam schrieb:

> On the pixel-is-point issue, we seem to lack a mechanism to resolve the
> issue, and I find I'm still not keen on the proposed interpretation.

I'm not aware of what the proposed interpretation is nor do I know your
interpretation but the way I understand the GeoTIFF spec it should be as
follows:

Let's assume we've got a 3x3 pixel file. In the case of pixel-is-area
every pixel (n,m) with 0<n<3 and 0<m<3 represents the area with the
bounding box (n,m ; n+1,m+1), so the file fits into the raster
coordinate system like this:

  0   1   2   3
0 +---+---+---+
  |   |   |   |
1 +---+---+---+
  |   | &n