Hello Martin, I looked into the code and your changes are surely helpful and I agree with your proposal. A very very simple class like "PointPair" is already in algorithm package and it's name is MappedPosition, but it is just for internal purpose for RubberSheetTansformation. The PointPair should be helpful when we would like to take the accuracy in account. After that we have to change the calculation itself, but I don't think that it should be much work (I think I've seen the equations somewhere - so when time comes I can try to do this). I'm finally going to add some documentation into the package.html.
Cheers, Jan. ______________________________________________________________ > Od: [EMAIL PROTECTED] > Komu: Jan Jezek <[EMAIL PROTECTED]> > CC: GeoTools Developers List <[email protected]> > Datum: 08.11.2006 05:12 > Předmět: More on calculator package > >Hello Jan > >I commited a first (yet untested) draft of MathTransformBuilder.getTransformation() method. This is what I would suggest to use instead of 'getMathTransform()'. In addition of the MathTransform object, a Transformation object also contains the source and target CRS, the valid area (computed as a GeographicBoundingBox containing all target points) and the accuracy (taken as the standard deviation). > >I wonder if "getStandardDeviation" is the most appropriate method name. The implementation looks like a "Root Mean Squared Error" computation (http://gislounge.com/glossary/bldefroot.shtml). I understand that both are close, since "The standard deviation is the root mean square (RMS) deviation of the values from their arithmetic mean" (http://en.wikipedia.org/wiki/Standard_deviation). But we are not computing deviation from an arithmetic mean; we are computing deviation from what is believed the real value. > >One thing that we may consider is to change the method from > > double getStandardDeviation() >to > Statistics getErrorStatistics() > >Where Statistics is an object that hold (among other) the minimal and maximal error values, and the RMS: > >http://javadoc.geotools.fr/snapshot/org/geotools/math/Statistics.html > >What do you think? > >------------------------------------------------------------------- > >I also had an other though. I wonder if we should define a new class, "PointPair" or something like that, which hold one source and one target point. The 'sourcePoints' and 'targetPoints' arrays would be replaced by a single array of instances of this "PointPair" class. This is an easy way to ensure that there is exactly one target point of each source point, but this is not the mean reason. The main reason I have in mind is that we may want to associate metadata to a "source-target" pair. For example some calculator algorithms can take the accuracy in account (some point pairs are a more confident matching than other ones). A user graphical interface may also allow to attach comments to a pair. We could easily add such field in a "PointPair" class in the future. In comparaison, two distinct DirectPosition arrays is less easily extensible. > >Should we apply such change? > > Martin > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
