[Geotiff] GeoTIFF spec - ModelTransformTag is not invertible

[Niles Ritter]

On Fri, 2007-02-02 at 10:02 -0600, Ed Grissom wrote:

> 
> GeoTIFF'ers
> 
> I have an issue with one small part of the spec, that I would like to
> get resolved.   This deals with the ModelTransformationTag and is in
> section 2.6 of the spec. 
> [ Non-invertible matrix ]

Pretty good timing, Ed; I usually scan the GeoTIFF list once 
every blue moon, and the moon just happened to be blue 
last night (with Saturn nearby).

Summary:
----------
GeoTIFF files which have a zero on the (3,3) coordinate in
the ModelTransformTag is perfectly valid GeoTIFF, even
though the matrix is not invertible. GeoTIFF readers 
should not crash on encountering this situation.

Details:
--------
There are several different kinds of model spaces, to which the
3D raster coordinates (I,J,K) can be transformed in GeoTIFF, which
include Geographic, Geocentric, and Projected. It should be noted
here (from section 2.6.1), that the K-value is the pixel value,
not a third independent axis (such you'd have in a voxel). 

In the spec is it noted that the Geographic and Projected model
spaces are intrinsically two-dimensional, and so the Z-value
of (X,Y,Z) is ill-defined, or at best zero. The reason is that
the Z coordinate would indicate a vertical spatial location, which
is probably unknown and not contained in the data.

In any case, since the raster data is always thought of 
as sitting embedded in 3-dimensional raster space, for 
Geographic and Project model spaces the inverse map from
(X,Y,Z) to (I,J,K) is not well defined. However, the inverse
map from flat (X,Y) to flat (I,J) space is well defined,
and in that sense an inverse makes sense.

If the model space is Geocentric, and the image is a digital
elevation (I,J,K) model, then the matrix is and must be invertible,
as we are realizing the image as a mesh of grid points in 3 
dimensional Geocentric space, and both K and Z have linear
units. Section 3.2.3 gives such an example.

(BTW, having a zero in the main diagonal does not imply that
 the matrix is non-invertible; a 90-degree rotation, for example,
 is a 2-d matrix with all zeroes on the main diagonal. In
 this case, however, a whole row is zero, which is singular).

All of that said, there is little harm in the Geographic and
Projected model spaces of changing that diagonal element to 1.
The risk however is that it implies something that is not actually
correct, which is that the model space coordinates have
some vertical (spatial) information that is somehow dependent
upon the value of the pixel.

--Niles.

> 
> The example for 'baseline GeoTIFF' is:
> 
> ==============================================
> 
> For Baseline GeoTIFF, the model space is always 2-D, and so the matrix
> will have the more limited form:  
>         |-   -|     |-                 -|  |-   -| 
>         |  X  |     |   a   b   0   d   |  |  I  | 
>         |     |     |                   |  |     | 
>         |  Y  |     |   e   f   0   h   |  |  J  | 
>         |     |  =  |                   |  |     | 
>         |  Z  |     |   0   0   0   0   |  |  K  | 
>         |     |     |                   |  |     | 
>         |  1  |     |   0   0   0   1   |  |  1  | 
>         |-   -|     |-                 -|  |-   -| 
> Values "d" and "h" will often be used to represent translations in X
> and Y, and so will not necessarily be zero. All 16 values should be
> specified, in all cases. Only the raster-to-model transformation is
> defined; if the inverse transformation is required it must be computed
> by the client, to the desired accuracy.
> 
> ==============================================
> 
> 
> Note that the main diagonal contains a zero at the intersection of the
> third row and the third column.   If I am not mistaken, a zero on the
> main diagonal means that the matrix is NOT invertible.   I've tested
> this with our matrix inversion code, and substituting a one for the
> zero gives a matrix that can be inverted.
> 
> 
> Since the paragraph immediately below this example mentions matrix
> inversion, why does the example show a matrix that CANNOT be
> inverted ? 
> 
> In my estimation, this is a typo and a '1' should be at the
> intersection of the third row and third column.  
> 
> However, the next section of the spec deals with how to translate a
> "point-n-scale" description to a matrix, and shows the Z-scale of the
> point-n-scale (which is typically zero for 2-D) as being inserted at
> this point in the matrix.   However, any value can be inserted here
> without changing any outcomes since the input "K" values for 2-D are
> all zero.  In other words, any value here gives the same results
> except when inverting, and then any non-zero value allows inversion
> where a zero will not. 
> 
> 
> Intergraph has been writing matrices with a 1 at this position for the
> ModelTransformTag for many years.  Recently, however, we came across a
> file from a customer which had a 0 there and it blew up our matrix
> inversion code. 
> 
> 
> Any arguments why this should not be changed ?
> 
> What is the process for getting the spec changed or at least amended ?
> 
> Thanks for any info or discussion. 
> 
> 
> --  
> ed grissom 
> ed.grissom at intergraph.com
> 
> _______________________________________________
> Geotiff mailing list
> Geotiff at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/geotiff