Re: [GeoShaver] Re: Status of Coverages in GeoAPI and GeoTools

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: Status of Coverages in GeoAPI and GeoTools

Martin Desruisseaux
Jon Blower a écrit :
> Thanks for this clarification.  So I guess we can safely use the
> Coverage interface (from GeoAPI) and the GridCoverage2D class (from
> GeoTools).  If we stick to methods from Coverage (not GridCoverage)
> we'll probably be OK.  Is that right?

Yes I think so (but can't be 100% sure).


> Another question: are there any implementations in GeoTools of the
> DiscreteCoverages?

No. GeoTools implements nothing from ISO 19123 at this time.


> Oh, and another: when requesting a value from a Coverage that doesn't
> correspond directly with a sample point, what interpolation method is
> used or assumed?  I couldn't find a parameter for the user to specify
> a method.

By default, nearest neighboard. In order to apply an other interpolation method,
you need to apply the "interpolate" operation as below (from memory):

Coverage coverage = ...
coverage = Operations.DEFAULT.interpolate(coverage, "bilinear");

It will returns a new GridCoverage2D instance backed by the same data (the
RenderedImage data will not be copied, so it should be reasonably cheap on
memory usage), but using the given interpolation method. Behind the hood, the
returned GridCoverage2D is actually an instance of Interpolator2D, but you don't
need to known this interpolation details.

The supported interpolation are the one supported by JAI: "nearest", "bilinear",
"bicubic", "bicubic2". You can also defines your own interpolations if you wish,
using JAI API (creating a subclass of javax.media.jai.Interpolation).

GeoTools also has an extension which is not part of OGC specification: you can
specify an array of interpolation methods instead of a single method. For
example if you invoke the "interpolate" operation with the following arguments
(from memory - I don't remember the exact API):

String[] {
     "bicubic",
     "bilinear",
     "nearest"
};

Then everytime an evaluate method is invoked, GeoTools will tries the bicubic
interpolation first. If it get NaN, then it tried bilinear interpolation (which
requires less pixels, so less chances that one of those pixels has a NaN value).
If the later produced NaN as well, then if fallback on last resort to nearest
neighboard. This fallback mechanism is useful for coverage like "sea surface
temperature" with lot of "nodata values" (typically clouds), and we want to
interpolate only when it will not cause a lost of data.

        Martin

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: Status of Coverages inGeoAPI and GeoTools

Martin Desruisseaux
Andy Turner a écrit :
> I think a continuous coverage is one where for any location a value is obtained by interpolation and that for a discrete coverage the value at any point is known directly. (The distinction, continuous or discrete is nothing to do with the values attributed to the coverage.)

Yes it is also my understanding. It GeoTools implementation, GridCoverage2D
(without subclassing) would be a discrete coverage (minus tricky boundary issues
like the ones you mentioned) while Interpolator2D would be a continuous
coverage. But at this time GeoTools does not implement ISO interfaces that way.
However this is something we would like to do in the future.

        Martin

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: [GeoShaver] Re: Status of Coverages inGeoAPI and GeoTools

Jon Blower
Ah, interesting.  Just to check I've understood this correctly:

1) A coverage represented internally by a grid (e.g. numerical model
output, digital photo or satellite image) is a type of
DiscreteCoverage in ISO19123 (perhaps a DiscreteGridPointCoverage)?

2) For a DiscreteCoverage, if I ask for a value at a point that
doesn't correspond exactly with a grid point I will get the value from
the nearest grid point (i.e. nearest-neighbour interpolation).  Or do
I actually get null?

3) However, in GeoTools, the DiscreteCoverages are not implemented.
The GridCoverage2D class does not implement ISO19123 interfaces but it
is effectively a discrete coverage that performs nearest-neighbour
interpolation.

4) If I want bilinear (or bicubic or anything else) interpolation then
I need to take my GridCoverage2D and somehow convert it to an
Interpolator2D.  How do I do this?

Another question: Is it possible to have different interpolation
methods in different directions (e.g. nearest-neighbour in the
horizontal, linear in the vertical)?

Cheers, Jon

On Wed, Jun 11, 2008 at 4:20 PM, Martin Desruisseaux
<[hidden email]> wrote:

>
> Andy Turner a écrit :
>> I think a continuous coverage is one where for any location a value is obtained by interpolation and that for a discrete coverage the value at any point is known directly. (The distinction, continuous or discrete is nothing to do with the values attributed to the coverage.)
>
> Yes it is also my understanding. It GeoTools implementation, GridCoverage2D
> (without subclassing) would be a discrete coverage (minus tricky boundary issues
> like the ones you mentioned) while Interpolator2D would be a continuous
> coverage. But at this time GeoTools does not implement ISO interfaces that way.
> However this is something we would like to do in the future.
>
>        Martin
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "GeoShaver" group.
>  To post to this group, send email to [hidden email]
>  To unsubscribe from this group, send email to [hidden email]
>  For more options, visit this group at http://groups.google.co.uk/group/geoshaver?hl=en-GB
> -~----------~----~----~----~------~----~------~--~---
>
>



--
--------------------------------------------------------------
Dr Jon Blower              Tel: +44 118 378 5213 (direct line)
Technical Director         Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre   Fax: +44 118 378 6413
ESSC                       Email: [hidden email]
University of Reading
3 Earley Gate
Reading RG6 6AL, UK
--------------------------------------------------------------

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: [GeoShaver] Re: Status ofCoverages inGeoAPI and GeoTools

Jon Blower
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

On Thu, Jun 12, 2008 at 10:48 PM, Andy Turner <[hidden email]> wrote:

> Hi Jon et al,
>
> Jon's are all good questions, sorry I went off on a tangent. I don't know about any of the numbered ones, but the coverages working group of the OGC TC might. Do you want me to pass them on?
>
> In principal I think you can use whatever generalisation of values in the coverage to produce an interpolated value. However I don't know if this principal is reflected in the standards documentation or software implementations. A further thing to note is that there are generalisions (interpolations) of values in a single variable/coverage and those that involve multiple variables/coverages. For instance I might chose to guide an interpolation based on a combination of values from multiple coverages. IMHO, this is still interpolation. It is even interpolation when the value is going to be outwith the current range of values in the coverage.
>
> Regards,
>
> Andy
>
>
> -----Original Message-----
> From: [hidden email] on behalf of Jon Blower
> Sent: Wed 11/06/2008 17:55
> To: [hidden email]
> Cc: Andy Turner; [hidden email]
> Subject: Re: [Geotools-gt2-users] [GeoShaver] Re: [GeoShaver] Re: Status ofCoverages inGeoAPI and GeoTools
>
> Ah, interesting.  Just to check I've understood this correctly:
>
> 1) A coverage represented internally by a grid (e.g. numerical model
> output, digital photo or satellite image) is a type of
> DiscreteCoverage in ISO19123 (perhaps a DiscreteGridPointCoverage)?
>
> 2) For a DiscreteCoverage, if I ask for a value at a point that
> doesn't correspond exactly with a grid point I will get the value from
> the nearest grid point (i.e. nearest-neighbour interpolation).  Or do
> I actually get null?
>
> 3) However, in GeoTools, the DiscreteCoverages are not implemented.
> The GridCoverage2D class does not implement ISO19123 interfaces but it
> is effectively a discrete coverage that performs nearest-neighbour
> interpolation.
>
> 4) If I want bilinear (or bicubic or anything else) interpolation then
> I need to take my GridCoverage2D and somehow convert it to an
> Interpolator2D.  How do I do this?
>
> Another question: Is it possible to have different interpolation
> methods in different directions (e.g. nearest-neighbour in the
> horizontal, linear in the vertical)?
>
> Cheers, Jon
>
> On Wed, Jun 11, 2008 at 4:20 PM, Martin Desruisseaux
> <[hidden email]> wrote:
>>
>> Andy Turner a écrit :
>>> I think a continuous coverage is one where for any location a value is obtained by interpolation and that for a discrete coverage the value at any point is known directly. (The distinction, continuous or discrete is nothing to do with the values attributed to the coverage.)
>>
>> Yes it is also my understanding. It GeoTools implementation, GridCoverage2D
>> (without subclassing) would be a discrete coverage (minus tricky boundary issues
>> like the ones you mentioned) while Interpolator2D would be a continuous
>> coverage. But at this time GeoTools does not implement ISO interfaces that way.
>> However this is something we would like to do in the future.
>>
>>        Martin
>>
>> --~--~---------~--~----~------------~-------~--~----~
>> You received this message because you are subscribed to the Google Groups "GeoShaver" group.
>>  To post to this group, send email to [hidden email]
>>  To unsubscribe from this group, send email to [hidden email]
>>  For more options, visit this group at http://groups.google.co.uk/group/geoshaver?hl=en-GB
>> -~----------~----~----~----~------~----~------~--~---
>>
>>
>
>
>
> --
> --------------------------------------------------------------
> Dr Jon Blower              Tel: +44 118 378 5213 (direct line)
> Technical Director         Tel: +44 118 378 8741 (ESSC)
> Reading e-Science Centre   Fax: +44 118 378 6413
> ESSC                       Email: [hidden email]
> University of Reading
> 3 Earley Gate
> Reading RG6 6AL, UK
> --------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
>



--
--------------------------------------------------------------
Dr Jon Blower Tel: +44 118 378 5213 (direct line)
Technical Director Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre Fax: +44 118 378 6413
ESSC Email: [hidden email]
University of Reading
3 Earley Gate
Reading RG6 6AL, UK
--------------------------------------------------------------

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: [GeoShaver] Re: Status ofCoverages inGeoAPI and GeoTools

mbedward
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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: [GeoShaver] Re: Status ofCoverages inGeoAPI and GeoTools

mbedward
In reply to this post by Jon Blower
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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: [GeoShaver] Re: Status ofCoverages inGeoAPI and GeoTools

Andy Turner
In reply to this post by Jon Blower
I think were grappling with the difference between what is a continuous coverage and what is a discrete coverage. Yes (I think we agree), my understanding is that in querying a continuous coverage a method should in principal be able to return a value that is not a no data value (null) at any point in its domain (also it's envelope). (I'm not too hot on terminology here, but domain seems to be the right word and I'd expect envelop to be something very similar if not equivallent in this case and I don't know if they need be rectangular, but that also might be a difference - sorry I'm trying to find out). In querying a discrete coverage we can expect null returns within the envelope. for some points, but that depends on how the boundaries of two discrete parts of the coverage are defined. I don't know if it is allowed to return more than one value for a discrete coverage which might be the case at a boundary, or if the discrete parts of the coverage are allowed to overlap. In terms of domain, perhaps this is the union of all parts that return at least one non null value. In terms of discrete raster coverages (sometimes raster is called grid), when there is only one variable there is only the problem of what to do on the boundary parts. I am still not clear on what is a discrete coverage yet. I did skim a document [1] and remember seeing point type raster coverages as a special case of discrete coverages.

I'll try to pass on this thread somehow to the OGC Coverages group now. I'm not sure how best to do this yet as we could end up even more fragmented communication posting to 3 lists... First things first, I have sent a request to join the Coverages.wg email list at OGC. I think this is an open list if you are an OGC portal user, but it may be a public list.

Is it time for the University of Reading to become an OGC member Jon. I've been wondering if NeSC could join on behalf of us all... That's a bit off topic though.

Bye for now...

Andy

[1] The OpenGIS® Abstract Specification Topic 6: Schema for coverage geometry and functions (http://portal.opengeospatial.org/files/?artifact_id=19820)

[2] https://lists.opengeospatial.org/mailman/listinfo/coverages.wg

-----Original Message-----
From: [hidden email] on behalf of Jon Blower
Sent: Fri 13/06/2008 08:43
To: Andy Turner
Cc: [hidden email]; [hidden email]
Subject: Re: [Geotools-gt2-users] [GeoShaver] Re: [GeoShaver] Re: Status ofCoverages inGeoAPI and GeoTools
 
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

On Thu, Jun 12, 2008 at 10:48 PM, Andy Turner <[hidden email]> wrote:

> Hi Jon et al,
>
> Jon's are all good questions, sorry I went off on a tangent. I don't know about any of the numbered ones, but the coverages working group of the OGC TC might. Do you want me to pass them on?
>
> In principal I think you can use whatever generalisation of values in the coverage to produce an interpolated value. However I don't know if this principal is reflected in the standards documentation or software implementations. A further thing to note is that there are generalisions (interpolations) of values in a single variable/coverage and those that involve multiple variables/coverages. For instance I might chose to guide an interpolation based on a combination of values from multiple coverages. IMHO, this is still interpolation. It is even interpolation when the value is going to be outwith the current range of values in the coverage.
>
> Regards,
>
> Andy
>
>
> -----Original Message-----
> From: [hidden email] on behalf of Jon Blower
> Sent: Wed 11/06/2008 17:55
> To: [hidden email]
> Cc: Andy Turner; [hidden email]
> Subject: Re: [Geotools-gt2-users] [GeoShaver] Re: [GeoShaver] Re: Status ofCoverages inGeoAPI and GeoTools
>
> Ah, interesting.  Just to check I've understood this correctly:
>
> 1) A coverage represented internally by a grid (e.g. numerical model
> output, digital photo or satellite image) is a type of
> DiscreteCoverage in ISO19123 (perhaps a DiscreteGridPointCoverage)?
>
> 2) For a DiscreteCoverage, if I ask for a value at a point that
> doesn't correspond exactly with a grid point I will get the value from
> the nearest grid point (i.e. nearest-neighbour interpolation).  Or do
> I actually get null?
>
> 3) However, in GeoTools, the DiscreteCoverages are not implemented.
> The GridCoverage2D class does not implement ISO19123 interfaces but it
> is effectively a discrete coverage that performs nearest-neighbour
> interpolation.
>
> 4) If I want bilinear (or bicubic or anything else) interpolation then
> I need to take my GridCoverage2D and somehow convert it to an
> Interpolator2D.  How do I do this?
>
> Another question: Is it possible to have different interpolation
> methods in different directions (e.g. nearest-neighbour in the
> horizontal, linear in the vertical)?
>
> Cheers, Jon
>
> On Wed, Jun 11, 2008 at 4:20 PM, Martin Desruisseaux
> <[hidden email]> wrote:
>>
>> Andy Turner a écrit :
>>> I think a continuous coverage is one where for any location a value is obtained by interpolation and that for a discrete coverage the value at any point is known directly. (The distinction, continuous or discrete is nothing to do with the values attributed to the coverage.)
>>
>> Yes it is also my understanding. It GeoTools implementation, GridCoverage2D
>> (without subclassing) would be a discrete coverage (minus tricky boundary issues
>> like the ones you mentioned) while Interpolator2D would be a continuous
>> coverage. But at this time GeoTools does not implement ISO interfaces that way.
>> However this is something we would like to do in the future.
>>
>>        Martin
>>
>> --~--~---------~--~----~------------~-------~--~----~
>> You received this message because you are subscribed to the Google Groups "GeoShaver" group.
>>  To post to this group, send email to [hidden email]
>>  To unsubscribe from this group, send email to [hidden email]
>>  For more options, visit this group at http://groups.google.co.uk/group/geoshaver?hl=en-GB
>> -~----------~----~----~----~------~----~------~--~---
>>
>>
>
>
>
> --
> --------------------------------------------------------------
> Dr Jon Blower              Tel: +44 118 378 5213 (direct line)
> Technical Director         Tel: +44 118 378 8741 (ESSC)
> Reading e-Science Centre   Fax: +44 118 378 6413
> ESSC                       Email: [hidden email]
> University of Reading
> 3 Earley Gate
> Reading RG6 6AL, UK
> --------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
>



--
--------------------------------------------------------------
Dr Jon Blower Tel: +44 118 378 5213 (direct line)
Technical Director Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre Fax: +44 118 378 6413
ESSC Email: [hidden email]
University of Reading
3 Earley Gate
Reading RG6 6AL, UK
--------------------------------------------------------------


-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: Status of Coverages in GeoAPI and GeoTools

Martin Desruisseaux
In reply to this post by Jon Blower
Jon Blower a écrit :
> 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.

Yes. If we stick to numerical results, I see coverage as a function of (x,y,z,t)

The interpolation could be specified at ContinuousCoverage construction time.
ISO 19123 do not specifies constructors and we have not yet proposed Coverage
factories in GeoAPI, so this task still on the todo list.


> 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 I was going to implement that today, I would probably use the Envelope. But
the convex hull could be an other serious candidate. I don't think that it needs
to be the individual points however.

ISO 19123 defines a Coverage.getDomainExtents() association which returns (in my
understanding) domain limits for the coverage as a whole. The return values are
ISO 19115 Extent object, including GeographicExtent which may describe the
extents as polygons, geographic bounding box or plain geographic identifier
(e.g. the name of a city). So the definition is somewhat fuzzy.


> 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?

GeoAPI defines a PointOutsideCoverageException, but this exception is actually
imported from OGC 01-004 and we left to implementors the decision about when to
thrown this exception.

The wording has changed between GeoAPI 2.1 and 2.2-SNAPSHOT. Current wording
said "Thrown when a evaluate method is invoked for a location outside the domain
of the coverage".



> 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)?

I think we can eliminate the set of discret points, given that there is no way I
can see to express that as an ISO 19115 Extent and the
Coverage.getDomainExtents() is mandatory and must contains at least one element.

        Martin

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: Status of Coverages in GeoAPI and GeoTools

Martin Desruisseaux
In reply to this post by Andy Turner
Andy Turner a écrit :
> my understanding is that in querying a continuous coverage a method should in principal be able to return a value that is not a no data value (null) at any point in its domain (...snip...). In querying a discrete coverage we can expect null returns within the envelope. for some points, but that depends on how the boundaries of two discrete parts of the coverage are defined. I don't know if it is allowed to return more than one value for a discrete coverage which might be the case at a boundary, or if the discrete parts of the coverage are allowed to overlap.

I don't think that the difference between discrete and continuous coverage is
about returning null (nodata) values or not. I think that the difference is
rather that DiscreteCoverage do not applies interpolation. evaluate(point)
returns the same value for every point inside a pixel, no matter if the point is
at the pixel center or near the corner of that pixel. On the contrary,
ContinuousCoverage can apply an interpolation, so that requerying the value at
the center or near the corner of a pixel will produce different values. Whatever
that pixel represents a "nodata" value is an other topic.

I think that overlapping objects are allowed in discrete coverages.

        Martin

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: Status of Coverages in GeoAPI and GeoTools

Jon Blower
Hi Martin,

> I don't think that the difference between discrete and continuous coverage is
> about returning null (nodata) values or not. I think that the difference is
> rather that DiscreteCoverage do not applies interpolation. evaluate(point)
> returns the same value for every point inside a pixel, no matter if the point is
> at the pixel center or near the corner of that pixel. On the contrary,
> ContinuousCoverage can apply an interpolation, so that requerying the value at
> the center or near the corner of a pixel will produce different values. Whatever
> that pixel represents a "nodata" value is an other topic.

My problem with this is that, to my mind, nearest-neighbour
interpolation is still interpolation.  You are still "inventing" data
values where no data was measured.  When I call evaluate() I need to
know whether I am getting a "true" data value or an interpolated one.
I am talking in particular about the case where a Coverage is created
from a set of point measurements.  One might decide that these points
are representative of a finite-sized "cell" but there is no guarantee
that these cells will be contiguous.  Therefore in general there will
always be points outside the cells that are unsampled.  Are such
points considered outside the domain of the Coverage?  Or is a
Coverage simply the wrong choice of data structure for this kind of
information?

Cheers, Jon

--
--------------------------------------------------------------
Dr Jon Blower Tel: +44 118 378 5213 (direct line)
Technical Director Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre Fax: +44 118 378 6413
ESSC Email: [hidden email]
University of Reading
3 Earley Gate
Reading RG6 6AL, UK
--------------------------------------------------------------

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: [GeoShaver] Re: Status ofCoverages inGeoAPI and GeoTools

Jon Blower
In reply to this post by mbedward
Hi Michael,

Thanks very much for this.

> My naive 2p / 2c worth is that the domain of a coverage is simply that
> region within which data are defined.

I like this definition because I understand it!  However, I'm not sure
that everyone has the same view.  I think the $64000 question is: does
the domain for a single coverage have to be contiguous?  If so, this
would seem to rule out the use of a Coverage for a discretely-sampled
domain in which you don't want to apply interpolation of any kind.

If domains are allowed to be non-contiguous then this complicates
things somewhat but not impossibly so.

I think this has revealed a problem with terminology.  It seems that
GeoAPI/Tools interprets a DiscreteCoverage to be a
discretely-*sampled* coverage, which is nevertheless conceptually a
contiguous region (with the gaps filled in by nearest-neighbour
interpolation).  A ContinuousCoverage might also be discretely sampled
but the gaps are filled by some other interpolation method.  I don't
think this is a very obvious use of the terms.

By contrast, I believe that the Climate Science Modelling Language (a
GML Application Schema) regards a DiscreteCoverage to be
non-contiguous, i.e. the domain consists of a number of sub-domains
that do not touch or intersect.  Andrew Woolf or Dom Lowe would be
able to confirm whether my interpretation is correct here.

For the record the CSML interpretation is more obvious to me.  The
GeoAPI/Tools interpretation differentiates on the basis of
interpolation method, which I do not find very satisfactory.

But I haven't read the ISO specs - I'm hoping that someone else will
do that! ;-)

Cheers, Jon

P.S. I know this conversation has become a bit fragmented.  I'll try
to find time to type this up on a web page or something.

On Fri, Jun 13, 2008 at 9:29 AM, Michael Bedward
<[hidden email]> wrote:

> 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

--
--------------------------------------------------------------
Dr Jon Blower Tel: +44 118 378 5213 (direct line)
Technical Director Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre Fax: +44 118 378 6413
ESSC Email: [hidden email]
University of Reading
3 Earley Gate
Reading RG6 6AL, UK
--------------------------------------------------------------

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: Status of Coverages in GeoAPI and GeoTools

Simone Giannecchini-3
In reply to this post by Martin Desruisseaux
Hi all,
trying to get up to speed a litlle bit late :-)...

On Wed, Jun 11, 2008 at 1:30 PM, Martin Desruisseaux
<[hidden email]> wrote:

>
> Jon Blower a écrit :
>> One of the key factors affecting our work in GeoShaver (and actually
>> in another project I'm involved in too) is the Coverage concept and
>> its implementation.  I understand that things are changing with
>> ISO19123, but I was wondering if someone could summarize the current
>> state of GeoAPI and GeoTools with respect to the new Coverages.  How
>> long will it take to have stable Coverage APIs in GeoAPI and stable
>> implementations in GeoTools?
>
> ISO 19123 interfaces was wrote by a mix of (if my memory serve me right) Simone,
> Daniele, Bryce and myself. I believe that all interfaces are there (maybe Simone
> could tell us if I'm forgetting any). We still have a few unresolved open issues
> flagged by "todo" javadoc tags. They are visible in the javadoc (unfortunatly we
> don't have an automatically generated summary of all "todo" at this time).

it was actually Alessio I believe who spent some time a while ago in
finishing the iso 19123 interfaces, but I am not 100% sure the work
has been completed.



>
> Most interfaces from the legacy OGC 01-004 have been deprecated, but not yet
> removed. The GeoTools implementation still implements the legacy specification.
> It is not clear at this time which interfaces will really be removed and which
> one will be un-deprecated. For example in the referencing module we have reused
> a few intefaces from the legacy OGC 01-009 when ISO 19111 had nothing equivalent
> (MathTransform, AuthorityFactory...).
>
> So I would said:
>
> * I believe that the Coverage interface is stable except the few methods flagged
>   with "todo", but even those would probably have only minor modifications.
>
> * We will probably try to retrofit GridRange (from OGC 01-004) into GridEnvelope
>   (from ISO 19123). GridRange would be removed, but from user eyes the change
>   would probably be only class/method renaming with same functionalities.
>
> * I'm not sure about GridGeometry. This class is crucial in current GridCoverage
>   design, and I dont know yet if it can be retrofited in existing ISO 19123
>   constructs. If there is no ISO 19123 equivalent, we may keep it.

I share this view, we should try to retrofit the grid geometry related
classes since they ahve proven ot be life-saver utilities, at least
IMHO.

>
> * I don't know what to do with ColorInterpretation, ByteInValuePacking and the
>   like. There is nothing equivalent in ISO 19123. However we can infer the same
>   information from Java RenderedImage API. So maybe we could just remove them.
>

The way I see it, 19123 does not mention color intepretation at all
since it seems (going from memory) to focus only on values, which
would probably map well with Raster or DataBuffer in java.

This might lead to discuss a little bit over the various view types
that have been introduced lately in geotools (daniele should send an
email anyway)




> * The future of GridCoverage is unsure. My guess is that the DataBlock related
>   methods will either be removed, or move to GridValuesMatrix. I think that the
>   only really useful GridCoverage method is "getGridGeometry()" - the other ones
>   are inherited from Coverage. So my guess is that:
>
>   - GeoTools GridCoverage2D implementation will not have major change. It will
>     keep its implementation-specific methods like getRenderedImage().

I completely agree. even though I think that we should  relax a bit
the need for specifying categories and the like at construction time,
but that requries discussion anyway.

>
>   - GeoAPI GridCoverage interface may be removed - it depends what we decice
>     to do with the above points (especially GridGeometry).
>

We might even move them to geotools as part of our implementation,
just a random thought.


>   - GridCoverage2D would probably implements a few ISO 19123 interfaces in
>     replacement (or in addition) of GridCoverage. I'm not sure which ones.
>

I would see CoverageStack, with a few modifications as a good
condidate for being the base class for 19123 implementation.
GridCoverage2D would probably become part of our implementation but
not part of GeoApi interfaces.



Simone.

>
>> For many projects, GridCoverages are the most important things for now
>> (CV_RectifiedGrid and CV_ReferenceableGrid I think).  How much work is
>> there still to do in this area?
>
> Maybe one or two months, once we are able to work on it. Right now we are stuck
> in other projects, so unfortunatly it is very difficult to give a timeline...
>
>        Martin
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "GeoShaver" group.
>  To post to this group, send email to [hidden email]
>  To unsubscribe from this group, send email to [hidden email]
>  For more options, visit this group at http://groups.google.co.uk/group/geoshaver?hl=en-GB
> -~----------~----~----~----~------~----~------~--~---
>
>



--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928


http://www.geo-solutions.it

-------------------------------------------------------

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: Status of Coverages inGeoAPI and GeoTools

Simone Giannecchini-3
In reply to this post by Martin Desruisseaux
On Wed, Jun 11, 2008 at 8:49 PM, Martin Desruisseaux
<[hidden email]> wrote:

>
> Jon Blower a écrit :
>> 1) A coverage represented internally by a grid (e.g. numerical model
>> output, digital photo or satellite image) is a type of
>> DiscreteCoverage in ISO19123 (perhaps a DiscreteGridPointCoverage)?
>
> In my understanding, a ContinuousCoverage could be backed by a grid as well, but
> with the addition of an interpolation.
>
>
>> 2) For a DiscreteCoverage, if I ask for a value at a point that
>> doesn't correspond exactly with a grid point I will get the value from
>> the nearest grid point (i.e. nearest-neighbour interpolation).  Or do
>> I actually get null?
>
> Nearest neighbour in my understanding.
>

>
>
>> 3) However, in GeoTools, the DiscreteCoverages are not implemented.
>> The GridCoverage2D class does not implement ISO19123 interfaces but it
>> is effectively a discrete coverage that performs nearest-neighbour
>> interpolation.
>
> Yes. A subtile nuance is that a GridCoverage2D subclass (namely Interpolator2D)
> act as a ContinuousCoverage. If GridCoverage2D is declared as a DiscreteCoverage
> and if we follow ISO 19123 spirit, then GridCoverage2D should not have any
> children that are ContinuousCoverage; it would need to be a different hierarchy.
>

I am not so sure about this interpreation, but of course I might be wrong.

The coverage function for a DiscreteCoverage list a collection of
GeometryValue pairs.
A GeometryValue  pair would be something like <DomainObject, Record>.

If we have a discrete coverage where the DomainObjects are points we
should then have a set of pairs <pont,values>. I remember that 19123
says that locate and evaluate should return null or (no data) if ask
for a direct position that is not contained in any of the
DomainObjects contained in the overage function collection.

Note that the case of having an envelope as a DomainObject would mean
that have only record for the coverage over the whole envelope.

To summarize, it seems to me that a GridCoverage2D as it is
implemented right now is a ContinuousCoverage that simply does NN
interpolation within its envelope.
If we would want to implement it as a discrete coverage where the
DomainObjects are points we should have  to provide a geom-value pair
for each point inside what we actually call the envelope of the
coverage and return null if we don't ask exactly for one of the
positions we have.
Of course this opens a discussion by itself since we would have to
decide how close we have to be to a certain point to actually say,
that we have a much. Food for more thoughts probably...


Simone.

>
>> 4) If I want bilinear (or bicubic or anything else) interpolation then
>> I need to take my GridCoverage2D and somehow convert it to an
>> Interpolator2D.  How do I do this?
>
> Use the Operations.interpolate(...) method.
>
>
>> Another question: Is it possible to have different interpolation
>> methods in different directions (e.g. nearest-neighbour in the
>> horizontal, linear in the vertical)?
>
> Yes. Interpolator2D acts only on 2D slices. In order to create the vertical or
> temporal dimension, you can give a list of GridCoverage2D (or Interpolator2D) to
> CoverageStack. The later uses its own interpolation mechanism for the dimensions
> that are not managed by Interpolator2D. Currently the supported CoverageStack
> interpolations are only nearest neighbor and linear.
>
>        Martin
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "GeoShaver" group.
>  To post to this group, send email to [hidden email]
>  To unsubscribe from this group, send email to [hidden email]
>  For more options, visit this group at http://groups.google.co.uk/group/geoshaver?hl=en-GB
> -~----------~----~----~----~------~----~------~--~---
>
>



--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928


http://www.geo-solutions.it

-------------------------------------------------------

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: [GeoShaver] Re: Status ofCoverages inGeoAPI and GeoTools

Simone Giannecchini-3
In reply to this post by Jon Blower
On Fri, Jun 13, 2008 at 9:43 AM, Jon Blower <[hidden email]> 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.
>

ContinuosCoverage explicitly allows to specify interpolation

> 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)?
>

The domain of a DiscreteCoverage in this case should be constituted by
the collection of the single points that are the back end of the
discrete coverage itself.
If we then want to create a ContinuousCoverage out of this
DiscreteCoverage we can define a ContinousCoverage whose domain is the
convex hull (or the envelope) of the DiscreteCoverage domain (which is
a collection of points) and use the interpolation between the points
of the discrete coverage (in this sense a GridCoverage2D is a
ContinuosCoverage that does NN itnerpolation).

I have grabbed an old 19123 and the difference is subtle   but seems
to exist. Specifically there exists a chapter for
DiscretePointCoverage which explicitly mention the fact that it could
be used as a base for a ContinuosCoverage by means of interpolation.



> 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)?

I believe the second would apply for a DiscreteCoverage backed by
points. Let's just think to the case of sparse points and then you
realize why you don't want interpolation in DiscreteCoverage-

Simone.

>
> Cheers, Jon
>
> On Thu, Jun 12, 2008 at 10:48 PM, Andy Turner <[hidden email]> wrote:
>> Hi Jon et al,
>>
>> Jon's are all good questions, sorry I went off on a tangent. I don't know about any of the numbered ones, but the coverages working group of the OGC TC might. Do you want me to pass them on?
>>
>> In principal I think you can use whatever generalisation of values in the coverage to produce an interpolated value. However I don't know if this principal is reflected in the standards documentation or software implementations. A further thing to note is that there are generalisions (interpolations) of values in a single variable/coverage and those that involve multiple variables/coverages. For instance I might chose to guide an interpolation based on a combination of values from multiple coverages. IMHO, this is still interpolation. It is even interpolation when the value is going to be outwith the current range of values in the coverage.
>>
>> Regards,
>>
>> Andy
>>
>>
>> -----Original Message-----
>> From: [hidden email] on behalf of Jon Blower
>> Sent: Wed 11/06/2008 17:55
>> To: [hidden email]
>> Cc: Andy Turner; [hidden email]
>> Subject: Re: [Geotools-gt2-users] [GeoShaver] Re: [GeoShaver] Re: Status ofCoverages inGeoAPI and GeoTools
>>
>> Ah, interesting.  Just to check I've understood this correctly:
>>
>> 1) A coverage represented internally by a grid (e.g. numerical model
>> output, digital photo or satellite image) is a type of
>> DiscreteCoverage in ISO19123 (perhaps a DiscreteGridPointCoverage)?
>>
>> 2) For a DiscreteCoverage, if I ask for a value at a point that
>> doesn't correspond exactly with a grid point I will get the value from
>> the nearest grid point (i.e. nearest-neighbour interpolation).  Or do
>> I actually get null?
>>
>> 3) However, in GeoTools, the DiscreteCoverages are not implemented.
>> The GridCoverage2D class does not implement ISO19123 interfaces but it
>> is effectively a discrete coverage that performs nearest-neighbour
>> interpolation.
>>
>> 4) If I want bilinear (or bicubic or anything else) interpolation then
>> I need to take my GridCoverage2D and somehow convert it to an
>> Interpolator2D.  How do I do this?
>>
>> Another question: Is it possible to have different interpolation
>> methods in different directions (e.g. nearest-neighbour in the
>> horizontal, linear in the vertical)?
>>
>> Cheers, Jon
>>
>> On Wed, Jun 11, 2008 at 4:20 PM, Martin Desruisseaux
>> <[hidden email]> wrote:
>>>
>>> Andy Turner a écrit :
>>>> I think a continuous coverage is one where for any location a value is obtained by interpolation and that for a discrete coverage the value at any point is known directly. (The distinction, continuous or discrete is nothing to do with the values attributed to the coverage.)
>>>
>>> Yes it is also my understanding. It GeoTools implementation, GridCoverage2D
>>> (without subclassing) would be a discrete coverage (minus tricky boundary issues
>>> like the ones you mentioned) while Interpolator2D would be a continuous
>>> coverage. But at this time GeoTools does not implement ISO interfaces that way.
>>> However this is something we would like to do in the future.
>>>
>>>        Martin
>>>
>>> --~--~---------~--~----~------------~-------~--~----~
>>> You received this message because you are subscribed to the Google Groups "GeoShaver" group.
>>>  To post to this group, send email to [hidden email]
>>>  To unsubscribe from this group, send email to [hidden email]
>>>  For more options, visit this group at http://groups.google.co.uk/group/geoshaver?hl=en-GB
>>> -~----------~----~----~----~------~----~------~--~---
>>>
>>>
>>
>>
>>
>> --
>> --------------------------------------------------------------
>> Dr Jon Blower              Tel: +44 118 378 5213 (direct line)
>> Technical Director         Tel: +44 118 378 8741 (ESSC)
>> Reading e-Science Centre   Fax: +44 118 378 6413
>> ESSC                       Email: [hidden email]
>> University of Reading
>> 3 Earley Gate
>> Reading RG6 6AL, UK
>> --------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>>
>>
>
>
>
> --
> --------------------------------------------------------------
> Dr Jon Blower Tel: +44 118 378 5213 (direct line)
> Technical Director Tel: +44 118 378 8741 (ESSC)
> Reading e-Science Centre Fax: +44 118 378 6413
> ESSC Email: [hidden email]
> University of Reading
> 3 Earley Gate
> Reading RG6 6AL, UK
> --------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>



--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928


http://www.geo-solutions.it

-------------------------------------------------------

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Reply | Threaded
Open this post in threaded view
|

Re: [GeoShaver] Re: [GeoShaver] Re: Status ofCoverages inGeoAPI and GeoTools

Adrian Custer
In reply to this post by Jon Blower
On Fri, 2008-06-13 at 12:27 +0100, Jon Blower wrote:

> Hi Michael,
>
> Thanks very much for this.
>
> > My naive 2p / 2c worth is that the domain of a coverage is simply that
> > region within which data are defined.
>
> I like this definition because I understand it!  However, I'm not sure
> that everyone has the same view.  I think the $64000 question is: does
> the domain for a single coverage have to be contiguous?  If so, this
> would seem to rule out the use of a Coverage for a discretely-sampled
> domain in which you don't want to apply interpolation of any kind.

No, a coverage domain does not need to be continuous. A coverage, in its
most abstract, is merely:

                         some set of direct positions
                            for all of which we have
                               a set of values.
       
The set of direct positions may be finite (i.e. a random or regular
group of points) or infinite (i.e. a set of polygons, a mix of points,
lines and polygons). The values can be of any kind of measure: nominal,
ordinal, interval, or ratio and can also be a vector of, possibly mixed,
values. The coverage is however *required* to have a value for each
position in the original set. The key for the discrete/continuous will
be how the values are generated.

An example of a discrete coverage might be "countryNameCoverage". The
domain of such a coverage could be the set of polygons of territories
claimed to be occupied by some nation state (i.e. in today's world, all
the land masses.) For our purposes let's call this a set of mostly
non-overlapping polygons. The coverage, by its construction, guaranttees
that for any point within those polygons we can get a "name" for a
country. So if we give it a point in Boston we get 'USA', if we give it
a point in the mississippi we get 'USA' but if we give it a point in the
Amazon, we could get 'Brazil'. The coverage can define rules about how
it resolves disputed areas like land in Antarctica. So this is
'discrete' in that we get the same result wherever we are within a
polygon---any point we ask for within the alaska polygon will always
give us 'USA'.

An example of a continous coverage, based on the same polygons, could be
"populationDensityCoverage". There, our two queries in the alaska
polygon could return completely different values and indeed, in general,
we expect different points to have different values even within the same
polygon.

Do not confuse continuous coverage with the continuity of the values
however. We could have a third coverage using the same polygons which is
"sexOfclosestHumanCoverage" which would return 'female' 'unknown' 'male'
for any position in the polygons. Again every point in Alaska would have
an answer but that answer would be different for different places in
Alaska so the coverage is continuous although the values are not.

An 'image' can be turned into a coverage in several ways although a
common one will be to characterize the domain as a single, continuous
rectangular block everywhere over which the coverage can return a vector
of values, say one value for each of the image bands. The return vector
would vary with position across the single domain so this would be a
continuous construction. Alternatively, we could define an 'image' as a
multi-domain discrete coverage where the domain is a set of equally
sized polygons arranged side-by-side and the value returned is the same
for each position within each polygon. Note in passing that we are not
talking about how the values are generated---that's a detail of the
internals of the coverage.

In many ways coverages are the end goal of GI Systems so they are rich
and complex. Also, Geotools has for a long time mixed up the notion of
GridCoverage with the notion of Coverage causing some confusion.

For details of the construction of these things, please look at the spec
itself.

Also, you should all be aware there's a big doc written by Bryce trying
to play with these notions. He's good at giving a 'read' of the specs he
looks at so one can compare one's own understanding to someone else's
(ie. his) as one reads. See
  http://docs.codehaus.org/display/GEOTOOLS/
                                    ISO+19123+progress+and+future+plan
(rebuild the link)
for details.

Hope that helps---it's hard territory.

--adrian



>
> If domains are allowed to be non-contiguous then this complicates
> things somewhat but not impossibly so.
>
> I think this has revealed a problem with terminology.  It seems that
> GeoAPI/Tools interprets a DiscreteCoverage to be a
> discretely-*sampled* coverage, which is nevertheless conceptually a
> contiguous region (with the gaps filled in by nearest-neighbour
> interpolation).  A ContinuousCoverage might also be discretely sampled
> but the gaps are filled by some other interpolation method.  I don't
> think this is a very obvious use of the terms.
>
> By contrast, I believe that the Climate Science Modelling Language (a
> GML Application Schema) regards a DiscreteCoverage to be
> non-contiguous, i.e. the domain consists of a number of sub-domains
> that do not touch or intersect.  Andrew Woolf or Dom Lowe would be
> able to confirm whether my interpretation is correct here.
>
> For the record the CSML interpretation is more obvious to me.  The
> GeoAPI/Tools interpretation differentiates on the basis of
> interpolation method, which I do not find very satisfactory.
>
> But I haven't read the ISO specs - I'm hoping that someone else will
> do that! ;-)
>
> Cheers, Jon
>
> P.S. I know this conversation has become a bit fragmented.  I'll try
> to find time to type this up on a web page or something.
>
> On Fri, Jun 13, 2008 at 9:29 AM, Michael Bedward
> <[hidden email]> wrote:
> > 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
>


-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users