[Geoserver-devel] WCS limits patch ready

Hi,
I've just attached a patch that add wcs limits, as described
in a previous mail on this list, to
http://jira.codehaus.org/browse/GEOS-3856

The patch adds the limits to both WCS 1.0 and WCS 1.1, along
with a couple of simple tests, and exposes the two new configurable
items, max input memory, max output memory, in the WCS configuration
page. It still misses changes to the sphix docs, but I'm going to
add them.

Most of the magic is performed in the WCSUtils class (so that it
can be shared among the two WCS implementations).
If you look at the code you'll see there are two input checks
and one output one.
The first input check tries to guess how much data will be
read without actually reading it. It is not that easy as we
have no definitive info about how big a coverage cell is
until we read it, so I had to try and guess that information
from the "coverage dimension" range, which normally has a 1-1
association with the actual storage type (e.g., for byte storage
the range will be 0..255 and so on).
We jump through those hoops basically because once the
coverage has been read trying to access its size or its
sample model will trigger the JAI reading chain, and that
will actually load the data in memory.
If the source is tiled no problem, but if it's not and we're
reading a lot of data, boom, we get exactly the kind of situation
we want to avoid with the limits.

Then there is a second check, just to make sure, after the
coverage is read, based on actual with/height and per band
size.

Then, just before generating the final output coverage, a final
test is made against the output, which can be smaller or larger
depending on other factors like supersampling and band selection.

Well, let me know if the patch looks ok, looking forward to commit
it to both trunk and 2.0.x, as it does not roll new API and makes
WCS production proof (or at least, more production proof).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Patch looks good to me. But of course i am a novice when it comes to coverages and wcs. But +1 nonetheless.

-Justin

On Thu, Sep 23, 2010 at 10:37 AM, Andrea Aime <aaime@anonymised.com> wrote:

Hi,
I’ve just attached a patch that add wcs limits, as described
in a previous mail on this list, to
http://jira.codehaus.org/browse/GEOS-3856

The patch adds the limits to both WCS 1.0 and WCS 1.1, along
with a couple of simple tests, and exposes the two new configurable
items, max input memory, max output memory, in the WCS configuration
page. It still misses changes to the sphix docs, but I’m going to
add them.

Most of the magic is performed in the WCSUtils class (so that it
can be shared among the two WCS implementations).
If you look at the code you’ll see there are two input checks
and one output one.
The first input check tries to guess how much data will be
read without actually reading it. It is not that easy as we
have no definitive info about how big a coverage cell is
until we read it, so I had to try and guess that information
from the “coverage dimension” range, which normally has a 1-1
association with the actual storage type (e.g., for byte storage
the range will be 0…255 and so on).
We jump through those hoops basically because once the
coverage has been read trying to access its size or its
sample model will trigger the JAI reading chain, and that
will actually load the data in memory.
If the source is tiled no problem, but if it’s not and we’re
reading a lot of data, boom, we get exactly the kind of situation
we want to avoid with the limits.

Then there is a second check, just to make sure, after the
coverage is read, based on actual with/height and per band
size.

Then, just before generating the final output coverage, a final
test is made against the output, which can be smaller or larger
depending on other factors like supersampling and band selection.

Well, let me know if the patch looks ok, looking forward to commit
it to both trunk and 2.0.x, as it does not roll new API and makes
WCS production proof (or at least, more production proof).

Cheers
Andrea


Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.


Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.