Hello Adam
Maybe one issue that we will face is that it may be easy to get lost in
the implementation details, and hard to get the "big picture". The
"developer guide" docbook document is an attempt to address this issue,
but it will take a long time before I complete it (it is like writing a
book). For now, the most concrete "big picture" I'm aware of are annexes
B and C of the following document:
http://portal.opengeospatial.org/files/?artifact_id=39049
Annexes B and C are "Context for modelling of spatial referencing by
coordinates" and "Spatial referencing by coordinates – Geodetic
concepts" respectively. This document is more "concrete" for us than
other geodesy books because the concepts explained there map directly to
a SIS class (or upcoming class). The Bursa-Wolf parameters are not cited
explicitly in this document, but appears indirectly in paragraph C.4
under the name "Helmert transformation".
OGC is considering to publish their specifications as plain HTML pages.
If they do, that would make our task easier since javadoc could point
directly to the corresponding clause of a specification.
Cheers,
Martin
Le 10/11/13 15:58, Adam Estrada a écrit :
Thanks Martin! I am not 100% with the inner workings of most coordinate
transformations so I am learning a lot watching you work through these
features
Cheers,
Adam
On Fri, Nov 8, 2013 at 6:07 PM, Martin Desruisseaux <
[email protected]> wrote:
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
