Hello all
The main work this week has been an effort to increase the accuracy of
the matrix computed by the
BursaWolfParameters.getPositionVectorTransformation() method. This was a
known problem in Geotk. The intend is not to have an accurate "position
vector transformation" (that would be pointless since this
transformation method, like all datum shifts, is only approximative
anyway). The intend is to get back an identity matrix when concatenating
a chain of operations having "A -> B" followed by "B -> A". More
specifically the problem was:
* "Position vector transformation", when expressed in matrix form, is
close to an identity matrix (values are quite small).
* When performing matrix inversions and multiplications, rounding
errors accumulate relatively fast.
* As a consequence of combination of the two above points, some
concatenation of transformations resulted in matrices difficult to
distinguish from noise.
The usual strategy for floating point values:
if (abs(value) < epsilon)
didn't worked in this case, because the overlapping between "signal" and
"noise" were too high in some situations: sometime a real datum shift
was considered as noise, and conversely. This problem does not happen
for a BursaWolfParameters object alone, but appears after a few
concatenations. The work of the last few weeks is an attempt to improve
the discrimination between signal and noise in coordinate transformation
chains.
My plan for next week is to add a new property in BursaWolfParameters:
its domain of validity. This information was missing in Geotk, and
experience has shown that this was a problem. Then, I plan to complete
the GeodeticObjects class. When GeodeticObjects will provide at least
the WGS84 GeographicCRS, I think that the class would be okay for a SIS
0.4 release (remaining work would be to provide a basic Feature class
for the Shapefile reader).
Martin
