The porting of GeoTools 2.x projections is finished, except Krovak which is in
progress right now. The main change compared to Proj4/GeoTools 2.x is described
below:
Projections are non-linear operations. But there is a few linear operations
performed before and after the non-linear ones.
* Before the non-linear part, the linear operations are the conversions
from degrees to radians and the removal of central meridian value.
* After the non-linear part, the linear operations are the multiplication
by the global scale (including a projection-specific scale factor and
the semi-major axis length) and the addition of false easting/northing.
Those linear parts can be removed from the projection code and inserted into
affine transforms to be applied before and after the projection. Because the
projections are often used together with affine transforms anyway (for unit
conversions, for swapping the order of (latitude,longitude) axes, for rendering
to screen, etc.), it does not introduce any additional cost. Quite the opposite,
those affine transforms can be efficiently concatenated, resulting in less
floating point operations when tranforming coordinates (just a few less
multiplications - probably unoticeable compared to the cost of calling sin and
cos functions).
But the mean interest is not there. By moving those linear operations out of the
projection code, many projection parameters disaspear from the projection
objects. At first we get ride of "central_meridian", "scale_factor",
"false_easting" and "false_northing" (since they now appears in the affine
transforms). But my experience with the work I did during the last months in
GeoTools/Geotidy is that a few more parameters - on a projection-by-projection
basis - also disaspear from the projection code, to be moved in the affine
transforms.
At the end, Mercator and TransverseMercator depends only on the Earth's
excentricity; everything else moved to affine transforms. Other projections have
more parameters than can't be moved.
Because TransverseMercator depends only on Earth's excentricty, projecting
coordinates from a UTM zone to an other UTM zone on the same datum (a quite
common operation when we are at the border of 2 UTM zones) can now be easily
calculated as an affine transform. No need anymore to convert from the first UTM
zone to geographic coordinates, than from geographic coordinates to the second
UTM zone. Using directly the affine transforms is considerably faster,
especially when projection rasters (because resampling of images using affine
transforms have hardware accelerations).
This acceleration do not benefit to all projections since it depends on how many
parameters remains involved in non-linear equations.
On the equation side, a side-effect of using affine transforms is that all
special cases like the above one disaspear:
if (southPole) {
// some formulas here
} else {
// Formulas for North pole, often identical to the
// South pole case with a few sign reverted.
}
A single unified formulas handles both the north and south case, with the change
of sign handle by the affine transforms before or after that part.
Martin
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
