Update of "Affine Transform"
Not logged in

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview

Artifact ID: bfddc3f6420380ebfbc1b1f2fd00b25dc1628a21
Page Name:Affine Transform
Date: 2015-05-02 23:40:35
Original User: sandro
Parent: d811cbd7e2e0c54842fdefebdb7fe9853c8b6f74 (diff)
Next 879eb3b9f32721f882553e148eb9e089d8bd9b0d
Content

back

Affine Transformations

Starting since version 4.3.0 SpatiaLite supports several new SQL functions based on affine transformations; understanding all the underlaying mathematics could easily be a rather difficult task, more notably if you have absolutely no familiarity with this kind of operations.
So we'll start smoothly by introducing first a very simple practical example based on kind of a joke about the geography of Italy and Sicily.

Fancy Geograpy and amusing Math

Preface

Looking to a map of Italy it appears obvious at first glance that Sicily is located in a very inconvenient position:
  1. Sicicly is placed too far South and too much close to North Africa; this implies an unpleasant torrid summer, and in turn this poses severe limitations to agricoltural activities.
  2. The Strait of Messina is exaggeratedly narrow, thus posing severe security risks to the navigation of capital ships and supertankers.
    Even worst, from time to time some crazy politician strongly advocates the very stupid idea to build an incredibly costly bridge crossing the Strait, completely overlooking the very high seismical risk of this district and purposely forgetting to remember that in 1908 both towns of Messina and Reggio Calabria were completely destroyed by an earthquake followed by a tsunami.
    More than 100,000 peoples lost their lives, and it was one of the most frightening natural disasters registered in Europe during modern times.
So we'll immediately start a case study intended to identify a possible alternative location for Sicily.
Incidentally we'll use the new SQL functions based on Affine Transformations for this task.
Let's go on.
wfs-1

Step #1: translating Sicily into a more convenient position

There is plenty of free room in the lower Tyrrhenian Sea, so we'll start by applying a translation: this practically means adding (or subctracting) a constant value to the coordinates on both x and y axes.
After a very quick examination moving Sicily 150 km (i.e. 150,000 m) westwards and 150 km northwards seems to be an absolutely reasonable choice.
So using the Affine Transformation SQL functions we'll write the following SQL statement:
CREATE TABLE sicilia_1 AS
SELECT cod_reg, 
   ATM_Transform(geometry,
      ATM_CreateTranslate(-150000, 150000)) AS geom
FROM sicilia_0;
SELECT RecoverGeometryColumn('sicilia_1', 'geom', 32632, 'MULTIPOLYGON', 'XY');
Remarks:
  • all affine transformation related SQL function names start with an ATM_ prefix: this simply stands for Affine Transformation Matrix.
  • ATM_Transform() is very similar to ST_Transform(); the most obvious difference is in that all transformation arguments are now expected to be passed under the form of an appropriate BLOB-serialized Affine Transformation Matrix.
  • ATM_CreateTranslate() simply is an SQL function returning a BLOB-serialized Affine Transformation Matrix.
    The BLOB-Matrix will be initialized so to represent a simple 2D Translate accordingly to (tx, ty) arguments.
    You could eventually define a complete 3D Translate by passing (tx, ty, tz) arguments, but this isn't strictly required in our current example.
wfs-1

Step #2: rotating Sicily so to get a nice horizontal alignement

Aligning the southern shores of Sicily to an almost horizontal line will surely lead to a more nicely ordered layout: so we have now to apply a counterclockwise rotation of about 25.0 degrees.
Thanks to Affine Transformations, we can combine both the previous translation and the current rotation into a single movement (a so called rototranslation).
We simply have to execute the following SQL statement:
CREATE TABLE sicilia_2 AS
SELECT cod_reg, 
   ATM_Transform(geometry,
      ATM_Translate(-150000, 150000,
         ATM_Translate(cx, cy,
            ATM_Rotate(25,
               ATM_CreateTranslate(-cx, -cy))))) AS geom
FROM (SELECT cod_reg, ST_X(centroid) AS cx, ST_Y(centroid) AS cy, geometry
      FROM (SELECT cod_reg, ST_Centroid(geometry) AS centroid, geometry 
            FROM sicilia_0) AS g1
) AS g2;
SELECT RecoverGeometryColumn('sicilia_2', 'geom', 32632, 'MULTIPOLYGON', 'XY');
Remarks:
  • correctly handling Rotation is rather complex. Any rotation will always imply a fixed center point, and by default this is exactly placed at the coordinates origin: (0, 0) (in the 2D case) or (0, 0, 0) (in the 3D case).
  • so a very naive attempt to directly invoke ATM_Rotate(25) will simply relocate Sicily in Southern Spain, and this absolutely isn't our intention.
  • what we really need is a more complex sequence of chained transformations:
    1. we'll start first by creating a new BLOB-Matix intended to relocate Sicily's centroid exactly on the coordinates origin: ATM_CreateTranslate(-cx, -cy)
    2. now we can safely chain the intended Rotation into the overall transformation stack: ATM_Rotate(25, atm-blob)
    3. after applying the Rotation we now have to relocate Sicily in its initial position: ATM_Translate(cx, cy, atm-blob)
    4. and finally we'll apply the Translation intended to reposition Sicily westwards and nothwards: ATM_Translate(-150000, 150000, atm-blob)
      we've used two separate translations simply for didactic clarity: we could easily merge both them into a single translation:
      ATM_Translate(cx - 150000, cy + 150000, atm-blob)
    5. this way ATM_Transform() will receive the final BLOB-Matrix resulting by chaining all the above transformation steps in the correct sequence.
  • Very important notice: Affine Transformations are not commutative: the relative order of subsequent operations in a complex transformation chain should always be very carefully considered.
  • all the FROM (SELECT ... FROM (SELECT ...) AS g1) AS g2 stuff simply is a rather trivial SQL trick based on two nested sub-queries.
    it's indented scope simply is avoiding to call too many times ST_Centroid(), ST_X() and ST_Y() in order to get the centroid coordinates.
wfs-1

Step #3: inflating and reshaping Sicily

An increased surface is surely welcome, because it automatically implies more agricultural lands: on the other hand shortening a little bit the length of the southern coastline will surely facilitate mobility and communications.
So we'll now apply a scaling transformation using two different values: sx=0.9 and sy=1.3.
Once again, Affine Transformations enable us to combine altogether both translate, rotate and scale into a single transformation.
This is the corresponding SQL statement:
CREATE TABLE sicilia_3 AS
SELECT cod_reg, 
   ATM_Transform(geometry,
      ATM_Translate(-150000, 150000,
         ATM_Translate(cx, cy,
            ATM_Scale(0.9, 1.3,
               ATM_Rotate(25,
                  ATM_CreateTranslate(-cx, -cy)))))) AS geom
FROM (SELECT cod_reg, ST_X(centroid) AS cx, ST_Y(centroid) AS cy, geometry
      FROM (SELECT cod_reg, ST_Centroid(geometry) AS centroid, geometry 
            FROM sicilia_0) AS g1
) AS g2;
SELECT RecoverGeometryColumn('sicilia_3', 'geom', 32632, 'MULTIPOLYGON', 'XY');
Remarks:
  • there is nothing really new in this: we'll simply chain yet another transformation in the appropriate sequence order.
  • ATM_Scale(sx, sy) is intended for the simpler 2D case.
  • in the more general 3D case you can invoke ATM_Scale(sx, sy, sz)
wfs-1

Step #4: final touch: reflecting Sicily

A reflected Sicily presents many interesting advantages: we'll examine all them in full detail in our study conclusions.
So we'll now apply a final <a href=http://en.wikipedia.org/wiki/Reflection_%28mathematics%29">reflection transformation; this simply corresponds to a 180 degrees rotation around the Y axis.
And the following is the final SQL statement applying all the above transformations in a single shot:
CREATE TABLE sicilia_2 AS
CREATE TABLE sicilia_4 AS
SELECT cod_reg, 
   ATM_Transform(geometry,
      ATM_Translate(-150000, 150000,
         ATM_Translate(cx, cy,
            ATM_YRoll(180,
               ATM_Scale(0.9, 1.3,
                  ATM_Rotate(25,
                     ATM_CreateTranslate(-cx, -cy))))))) AS geom
FROM (SELECT cod_reg, ST_X(centroid) AS cx, ST_Y(centroid) AS cy, geometry
      FROM (SELECT cod_reg, ST_Centroid(geometry) AS centroid, geometry 
            FROM sicilia_0) AS g1
) AS g2;
SELECT RecoverGeometryColumn('sicilia_4', 'geom', 32632, 'MULTIPOLYGON', 'XY');
Remarks:
  • there are several possible rotations supported by Affine Transformation:
    1. ATM_Rotate() always intends a 2D rotation, i.e. a rotation centered around the Z axis
    2. In the more general 3D case there are three possible rotations, one for each axis.
    3. the corresponding SQL functions are: ATM_XRoll(angle), ATM_YRoll(angle) and ATM_ZRoll(angle)
    4. Note: ATM_ZRoll() and ATM_Rotate() simply are two different alias-names for the same identical SQL function.
wfs-1

Final considerations

  1. Agriculture: after its relocation Sicily will gain much more agricultural land and will enjoy a more favourable climate: still sunny and warm but much less arid.
    This will certainly start a noticeable development of many economic activities, both direct and indirectly derived.
  2. Transportation systems: the suggested new layout for the Lower Tyrrhenian Sea strongly facilitates the development of maritime transports. Sicily could new become the central hub of a highly efficient network of high-speed and high-frequency ferry connections:
    • Palermo will now directly face Naples; Civitavecchia (Rome) seems to be a second obvious terminal for direct connections leading to Central Italy.
    • Messina will acquire a decisive strategic role, and will become the terminal for ferry connections leading to Civitavecchia, Leghorn and Genoa.
    • A less relevant (but anyway interesting) ferry link will join Trapani and Reggio Calabria.
    • Sardinia will strongly benefit from the new layout; Cagliari will be directly connected to Syracuse (or may be Augusta), and Olbia to Messina.
      This means definitely breaking the secular insulation of Sardinia, that will now start enjoying a stronger integration with all others regions of Southern Italy.
    • Last but not least: at a more strategic level it's absolutely obvious that now supertankers and big container ships can freely circumnavigate Sicily in any direction under uncompromised safety conditions.
      All Tyrrhenian harbors will now be directly conneted both to Eastern and Western Mediterranean, and this will surely induce a growth in the volumes of international traffics they could potentially attract.
  3. Heavy industry: the new transportation system strongly centered around maritime communications will surely induce an active rebirth of shipyards, a fluorishing traditional excellence of many southern regions in past times but nowadays a perishing and declining industrial branch.
  4. Tourism: the suggested new layout will certainly promote a strong development of international tourism.
    It's worth noting that the new layout will give birth to a wonderful island group extending between Sicily to Campania; several of these islands actually are active volcanoes, and this island chain will ideally join Mount Etna and Mount Vesuvius.
    This area could be considered the most impressive volcanic field of Europe and will certainly become a strong touristic attraction.
  5. Internal commerce: we can easily forecast a strong growth in volume of internal exchanges thank to the better connectivity based on maritime transports..
    Just a single example: Sardinia should now be able to export its finest sheep-cheese on the Calabrian markets whilst Calabria could freely export its renown red hot chilly peppers to Sardinia, and both regions will widely befit from increased exchange volumes.
  6. Practical realization: the present study clearly demonstrates that there are no Mathematics, Geometry or Geography adverse factors potentially forbidding the practical realization of the suggested idea.
    Unhappily the current state of the art in Geology poses many puzzling questions not yet fully resolved in a completely satisfying way.
    Anway we are hopefully expecting that future advancements in Tectonics (and more specifically a deeper comprehension of the micro-plaques mechanics) will surely allow to overcome any remaining issue.
wfs-1


Boring Math: a more formal presentation

Playtime's over: we'll now start a most serious exlanation.

An Affine Transformation can be represented in the form of a square matrix; the simpler 2D case requires a 3 x 3 matrix, and the followings are the possible arrangements corresponding to each elementary transformation:

General layout /abxoff\
|deyoff|
\001/

Identity /100\
|010|
\001/

Translate(tx, ty)    /10tx\
|01ty|
\001/

Scale(sx, sy) /sx00\
|0sy0|
\001/

Rotate(θ) /cos(θ)-sin(θ)0\
|sin(θ)cos(θ)0|
\001/

A 3D affine transformation requires a 4 x 4 matrix.
As you can easily notice there is direct relation beetween a 3D matrix and a 2D matrix; notice the cells showing a gray backgroud.

General layout    /abcxoff\
|defyoff|
|ghizoff|
\0001/

Identity /1000\
|0100|
\0010/
\0001/

Translate(tx, ty, tz)    /100tx\
|010ty|
|001tz|
\0001/

Scale(sx, sy, sz) /sx000\
|0sy00|
|00sz0|
\0001/

X Roll(θ) /1000\
|0cos(θ)-sin(θ)0|
|0sin(θ)cos(θ)0|
\0001/

Y Roll(θ) /cos(θ)0sin(θ)0\
|0100|
|-sin(θ)0cos(θ)0|
\0001/

Z Roll(θ) /cos(θ)-sin(θ)00\
|sin(θ)cos(θ)00|
|0010|
\0001/


applying an Affine Transformation

In order to materialize an affine transformation we simply have to compute (x', y', z') coordinates starting from (x, y, z) for every point or vertex found in the input Geometry accordingly to the following formulae:
in the simpler 2D case this will assume the reduced form:
As you can notice, applying an Affine Transformation does not requires computing any trigonometric function.
Trigonometric functions are very costly in computational terms, so applying an Affine Transformation is an intrinsically efficient mechanism because simply depends on multiplications and additions.


chaining two (or even more) Affine Transformations in a sigle operation

Affine transformation matrices have another amazing property.
We can multiply two different affine transformation matrices thus obtaining a third affine transformation matrix, and this latest once applied will contain both transformations and in the right sequence.
There is no limit; we can infinitively chain as many transformations as required, we'll simply have to continue multiplying all matrices one after the other carefully respecting the appropriate sequence.
At the end of the process we'll always get just a single affine transformation matrix faithfully representing any individual transformation in the chain.
The multiplication between two matrices is not a commutative operation: the relative order of operands is absolutely relevant.

multiplying two matrices

Multiplication is not really a simple operation when matrices are involved and requires a rather complex procedure; the following example shows how to multiply two 4 x 4 matrices.
/a11a12a13a14\
|a21a22a23a24|
|a31a32a33a34|
\a41a42a43a44/
*
/b11b12b13b14\
|b21b22b23b24|
|b31b32b33b34|
\b41b42b43b44/
=
/ (a11*b11 + a12*b21 + a13*b31 + a14*b41) (a11*b12 + a12*b22 + a13*b32 + a14*b42) (a11*b13 + a12*b23 + a13*b33 + a14*b43) (a11*b14 + a12*b24 + a13*b34 + a14*b44)\
| (a21*b11 + a22*b21 + a23*b31 + a24*b41) (a21*b12 + a22*b22 + a23*b32 + a24*b42) (a21*b13 + a22*b23 + a23*b33 + a24*b43) (a21*b14 + a22*b24 + a23*b34 + a24*b44)|
| (a31*b11 + a32*b21 + a33*b31 + a34*b41) (a31*b12 + a32*b22 + a33*b32 + a34*b42) (a31*b13 + a32*b23 + a33*b33 + a34*b43) (a31*b14 + a32*b24 + a33*b34 + a34*b44)|
\ (a41*b11 + a42*b21 + a43*b31 + a44*b41) (a41*b12 + a42*b22 + a43*b32 + a44*b42) (a41*b13 + a42*b23 + a43*b33 + a44*b43) (a41*b14 + a42*b24 + a43*b34 + a44*b44)/

identity matrix

An indentiy matrix simply corresponds to an affine transformation lacking any actual effect: at the end of the process the transformed geometry will be exactly the same as before.
Moreover an identity matrix plays a special role in multiplication: the resulting matrix will always be exactly the same of the other matrix.
(it's more or less the equivalent of multiplying e.g. 8*1=8 in an ordinary scalar multiplication).


Boring SQL functions: a formal explanation

SQL FunctionDescription
ATM_Transform ( BLOB Geometry , BLOB AT-matrix ) : BLOB GeometryWill return a new Geometry by applying an Affine Transformation to the input Geometry.
The output Geometry will preserve the original SRID, dimensions and type.
NULL will be returned on invalid arguments.
ATM_IsValid ( BLOB AT-matrix ) : BOOLEANWill check if a BLOB do really correspond to an encoded Affine Transformation Matrix then returning TRUE or FALSE.
-1 will be returned if the argument isn't of the BLOB type.
ATM_AsText ( BLOB AT-matrix ) : TEXTWill return a text serialized representation of the Matrix.
NULL will be returned on invalid arguments.
ATM_Multiply ( BLOB AT-matrix-A , BLOB AT-matrix-B ) : BLOB AT-matrixWill multiply Matrix-B by Matrix-A then returnign the resulting Matrix.
NULL will be returned on invalid arguments.
Note: the transformation defined by Matrix-A (left operand) will always happen after applying all transformations defined by Matrix-B (right operand).
SQL functions creating and initializing a new Affine Transformation Matrix
ATM_Create ( void ) : BLOB AT-matrixWill return an Identity Affine Transformation Matrix.
NULL if any error occurs.
ATM_Create ( double a , double b , double d , double e , double xoff , double yoff ) : BLOB AT-matrixWill return a 2D Affine Transformation Matrix initialized with explict values.
NULL if any error occurs or on invalid arguments.
ATM_Create ( double a , double b , double c , double d , double e , double f , double g , double h , double i , double xoff , double yoff , double double zoff ) : BLOB AT-matrixWill return a 3D Affine Transformation Matrix initialized with explict values.
NULL if any error occurs or on invalid arguments.
ATM_CreateTranslate ( double tx , double ty ) : BLOB AT-matrix
ATM_CreateTranslate ( double tx , double ty , double tz ) : BLOB AT-matrix
Will return an Affine Transformation Matrix initialized respectively as a 2D or 3D Translate.
NULL if any error occurs or on invalid arguments.
ATM_CreateScale ( double sx , double sy ) : BLOB AT-matrix
ATM_CreateScale ( double sx , double sy , double sz ) : BLOB AT-matrix
Will return an Affine Transformation Matrix initialized respectively as a 2D or 3D Scale.
NULL if any error occurs or on invalid arguments..
ATM_CreateRotate ( double angle ) : BLOB AT-matrix
ATM_CreateZRoll ( double angle ) : BLOB AT-matrix
Will return an Affine Transformation Matrix initialized as Rotation around the Z axis.
NULL if any error occurs or on invalid arguments.
The angle is always expected to be mesured in decimal degrees. The direction of rotation is defined such that positive angles rotate in the direction from the positive X axis toward the positive Y axis. With the default axis orientation positive angles rotate in a counterclockwise direction.
Note: this is the unique rotation allowed on a purely 2D plane.
ATM_CreateXRoll ( double angle ) : BLOB AT-matrixWill return an Affine Transformation Matrix initialized as Rotation around the X axis.
NULL if any error occurs or on invalid arguments.
ATM_CreateYRoll ( double angle ) : BLOB AT-matrixWill return an Affine Transformation Matrix initialized as Rotation around the Y axis.
NULL if any error occurs or on invalid arguments.
SQL functions supporting chaining two Affine Transformation Matrices
ATM_Translate ( double tx , double ty , BLOB AT-matrix ) : BLOB AT-matrix
ATM_Translate ( double tx , double ty , double tz , BLOB AT-matrix ) : BLOB AT-matrix
Will return an Affine Transformation Matrix by chaining respectively a 2D or 3D Translate and another Affine Transformation.
NULL if any error occurs or on invalid arguments.
ATM_Scale ( double sx , double sy , BLOB AT-matrix ) : BLOB AT-matrix
ATM_Scale ( double sx , double sy , double sz , BLOB AT-matrix ) : BLOB AT-matrix
Will return an Affine Transformation Matrix by chaining respectively a 2D or 3D Scale and another Affine Transformation.
NULL if any error occurs or on invalid arguments..
ATM_Rotate ( double angle , BLOB AT-matrix ) : BLOB AT-matrix
ATM_ZRoll ( double angle , BLOB AT-matrix ) : BLOB AT-matrix
Will return an Affine Transformation Matrix by chaining a Rotation around the Z axis and another Affine Transformation.
NULL if any error occurs or on invalid arguments.
ATM_XRoll ( double angle ) : BLOB AT-matrixWill return an Affine Transformation Matrix by chaining a Rotation around the X axis and another Affine Transformation.
NULL if any error occurs or on invalid arguments.
ATM_YRoll ( double angle ) : BLOB AT-matrixWill return an Affine Transformation Matrix by chaining a Rotation around the Y axis and another Affine Transformation.
NULL if any error occurs or on invalid arguments.
Note: all the above functions simply are convenience methods intended to avoid any need to repeatedly call ATM_Multiply().
SELECT ATM_Multiply(ATM_CreateRotate(15), 
                    ATM_Multiply(ATM_CreateScale(1.1, 1.2, 1.3), 
                                 ATM_CreateTranslate(10, 20, 30)));

SELECT ATM_Rotate(15, 
          ATM_Scale(1.1, 1.2, 1.3,
             ATM_CreateTranslate(10, 20, 30)));

SELECT ATM_Rotate(15, 
          ATM_Scale(1.1, 1.2, 1.3,
             ATM_Translate(10, 20, 30,
                ATM_Create())));
All three statements will return exactly the same identical Affine Transformation Matrix; anyway the second notation is obviously most concise and more practical than the other two.



back