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 <[email protected]> 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 <[email protected]> >> 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 >>> [email protected] >>> 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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > >
<<attachment: overlay_selection.jpg>>
------------------------------------------------------------------------------ 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
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
