Makes sense, Martin! How do you feel about writing a real book? eg. http://manning.com/mattmann/
Adam On Mon, Nov 11, 2013 at 8:34 AM, Martin Desruisseaux < [email protected]> wrote: > 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 >>> >> >
