This is a nice nice problem, I am not a coverage expert but I would like to talk about it. I would prefer an IRC meeting. What about right now?
Andrea On Sat, Apr 12, 2008 at 3:03 PM, Andrea Aime <[EMAIL PROTECTED]> wrote: > Hi, > I'm having some difficulties tackling a coverage reprojection > problem and so I'm here asking for directions to the coverage > experts. > > The issue is as follows. Let's say I want to serve to a client > a WMS image in EPSG:900913, but the WMS server is not able to handle > that projection, on the contrary, it's only able to provide > images in 4326 (example, the NASA wms server, onearth.jpl.nasa.gov). > Thus I need to put a man in the middle that can do the reprojection > in place of the original WMS. > > I have a WMS request in 900913, that I want to transform > in an equivalent request for the cascaded server, in 4326, > once I get back the image, I want to reproject it to 900913 > and serve it back to the client (cascading and reprojecting > WMS server). > > Now, all I have in my hands are the bbox in 900913, > and the width and height of the requested image. > Getting the bbox in 4326 is trivial. Getting an appropriate > width and height for the image I'm going to request > in 4326 seems to be the hard part. > Let me elaborate. Let's say I'm going to make the request > in 4326 for the bbox -130,25,-60,50 (lon/lat). A good > widht/height for that one could be 600x214, since it has > the same form factor as the bbox. > The same request in 900913 will have a different bbox, > and also a different with/height, in this case, 600x247, > because the transformation (a mercator) imposes > a different form factor. > > Now, say I have the request in 900913, what will be the > good dimension for the 4326 request? 600x214 does not > cut it, because reprojecting the resulting image > to 900913 will enlarge the pixels making the image > quite blurred. 600x247 would have the wrong form factor. > As you can see, the image requested in 4326 will have to > be bigger, probably 247 in height and > 600 / 216 * 247 = 689 in width -> a higher pixel > resolution to compensate for the vertical expansion > created by the mercator projection. > > What I'm looking for is a general formula to get the > optimal size, in pixels, for the input image, knowing > only the size of the desired image, the destination > crs and the source crs. > > If you think about it, this problem occurs also in standard > rendering when the source data has overviews. We know > what the destination coverage should look like, and we > have to decide what overview to pick out of the source image. > A problem that at the moment, afaik, is not considered. > WMS cascading + reprojection just makes it a little more > general, in that the source coverage has virtually any > pixel resolution we can think of (or even practically > every resolution, if the source data is vector > we can actually render it at any resolution level). > > Soo... coverage experts, any idea of how this problem > can be managed? > > Cheers > Andrea > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
