[Geoserver-devel] Feedback and ideas for overviews selection in raster data

GeoServer GeoServer Developer
1

Dear All,
I have been discussing a little with aaime and daniele these days
about better ways to pick overviews in gridcoverage upon a read
request.

The assumption is that I am provided with the following:

- bbox + crs
- grid-to-world transform
- image range (minx,miny,w,h)

and I needed to do all the needed magic like, crop, select overview,
decimate, resample, etc...

Now, we have roughly identified 3 situations:

1> the coverage native CRS and the request crs are similar, i.e. no
reprojection is needed between them
2> the coverage native CRS and the request crs are NOT similar, i.e. a
reprojection is needed between them, and the requested envelope can be
reprojected to the coverage native CRS
3> the coverage native CRS and the request crs are similar, i.e. a
reprojection is needed between them, and the requested envelope can
NOT be reprojected to the coverage native CRS (this usually happens
when going from project to geo or the other way around).

Case 1 can be handled with no problems relying on the gridtoworld
transform of the request.
For 2 and 3 i would like to hear opinions from other people about how
to select the best overviews taking into account reprojection between
the two spaces. My thoughts are:

- In the past, especially for 2 I was reprojecting the requested
envelope to the coverage CRS for computing the needed stuff for doing
a read. However this implies doing an implicit reprojection on the
requested grid geometry imposing that the raster range stay unchanged.
Therefore this may lead to a degradation of the resolution for the
request and to the selection of an overviews at a resolution lower
than needed. This is not good since in the end we need to reproject
again, therefore we might have raster data at a quality lower than
expected.
- I am pretty sure we can merge 2 and 3 into a single case
- which assumption you'd expect for overviews? Many software have
great limitation (constant aspect ratio, constant scale factor==2,
etc..) and so do many important formats (jpeg2000 to mention one).

Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

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

http://www.geo-solutions.it
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

2

Hi Simone:

The assumption is that I am provided with the following:
- bbox + crs
- grid-to-world transform
- image range (minx,miny,w,h)

I do not follow why are all three are here; it appears to me that you
could determine the image range based on the grid-to-world transform
and the bbox+crs?

2> the coverage native CRS and the request crs are NOT similar, i.e. a
reprojection is needed between them, and the requested envelope can be
reprojected to the coverage native CRS

Okay.

3> the coverage native CRS and the request crs are similar, i.e. a
reprojection is needed between them, and the requested envelope can
NOT be reprojected to the coverage native CRS (this usually happens
when going from project to geo or the other way around).

Is this where one of the "edges" of the reprojected request envelope
falls outside of the image; or outside of the valid area of the
coordinate reference system?

- In the past, especially for 2 I was reprojecting the requested
envelope to the coverage CRS for computing the needed stuff for doing
a read. However this implies doing an implicit reprojection on the
requested grid geometry imposing that the raster range stay unchanged.
Therefore this may lead to a degradation of the resolution for the
request and to the selection of an overviews at a resolution lower
than needed. This is not good since in the end we need to reproject
again, therefore we might have raster data at a quality lower than
expected.

I am imagining the target grid transformed into the image crs; forming
lots of little trapezoid(or stranger) shapes. I think you could
account for this with a little bit of math; taking the shortest
horizontal distance / vertical distance produced by the transformed
grid; and using that to select out the appropriate level of details.

- I am pretty sure we can merge 2 and 3 into a single case
- which assumption you'd expect for overviews? Many software have
great limitation (constant aspect ratio, constant scale factor==2,
etc..) and so do many important formats (jpeg2000 to mention one).

I would expect to choose the overview that prevents the same source
pixel being sampled twice for display.

Jody

3

Ciao Jody,
please see below...

-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

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

http://www.geo-solutions.it
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

On Fri, Apr 10, 2009 at 11:17 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hi Simone:

The assumption is that I am provided with the following:
- bbox + crs
- grid-to-world transform
- image range (minx,miny,w,h)

I do not follow why are all three are here; it appears to me that you
could determine the image range based on the grid-to-world transform
and the bbox+crs?

Correct, but I am carrying around this info using a GridGeometry2D
hence I have the all 3 anyway :-).

2> the coverage native CRS and the request crs are NOT similar, i.e. a
reprojection is needed between them, and the requested envelope can be
reprojected to the coverage native CRS

Okay.

3> the coverage native CRS and the request crs are similar, i.e. a
reprojection is needed between them, and the requested envelope can
NOT be reprojected to the coverage native CRS (this usually happens
when going from project to geo or the other way around).

Is this where one of the "edges" of the reprojected request envelope
falls outside of the image; or outside of the valid area of the
coordinate reference system?

y

- In the past, especially for 2 I was reprojecting the requested
envelope to the coverage CRS for computing the needed stuff for doing
a read. However this implies doing an implicit reprojection on the
requested grid geometry imposing that the raster range stay unchanged.
Therefore this may lead to a degradation of the resolution for the
request and to the selection of an overviews at a resolution lower
than needed. This is not good since in the end we need to reproject
again, therefore we might have raster data at a quality lower than
expected.

I am imagining the target grid transformed into the image crs; forming
lots of little trapezoid(or stranger) shapes. I think you could
account for this with a little bit of math; taking the shortest
horizontal distance / vertical distance produced by the transformed
grid; and using that to select out the appropriate level of details.

- I am pretty sure we can merge 2 and 3 into a single case
- which assumption you'd expect for overviews? Many software have
great limitation (constant aspect ratio, constant scale factor==2,
etc..) and so do many important formats (jpeg2000 to mention one).

I would expect to choose the overview that prevents the same source
pixel being sampled twice for display.

I am not sure I have fully understood your suggestions, however, to
clarify, what I am looking for area ideas about how to compute the
scale factor(s?) of a request for WMS/WCS in a generic way that can be
portable between different CRS. So that I can use it to select
overviews. Feedback on how people would expect us to select overviews
are welcome as well.

Simone.

Jody

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

4

Simone, If your are attacking this CRS stuff, could you please make a design offering an API for CRS conversions of envelopes and images.

The imagemosaic-jdbc module does also CRS conversions for the requested envelopes and returned images, but I would not swear on it. (I did my best, but I am not a CRS expert).

I would be happy to use your code for these situations since you have more experience.

christian

Simone Giannecchini writes:

Ciao Jody,
please see below...

-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

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

http://www.geo-solutions.it
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

On Fri, Apr 10, 2009 at 11:17 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hi Simone:

The assumption is that I am provided with the following:
- bbox + crs
- grid-to-world transform
- image range (minx,miny,w,h)

I do not follow why are all three are here; it appears to me that you
could determine the image range based on the grid-to-world transform
and the bbox+crs?

Correct, but I am carrying around this info using a GridGeometry2D
hence I have the all 3 anyway :-).

2> the coverage native CRS and the request crs are NOT similar, i.e. a
reprojection is needed between them, and the requested envelope can be
reprojected to the coverage native CRS

Okay.

3> the coverage native CRS and the request crs are similar, i.e. a
reprojection is needed between them, and the requested envelope can
NOT be reprojected to the coverage native CRS (this usually happens
when going from project to geo or the other way around).

Is this where one of the "edges" of the reprojected request envelope
falls outside of the image; or outside of the valid area of the
coordinate reference system?

y

- In the past, especially for 2 I was reprojecting the requested
envelope to the coverage CRS for computing the needed stuff for doing
a read. However this implies doing an implicit reprojection on the
requested grid geometry imposing that the raster range stay unchanged.
Therefore this may lead to a degradation of the resolution for the
request and to the selection of an overviews at a resolution lower
than needed. This is not good since in the end we need to reproject
again, therefore we might have raster data at a quality lower than
expected.

I am imagining the target grid transformed into the image crs; forming
lots of little trapezoid(or stranger) shapes. I think you could
account for this with a little bit of math; taking the shortest
horizontal distance / vertical distance produced by the transformed
grid; and using that to select out the appropriate level of details.

- I am pretty sure we can merge 2 and 3 into a single case
- which assumption you'd expect for overviews? Many software have
great limitation (constant aspect ratio, constant scale factor==2,
etc..) and so do many important formats (jpeg2000 to mention one).

I would expect to choose the overview that prevents the same source
pixel being sampled twice for display.

I am not sure I have fully understood your suggestions, however, to
clarify, what I am looking for area ideas about how to compute the
scale factor(s?) of a request for WMS/WCS in a generic way that can be
portable between different CRS. So that I can use it to select
overviews. Feedback on how people would expect us to select overviews
are welcome as well.

Simone.

Jody

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

5

Christian Müller a écrit :

Simone, If your are attacking this CRS stuff, could you please make a design offering an API for CRS conversions of envelopes and images.

For the transformation of envelopes, there is this method:

http://javadoc.geotools.fr/snapshot/org/geotools/referencing/CRS.html#transform(org.opengis.geometry.Envelope,%20org.opengis.referencing.crs.CoordinateReferenceSystem)

This is not a trivial task if we want to take in account the case when the envelope encompasses a pole, as you can see if you look at the code.

http://hg.geomatys.com/geotidy/file/a9b57f73b998/modules/referencing/gt-referencing/src/main/java/org/geotools/referencing/CRS.java#l1182

Unless you feel courageous, it is probably easier to stick with the above CRS static methods...

  Martin

6

There is a JTS utility method for transforming envelopes; and
ReferencedEnvelope also has this functionality. However Simone's
question is more focused; on selecting out the correct overlay given
the need to fill in a target raster.

Simone if you can consider the attached "diagram" (yes I did not even
try ascii art). It shows the raster in col/row space along with its
overlay in col/row space. The strange slice shape is the target
enveloper reprojected down into col/row space representing what we are
going to try and sample.

Towards the outer edge of this shape the samples are going to be less
dense and we can make use of the overlay; towards the inner edge of
this shape they are going to be more dense and we will need to make
use of a greater level of detail.

A couple of questions:
- can you pull from both? Is their a time saving in doing so? Or do
you need to pull from a single overlay...

If you need to pull from a single overlay:
- to be "perfect" you would need to pull from a single overlay you
would need to go for the more detailed one here
- to be "fast" you could consider setting a threadshold and choose
which overlay to use based on the on a % of the result that would be
appear stretched
- or to be "fast" you could consider a choice of overlay based what is
going on in the "center" of the target envelope? This would look bad
for tiled solutions

My earlier comment was based on figuring out the minimum horizontal /
vertical delta between the samples in col/row space and figuring out
which overlay to choose based on that.

Jody

On Sat, Apr 11, 2009 at 3:39 AM, Christian Müller
<christian.mueller@anonymised.com> wrote:

Simone, If your are attacking this CRS stuff, could you please make a design
offering an API for CRS conversions of envelopes and images.
The imagemosaic-jdbc module does also CRS conversions for the requested
envelopes and returned images, but I would not swear on it. (I did my best,
but I am not a CRS expert).
I would be happy to use your code for these situations since you have more
experience.
christian

Simone Giannecchini writes:

Ciao Jody,
please see below...
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
-------------------------------------------------------

On Fri, Apr 10, 2009 at 11:17 AM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Hi Simone:

The assumption is that I am provided with the following:
- bbox + crs
- grid-to-world transform
- image range (minx,miny,w,h)

I do not follow why are all three are here; it appears to me that you
could determine the image range based on the grid-to-world transform
and the bbox+crs?

Correct, but I am carrying around this info using a GridGeometry2D
hence I have the all 3 anyway :-).

2> the coverage native CRS and the request crs are NOT similar, i.e. a
reprojection is needed between them, and the requested envelope can be
reprojected to the coverage native CRS

Okay.

3> the coverage native CRS and the request crs are similar, i.e. a
reprojection is needed between them, and the requested envelope can
NOT be reprojected to the coverage native CRS (this usually happens
when going from project to geo or the other way around).

Is this where one of the "edges" of the reprojected request envelope
falls outside of the image; or outside of the valid area of the
coordinate reference system?

y

- In the past, especially for 2 I was reprojecting the requested
envelope to the coverage CRS for computing the needed stuff for doing
a read. However this implies doing an implicit reprojection on the
requested grid geometry imposing that the raster range stay unchanged.
Therefore this may lead to a degradation of the resolution for the
request and to the selection of an overviews at a resolution lower
than needed. This is not good since in the end we need to reproject
again, therefore we might have raster data at a quality lower than
expected.

I am imagining the target grid transformed into the image crs; forming
lots of little trapezoid(or stranger) shapes. I think you could
account for this with a little bit of math; taking the shortest
horizontal distance / vertical distance produced by the transformed
grid; and using that to select out the appropriate level of details.

- I am pretty sure we can merge 2 and 3 into a single case
- which assumption you'd expect for overviews? Many software have
great limitation (constant aspect ratio, constant scale factor==2,
etc..) and so do many important formats (jpeg2000 to mention one).

I would expect to choose the overview that prevents the same source
pixel being sampled twice for display.

I am not sure I have fully understood your suggestions, however, to
clarify, what I am looking for area ideas about how to compute the
scale factor(s?) of a request for WMS/WCS in a generic way that can be
portable between different CRS. So that I can use it to select
overviews. Feedback on how people would expect us to select overviews
are welcome as well.
Simone.

Jody

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

(attachments)

overlay_selection.jpg