>To: Jan Jezek <[EMAIL PROTECTED]>
>From: Martin Desruisseaux <[EMAIL PROTECTED]>
>Sent by: [EMAIL PROTECTED]
>Date: 11/07/2006 09:12PM
>cc: GeoTools Developers List <[email protected]>
>Subject: [Geotools-devel] More on calculator package
>
>Hello Jan
>
>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.
Standard deviation is only standard deviation if the calculation is performed on a random sampling of a normal distribution. You can use the equation on any set of numbers, of course, but that doesn't mean that a standard deviation pops out. :) I think in this scenario, we're talking about systemic errors resulting from the transformation parameters being slightly off. I could live with the notion of a "bounded error" (min error and max error) instead of a std dev.
I like your "Statistics" approach, below. However, I think there might already be a 19115 metadata object that has min/max values at least. Maybe if we need extra fields, we should just extend that?
>
>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.
I fear this approach for coverages with many points. It smacks of good design, but seems like it would be a memory hog. Perhaps a Map<DirectPosition,DirectPosition> where the values are calculated from the keys on demand?
>
>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=121
>642
>_______________________________________________
>Geotools-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
------------------------------------------------------------------------- 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
