Dealing with Geospatial Images is the problem you are now solving. No doubt of that. Images have an additional layer of meaning on top of the simple "position-value" relationship of a Coverage. :)
I would actually argue for factoring the additional layers of meaning entirely out of Coverage (because none of the stds have it there.) Perhaps a very simple GeospatialImage interface with three attributes is enough: getValueCoverage(), getRenderedCoverage(), getPhysicalUnitsCoverage(). Down the road we could add a getIsomorphicImage()/getPerspectiveImage(), which takes the coverage back and forth through the sensor's geometric model. > As said previously, the enumeration is not about spatial resampling > but could be > understood as "kind of units of measurement" where the enumeration > of "kind" is > driven by Image I/O and rendering restrictions in Java: > > GEOPHYSICS: are my data in some units I can use for calculation? > RENDERED: are my data in some units compatibly with Java2D restrictions? Ahh, but this enumeration does collapse two unrelated concerns into a single attribute. Think of it this way: say you have a "Geophysics" coverage AND a ColorModel has also been specified. You can then perform a spatial query (evaluate()) to retrieve "rendered" data OR to retrieve the actual data value. Arc/Info does both. Let us not become inferior to Arc/Info. :) Potentially, a coverage could have a third response to evaluate(): the raw data value in the file (different than the geophysical value if a transformation has been applied.) The same coverage has three different responses depending on the type of information requested. > etc. Because it is quite Java-specific, I do not expect to see them in an > international standard. Ahhh, but the notion of "data" vs. "a rendering of data" is already in the standards. This is the "Geospatial Image" concept found spread across 19101-2, 19115-2, 19129 (dead), and 19130 (pending). Specification of a rendering method is in 19117. The "Image" concept is not formalized to the point where we could or should stick it in GeoAPI, but it roughly equates to "data" + "portrayal" = "Image". This is not a Java specific thing. I sent out a document summarizing this Image notion about a week ago, if you're interested. I can't believe I said "Ahhh, but..." twice in one email. :) Bryce ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
