[Geoserver-devel] Raster reprojection

GeoServer GeoServer Developer
1

Hey geoserver raster gurus,

I'm about to dive into the code and figure out the answer myself, but I'm curious what the planned behavior for raster reprojection on 1.6.x is.

Right now I'm debugging in the ArcSDE raster code, and when I ask for a raster in EPSG:4326, I'm getting exactly that CRS and bounding box passed into my GridCoverageReader.read() method.

Is that the expected behavior? I.e., is each gridcoveragereader expected to handle reprojection internally? Somehow I thought that the requests would always be made in the native CRS of the raster data, and then 'warped' or 'reprojected' to fit the queried bbox.

Am I way off on that one?

thanks much!
--saul

2

Ciao Saul,
I am not sure I am included in the raster "gurus" dataset but since no one
else is answering I will try a best effort approach to serve your query.
(Yeah, I am tired and I need a vacation :-().

The behaviour I tried to implement in most readers was the following. If
someone is making a request to get part or all of a coverage I pass this
request to the coverage reader untouched then it is up to the reader to
ignore it or to make use of it.

What I usually do is reprojecting the envelope back to the coverage native
CRS and then intersect it with the original envelope in order to decide
whether or not the request will be satisfied.
A whole set of optimizations (that should be improved sometime in the
future) can be used, overviews management, decimation on reading, cropping,
etc. All of the require the reprojection of the requested envelope into the
native coverage crs.

Hope that helped.
Simone.

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

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

-----Original Message-----
From: geoserver-devel-bounces@lists.sourceforge.net
[mailto:geoserver-devel-bounces@lists.sourceforge.net] On Behalf Of Farber,
Saul (EEA)
Sent: venerdì 3 agosto 2007 1.07
To: geoserver-devel@lists.sourceforge.net
Subject: [Geoserver-devel] Raster reprojection

Hey geoserver raster gurus,

I'm about to dive into the code and figure out the answer myself, but I'm
curious what the planned behavior for raster reprojection on 1.6.x is.

Right now I'm debugging in the ArcSDE raster code, and when I ask for a
raster in EPSG:4326, I'm getting exactly that CRS and bounding box passed
into my GridCoverageReader.read() method.

Is that the expected behavior? I.e., is each gridcoveragereader expected to
handle reprojection internally? Somehow I thought that the requests would
always be made in the native CRS of the raster data, and then 'warped' or
'reprojected' to fit the queried bbox.

Am I way off on that one?

thanks much!
--saul

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Simone Gannecchini ha scritto:

Ciao Saul,
I am not sure I am included in the raster "gurus" dataset but since no one
else is answering I will try a best effort approach to serve your query.
(Yeah, I am tired and I need a vacation :-().

The behaviour I tried to implement in most readers was the following. If
someone is making a request to get part or all of a coverage I pass this
request to the coverage reader untouched then it is up to the reader to
ignore it or to make use of it.

What I usually do is reprojecting the envelope back to the coverage native
CRS and then intersect it with the original envelope in order to decide
whether or not the request will be satisfied. A whole set of optimizations (that should be improved sometime in the
future) can be used, overviews management, decimation on reading, cropping,
etc. All of the require the reprojection of the requested envelope into the
native coverage crs.

Whatever, but most readers do not reproject the data themselves, the
renderer is doing it, no? So, what do you do, you just reproject
the envelope to the native crs of the coverage to perfom the actual
data extraction, and then return the coverage in the native crs?

Cheers
Andrea

4

Ops,
as I said a need a vacation.

I forgot to say that I tried lo leave things as simple as possible. NO
ASSUMPTIONS are made on what you get from a read on a coverage reader
since one would be willing to NOT optimize at all.

This means that, if you are implementing your XXXReader you could do
everything you want up to decimating, cropping, resampling and
reprojectiong or simply do nothing and give the all coverage as it is.
The coverage renderer will (try) to care of it without making any
assumptions on what you could have done on the raster, which means
that It will try to crop, subsample and reproject itself if you have
not done it.

Simone.

On 8/3/07, Andrea Aime <aaime@anonymised.com> wrote:

Simone Gannecchini ha scritto:
> Ciao Saul,
> I am not sure I am included in the raster "gurus" dataset but since no one
> else is answering I will try a best effort approach to serve your query.
> (Yeah, I am tired and I need a vacation :-().
>
> The behaviour I tried to implement in most readers was the following. If
> someone is making a request to get part or all of a coverage I pass this
> request to the coverage reader untouched then it is up to the reader to
> ignore it or to make use of it.
>
> What I usually do is reprojecting the envelope back to the coverage native
> CRS and then intersect it with the original envelope in order to decide
> whether or not the request will be satisfied.
> A whole set of optimizations (that should be improved sometime in the
> future) can be used, overviews management, decimation on reading, cropping,
> etc. All of the require the reprojection of the requested envelope into the
> native coverage crs.

Whatever, but most readers do not reproject the data themselves, the
renderer is doing it, no? So, what do you do, you just reproject
the envelope to the native crs of the coverage to perfom the actual
data extraction, and then return the coverage in the native crs?

Cheers
Andrea

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

phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000

http://www.geo-solutions.it

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

5

Yeah, what andrea asked is what I'm curious about.

So I think this is what happens:

0) Coverage native EPSG is 9999.
1) Request for coverage in 4326 comes in.
2) Request for coverage in 4326 is passed to XXXgcReader
3) XXXgcReader does whatever it can to try and return some relevant data, but returns it in EPSG:9999
4) GridCoverageRenderer reprojects whatever was returned from XXXgcReader (which is in EPSG:9999) into EPSG:4326 by doing cropping, resampling, etc...essentially "reprojection"
5) The reprojected raster is returned to the caller

Is that right? I'm only fuzzy about step 4...should I be doing step 4 INSIDE the XXXgcReader, or will the GridCoverageRenderer handle it on its own?

thanks so much Simone,

--saul

________________________________

From: geoserver-devel-bounces@lists.sourceforge.net on behalf of Andrea Aime
Sent: Fri 8/3/2007 11:06 AM
To: Simone Gannecchini
Cc: geoserver-devel@lists.sourceforge.net; 'Farber, Saul (EEA)'
Subject: Re: [Geoserver-devel] Raster reprojection

Simone Gannecchini ha scritto:

Ciao Saul,
I am not sure I am included in the raster "gurus" dataset but since no one
else is answering I will try a best effort approach to serve your query.
(Yeah, I am tired and I need a vacation :-().

The behaviour I tried to implement in most readers was the following. If
someone is making a request to get part or all of a coverage I pass this
request to the coverage reader untouched then it is up to the reader to
ignore it or to make use of it.

What I usually do is reprojecting the envelope back to the coverage native
CRS and then intersect it with the original envelope in order to decide
whether or not the request will be satisfied.
A whole set of optimizations (that should be improved sometime in the
future) can be used, overviews management, decimation on reading, cropping,
etc. All of the require the reprojection of the requested envelope into the
native coverage crs.

Whatever, but most readers do not reproject the data themselves, the
renderer is doing it, no? So, what do you do, you just reproject
the envelope to the native crs of the coverage to perfom the actual
data extraction, and then return the coverage in the native crs?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

As I said what happens depend on how much the single plugin is implementing.

A plugin could do everything by itself comprehending the reprojection but I
usually do not do that.

Daniele and I are working on a couple of GDAL-based plugins for various
formats (MRSID, JP2 and ECW) which should be a bit more advanced with
respect to the others we have but still we don't do any reprojection.

The way I envision a good plug-in should work is like a best effort
approach, but in the end what I think would be a nice behaviour is the
following:

0) Coverage native EPSG is XXXX.
1) Request for coverage in 4326 comes in.
2) Request for coverage in 4326 is passed to XXXgcReader
3) XXXgcReader reproject the request back to XXXX crs
4) XXXgcReader load only the needed area(crop) at the best resolution
available(decimation or overviews)
5) XXXgcReader build a coverage in crs XXXX with data from 4)
6) GridCoverageRenderer reprojects whatever was returned from XXXgcReader
(which is in EPSG:9999) into EPSG:4326 by doing cropping, resampling,
etc...essentially "reprojection"
7) The reprojected raster is returned to the caller

In a perfect world a plugin should work as follows:

0) Coverage native EPSG is XXXX.
1) Request for coverage in 4326 comes in.
2) Request for coverage in 4326 is passed to XXXgcReader
3) XXXgcReader reproject the request back to XXXX crs
4) XXXgcReader load only the needed area(crop) at the best resolution
available(decimation or overviews)
5) XXXgcReader build a coverage in crs XXXX with data from 4)
6) XXXgcReader scale the coverage from 5)at the resolution requested and
to fit the view extent requested (in pixels)
7) XXXgcReader reproject coverage in crs 436 with data from 6)

8) GridCoverageRenderer reprojects simply apply the grid-to-world transform
to place the coverage at the right place on the final graphics.

9) The reprojected raster is returned to the caller

As everybody knows we don't live in a perfect world, doing all steps from 0
to 9 could add to complexity to the single plugins, but it would be feasible
moving some functionality up in the grdicoverage hierarchy. Actually if
someone has money to spend on this I would be glad to work on it :-).

Simone.

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

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

-----Original Message-----
From: Farber, Saul (EEA) [mailto:Saul.Farber@anonymised.com]
Sent: venerdì 3 agosto 2007 17.24
To: Andrea Aime; Simone Gannecchini
Cc: geoserver-devel@lists.sourceforge.net
Subject: RE: [Geoserver-devel] Raster reprojection

Yeah, what andrea asked is what I'm curious about.

So I think this is what happens:

0) Coverage native EPSG is 9999.
1) Request for coverage in 4326 comes in.
2) Request for coverage in 4326 is passed to XXXgcReader
3) XXXgcReader does whatever it can to try and return some relevant data,
but returns it in EPSG:9999
4) GridCoverageRenderer reprojects whatever was returned from XXXgcReader
(which is in EPSG:9999) into EPSG:4326 by doing cropping, resampling,
etc...essentially "reprojection"
5) The reprojected raster is returned to the caller

Is that right? I'm only fuzzy about step 4...should I be doing step 4
INSIDE the XXXgcReader, or will the GridCoverageRenderer handle it on its
own?

thanks so much Simone,

--saul

________________________________

From: geoserver-devel-bounces@lists.sourceforge.net on behalf of Andrea Aime
Sent: Fri 8/3/2007 11:06 AM
To: Simone Gannecchini
Cc: geoserver-devel@lists.sourceforge.net; 'Farber, Saul (EEA)'
Subject: Re: [Geoserver-devel] Raster reprojection

Simone Gannecchini ha scritto:

Ciao Saul,
I am not sure I am included in the raster "gurus" dataset but since no

one

else is answering I will try a best effort approach to serve your query.
(Yeah, I am tired and I need a vacation :-().

The behaviour I tried to implement in most readers was the following. If
someone is making a request to get part or all of a coverage I pass this
request to the coverage reader untouched then it is up to the reader to
ignore it or to make use of it.

What I usually do is reprojecting the envelope back to the coverage native
CRS and then intersect it with the original envelope in order to decide
whether or not the request will be satisfied.
A whole set of optimizations (that should be improved sometime in the
future) can be used, overviews management, decimation on reading,

cropping,

etc. All of the require the reprojection of the requested envelope into

the

native coverage crs.

Whatever, but most readers do not reproject the data themselves, the
renderer is doing it, no? So, what do you do, you just reproject
the envelope to the native crs of the coverage to perfom the actual
data extraction, and then return the coverage in the native crs?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

7

Simone,

Great explanation. That makes much sense.

The flow you explain below (the first one...the 'real world' one, rather than the 'perfect world one')...does that exist today? If my XXXgcReader plugin returns a mis-sized, untranslated coverage, will GCRenderer reproject it for me?

I'm fairly sure that it will...I just wanted to double check!

--saul

________________________________

From: Simone Gannecchini [mailto:simboss1@anonymised.com]
Sent: Fri 8/3/2007 12:19 PM
To: 'Farber, Saul (EEA)'; 'Andrea Aime'
Cc: geoserver-devel@lists.sourceforge.net
Subject: RE: [Geoserver-devel] Raster reprojection

As I said what happens depend on how much the single plugin is implementing.

A plugin could do everything by itself comprehending the reprojection but I
usually do not do that.

Daniele and I are working on a couple of GDAL-based plugins for various
formats (MRSID, JP2 and ECW) which should be a bit more advanced with
respect to the others we have but still we don't do any reprojection.

The way I envision a good plug-in should work is like a best effort
approach, but in the end what I think would be a nice behaviour is the
following:

0) Coverage native EPSG is XXXX.
1) Request for coverage in 4326 comes in.
2) Request for coverage in 4326 is passed to XXXgcReader
3) XXXgcReader reproject the request back to XXXX crs
4) XXXgcReader load only the needed area(crop) at the best resolution
available(decimation or overviews)
5) XXXgcReader build a coverage in crs XXXX with data from 4)
6) GridCoverageRenderer reprojects whatever was returned from XXXgcReader
(which is in EPSG:9999) into EPSG:4326 by doing cropping, resampling,
etc...essentially "reprojection"
7) The reprojected raster is returned to the caller

In a perfect world a plugin should work as follows:

0) Coverage native EPSG is XXXX.
1) Request for coverage in 4326 comes in.
2) Request for coverage in 4326 is passed to XXXgcReader
3) XXXgcReader reproject the request back to XXXX crs
4) XXXgcReader load only the needed area(crop) at the best resolution
available(decimation or overviews)
5) XXXgcReader build a coverage in crs XXXX with data from 4)
6) XXXgcReader scale the coverage from 5)at the resolution requested and
to fit the view extent requested (in pixels)
7) XXXgcReader reproject coverage in crs 436 with data from 6)

8) GridCoverageRenderer reprojects simply apply the grid-to-world transform
to place the coverage at the right place on the final graphics.

9) The reprojected raster is returned to the caller

As everybody knows we don't live in a perfect world, doing all steps from 0
to 9 could add to complexity to the single plugins, but it would be feasible
moving some functionality up in the grdicoverage hierarchy. Actually if
someone has money to spend on this I would be glad to work on it :-).

Simone.

-------------------------------------------------------
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/&gt;

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

-----Original Message-----
From: Farber, Saul (EEA) [mailto:Saul.Farber@anonymised.com]
Sent: venerdì 3 agosto 2007 17.24
To: Andrea Aime; Simone Gannecchini
Cc: geoserver-devel@lists.sourceforge.net
Subject: RE: [Geoserver-devel] Raster reprojection

Yeah, what andrea asked is what I'm curious about.

So I think this is what happens:

0) Coverage native EPSG is 9999.
1) Request for coverage in 4326 comes in.
2) Request for coverage in 4326 is passed to XXXgcReader
3) XXXgcReader does whatever it can to try and return some relevant data,
but returns it in EPSG:9999
4) GridCoverageRenderer reprojects whatever was returned from XXXgcReader
(which is in EPSG:9999) into EPSG:4326 by doing cropping, resampling,
etc...essentially "reprojection"
5) The reprojected raster is returned to the caller

Is that right? I'm only fuzzy about step 4...should I be doing step 4
INSIDE the XXXgcReader, or will the GridCoverageRenderer handle it on its
own?

thanks so much Simone,

--saul

________________________________

From: geoserver-devel-bounces@lists.sourceforge.net on behalf of Andrea Aime
Sent: Fri 8/3/2007 11:06 AM
To: Simone Gannecchini
Cc: geoserver-devel@lists.sourceforge.net; 'Farber, Saul (EEA)'
Subject: Re: [Geoserver-devel] Raster reprojection

Simone Gannecchini ha scritto:

Ciao Saul,
I am not sure I am included in the raster "gurus" dataset but since no

one

else is answering I will try a best effort approach to serve your query.
(Yeah, I am tired and I need a vacation :-().

The behaviour I tried to implement in most readers was the following. If
someone is making a request to get part or all of a coverage I pass this
request to the coverage reader untouched then it is up to the reader to
ignore it or to make use of it.

What I usually do is reprojecting the envelope back to the coverage native
CRS and then intersect it with the original envelope in order to decide
whether or not the request will be satisfied.
A whole set of optimizations (that should be improved sometime in the
future) can be used, overviews management, decimation on reading,

cropping,

etc. All of the require the reprojection of the requested envelope into

the

native coverage crs.

Whatever, but most readers do not reproject the data themselves, the
renderer is doing it, no? So, what do you do, you just reproject
the envelope to the native crs of the coverage to perfom the actual
data extraction, and then return the coverage in the native crs?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

8

The GCRenderer will (or at least should :-)) handle it.

Be aware that the performance could be bad, try to at least do some
decimation on loading.

Simone.

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

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

-----Original Message-----
From: Farber, Saul (EEA) [mailto:Saul.Farber@anonymised.com]
Sent: venerdì 3 agosto 2007 18.43
To: Simone Gannecchini; Farber, Saul (EEA); Andrea Aime
Cc: geoserver-devel@lists.sourceforge.net
Subject: RE: [Geoserver-devel] Raster reprojection

Simone,

Great explanation. That makes much sense.

The flow you explain below (the first one...the 'real world' one, rather
than the 'perfect world one')...does that exist today? If my XXXgcReader
plugin returns a mis-sized, untranslated coverage, will GCRenderer reproject
it for me?

I'm fairly sure that it will...I just wanted to double check!

--saul

________________________________

From: Simone Gannecchini [mailto:simboss1@anonymised.com]
Sent: Fri 8/3/2007 12:19 PM
To: 'Farber, Saul (EEA)'; 'Andrea Aime'
Cc: geoserver-devel@lists.sourceforge.net
Subject: RE: [Geoserver-devel] Raster reprojection

As I said what happens depend on how much the single plugin is implementing.

A plugin could do everything by itself comprehending the reprojection but I
usually do not do that.

Daniele and I are working on a couple of GDAL-based plugins for various
formats (MRSID, JP2 and ECW) which should be a bit more advanced with
respect to the others we have but still we don't do any reprojection.

The way I envision a good plug-in should work is like a best effort
approach, but in the end what I think would be a nice behaviour is the
following:

0) Coverage native EPSG is XXXX.
1) Request for coverage in 4326 comes in.
2) Request for coverage in 4326 is passed to XXXgcReader
3) XXXgcReader reproject the request back to XXXX crs
4) XXXgcReader load only the needed area(crop) at the best resolution
available(decimation or overviews)
5) XXXgcReader build a coverage in crs XXXX with data from 4)
6) GridCoverageRenderer reprojects whatever was returned from XXXgcReader
(which is in EPSG:9999) into EPSG:4326 by doing cropping, resampling,
etc...essentially "reprojection"
7) The reprojected raster is returned to the caller

In a perfect world a plugin should work as follows:

0) Coverage native EPSG is XXXX.
1) Request for coverage in 4326 comes in.
2) Request for coverage in 4326 is passed to XXXgcReader
3) XXXgcReader reproject the request back to XXXX crs
4) XXXgcReader load only the needed area(crop) at the best resolution
available(decimation or overviews)
5) XXXgcReader build a coverage in crs XXXX with data from 4)
6) XXXgcReader scale the coverage from 5)at the resolution requested and
to fit the view extent requested (in pixels)
7) XXXgcReader reproject coverage in crs 436 with data from 6)

8) GridCoverageRenderer reprojects simply apply the grid-to-world transform
to place the coverage at the right place on the final graphics.

9) The reprojected raster is returned to the caller

As everybody knows we don't live in a perfect world, doing all steps from 0
to 9 could add to complexity to the single plugins, but it would be feasible
moving some functionality up in the grdicoverage hierarchy. Actually if
someone has money to spend on this I would be glad to work on it :-).

Simone.

-------------------------------------------------------
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/&gt;

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

-----Original Message-----
From: Farber, Saul (EEA) [mailto:Saul.Farber@anonymised.com]
Sent: venerdì 3 agosto 2007 17.24
To: Andrea Aime; Simone Gannecchini
Cc: geoserver-devel@lists.sourceforge.net
Subject: RE: [Geoserver-devel] Raster reprojection

Yeah, what andrea asked is what I'm curious about.

So I think this is what happens:

0) Coverage native EPSG is 9999.
1) Request for coverage in 4326 comes in.
2) Request for coverage in 4326 is passed to XXXgcReader
3) XXXgcReader does whatever it can to try and return some relevant data,
but returns it in EPSG:9999
4) GridCoverageRenderer reprojects whatever was returned from XXXgcReader
(which is in EPSG:9999) into EPSG:4326 by doing cropping, resampling,
etc...essentially "reprojection"
5) The reprojected raster is returned to the caller

Is that right? I'm only fuzzy about step 4...should I be doing step 4
INSIDE the XXXgcReader, or will the GridCoverageRenderer handle it on its
own?

thanks so much Simone,

--saul

________________________________

From: geoserver-devel-bounces@lists.sourceforge.net on behalf of Andrea Aime
Sent: Fri 8/3/2007 11:06 AM
To: Simone Gannecchini
Cc: geoserver-devel@lists.sourceforge.net; 'Farber, Saul (EEA)'
Subject: Re: [Geoserver-devel] Raster reprojection

Simone Gannecchini ha scritto:

Ciao Saul,
I am not sure I am included in the raster "gurus" dataset but since no

one

else is answering I will try a best effort approach to serve your query.
(Yeah, I am tired and I need a vacation :-().

The behaviour I tried to implement in most readers was the following. If
someone is making a request to get part or all of a coverage I pass this
request to the coverage reader untouched then it is up to the reader to
ignore it or to make use of it.

What I usually do is reprojecting the envelope back to the coverage native
CRS and then intersect it with the original envelope in order to decide
whether or not the request will be satisfied.
A whole set of optimizations (that should be improved sometime in the
future) can be used, overviews management, decimation on reading,

cropping,

etc. All of the require the reprojection of the requested envelope into

the

native coverage crs.

Whatever, but most readers do not reproject the data themselves, the
renderer is doing it, no? So, what do you do, you just reproject
the envelope to the native crs of the coverage to perfom the actual
data extraction, and then return the coverage in the native crs?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel