[gdal-dev] Affine parameters in the gdal datamodel doc

[Rahkonen Jukka (MML)]

Even Rouault wrote:

>> Hi,
>> 
>> I am trying to understand the geotransform parameters by reading 
>> http://www.gdal.org/gdal_datamodel.html but I am confused. In the 
>> Affine GeoTransform section there are formulas
>> 
>>     Xgeo = GT(0) + Xpixel*GT(1) + Yline*GT(2)
>>     Ygeo = GT(3) + Xpixel*GT(4) + Yline*GT(5)
>> 
>> The latter formula feels odd to me and I think that it should rather 
>> be
>> 
>>     Xgeo = GT(0) + Xpixel*GT(1) + Yline*GT(2)
>>     Ygeo = GT(3) + Ypixel*GT(5) + Xline*GT(4)

> Jukka,

> That would look more odd to me ;-) since it would seem to add 2 new variables to the equations (but perhaps that was just a typo, and you wanted only to switch the 2 terms of the addition ?) In the original equation, my guess is that Xpixel means "X or pixel or column" 
and Yline means "Y or line or row", according to the terminology people use.

> The equations are just the result of the standard matrix multiplication for a 2D affine transformation : 

> [   1     ]          [   1           0         0       ]       [    1      ]
> [  Xgeo ]   =    [   GT(0)   GT(1)   GT(2) ]  *    [ Xpixel  ]
> [  Ygeo ]          [   GT(3)   GT(4)   GT(5) ]  *    [ Yline    ]

> (usually you put the 1 at the bottom and right of the matrices, but that's only a presentation change)

Ok, it was just a combination of lazy reading and lazy thinking from my side:

- For some reason I was unconsciously thinking that if "Xpixel" means the location of a pixel in left to right direction then there should be another parameter "Ypixel" for defining the location in top to bottom direction. However, this parameter is called as "Yline".
- Because I did not understand the meaning of "Yline"  I did not bother to think about it at all.
- As the formula for calculating X coordinate has an order
 (initial x) + (pixel size(x) * pixel count x) + (correction term of x because of rotation) my brain believed that the formula for Y should follow the same order. Actually it is using another order which keeps the parameter index numbers nicely in order 0, 1, 2, 3, 4, 5
(initial y) +  (correction term of y because of rotation) + (pixel size(y) * pixel count y)

I am not sure if there is anything to learn about this. Programmers may think a bit differently than end users about what is logical but I was lurking the developers document even I am just a user so I can only accuse myself.

-Jukka Rahkonen-