G'day Jon, Good questions - I like it when computing, science and epistemology collide :)
My naive 2p / 2c worth is that the domain of a coverage is simply that region within which data are defined. i will now try to argue that that is not a tautology... Following on from your example of a set of points, yes - we might decide to restrict ourselves to the convex hull and call that the domain, but there are many other possibilities. Based on our knowledge of the data, prior experience, available literature etc. we may well feel confident in defining a domain boundary that extends some way beyond the data points. This may end up being represented digitally as a coverage within which there is a data domain, possibly quite complex in shape, with some surrounding NODATA area. Extending this idea further, we might get trendily Bayesian :) and dispense with a hard domain boundary altogether, defining instead a gradient of 'reliability of interpolation' or 'expected predictive accuracy' or some such term. Then, when we use data directly from this domain, or aggregate it, or make inferences from it, we will also take into account the predictive accuracy to put bounds around our results. I think there is an argument for not attaching an interpolation method to a coverage. I'll give a real example here. Decisions about the conservation status of plant and animal species are frequently made on the basis of fairly coarse raster data, e.g. national or state-wide censuses where a data from a wide variety of sources, collected with different methods and at different scales, have been aggregated into a relatively small number of grid cells. If part of the decision process involves determining the area over which a species occurs then the grid cell size is obviously important. There are examples where it has been impossible for any species to be rated at the highest status because there was an area threshold that was smaller than the grid cell size ! Some researchers have looked at ways of interpolating within cells in such raster data, based on theoretical patterns of distribution (e.g. fractal scaling) and/or expert knowledge of fine scale factors influencing a species' occurrence. Whether or not you want to do this will depend on (a) the nature of the exercise (b) the available data and your confidence in the theoretical underpinnings of the approach (c) convincing the punters to accept it :) These are case-specific decisions and not something that is bound up in the coverage itself. Jeepers, I've gone on a bit there - sorry. But it's very interesting stuff and well worth discussing because of all the very practical implications of alternative approaches. cheers Michael On Fri, Jun 13, 2008 at 5:43 PM, Jon Blower <[EMAIL PROTECTED]> wrote: > Hi Andy, > > Thanks very much for this. Yes, please pass on anything you like to > the coverages working group. > > I guess I'm not completely clear on what a Coverage actually is, > conceptually. From the GeoAPI javadocs: > > "The essential property of coverage is to be able to generate a value > for any point within its domain." > > At first read, this implies to me that a coverage is, from the point > of view of the user, a continuous feature that produces values at any > point in the domain, by interpolation if necessary (i.e. if the > coverage is stored internally as discrete elements). It worries me > that the methods in Coverage don't allow the user to specify an > interpolation method - this really matters in science. However, see > below. > > However, this raises the question of what constitutes the "domain" of > a coverage. Let's assume we're dealing with the case where a coverage > is represented internally as a set of discrete points. Is the domain > simply the points themselves? Or their convex hull? Or some > arbitrary bounding volume, defined by the data provider (i.e. the > Envelope)? > > If the domain is simply the points themselves, what would I expect to > get if I queried for a value at a different point? If I'm reading the > GeoAPI javadocs correctly then the Coverage.find() methods should > return the nearest point, whereas the evaluate() methods would throw > a PointOutsideCoverageException. However, some methods explicitly say > that this exception is thrown when the point is outside the Coverage's > Envelope, implying that the Envelope defines the domain. Is this > right? > > I guess this all boils down to the following question: is the Domain > of a Coverage always a contiguous rectangular region of space, i.e. > its Envelope (in which case interpolation is implicit)? Or can the > domain be a set of discrete points (in which case interpolation is > disallowed)? > > Cheers, Jon > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
