<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>GeoTIFF spec - ModelTransformTag is not invertible</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>
<BR>
<P><FONT FACE="Lucida Console">GeoTIFF'ers</FONT>
</P>
<P><FONT FACE="Lucida Console">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. </FONT></P>
<P><FONT FACE="Lucida Console">The example for 'baseline GeoTIFF' is:</FONT>
</P>
<P><FONT FACE="Lucida Console">==============================================</FONT>
</P>
<P><FONT SIZE=2 FACE="Courier New">For Baseline GeoTIFF, the model space is always 2-D, and so the matrix will have the more limited form: </FONT>
<BR><FONT SIZE=2 FACE="Courier New"> |- -| |- -| |- -|</FONT>
<BR><FONT SIZE=2 FACE="Courier New"> | X | | a b 0 d | | I |</FONT>
<BR><FONT SIZE=2 FACE="Courier New"> | | | | | |</FONT>
<BR><FONT SIZE=2 FACE="Courier New"> | Y | | e f 0 h | | J |</FONT>
<BR><FONT SIZE=2 FACE="Courier New"> | | = | | | |</FONT>
<BR><FONT SIZE=2 FACE="Courier New"> | Z | | 0 0 0 0 | | K |</FONT>
<BR><FONT SIZE=2 FACE="Courier New"> | | | | | |</FONT>
<BR><FONT SIZE=2 FACE="Courier New"> | 1 | | 0 0 0 1 | | 1 |</FONT>
<BR><FONT SIZE=2 FACE="Courier New"> |- -| |- -| |- -|</FONT>
<BR><FONT SIZE=2 FACE="Courier New">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.</FONT></P>
<P><FONT FACE="Lucida Console">==============================================</FONT>
</P>
<BR>
<P><FONT FACE="Lucida Console">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.</FONT></P>
<BR>
<P><FONT FACE="Lucida Console">Since the paragraph immediately below this example mentions matrix inversion, why does the example show a matrix that CANNOT be inverted ? </FONT></P>
<P><FONT FACE="Lucida Console">In my estimation, this is a typo and a '1' should be at the intersection of the third row and third column. </FONT>
</P>
<P><FONT FACE="Lucida Console">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. </FONT></P>
<BR>
<P><FONT FACE="Lucida Console">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. </FONT></P>
<BR>
<P><FONT FACE="Lucida Console">Any arguments why this should not be changed ?</FONT>
</P>
<P><FONT FACE="Lucida Console">What is the process for getting the spec changed or at least amended ?</FONT>
</P>
<P><FONT FACE="Lucida Console">Thanks for any info or discussion. </FONT>
</P>
<BR>
<P><FONT FACE="Lucida Console">-- </FONT>
<BR><FONT FACE="Lucida Console">ed grissom</FONT>
<BR><FONT FACE="Lucida Console">ed.grissom@intergraph.com</FONT>
</P>
</BODY>
</HTML>