Alright, no IRC I guess :) A few questions then. Just to be sure: from your explanation I understand that you do not have problems to gain the right portion of reprojected territory and clip it on the right region, right? Your problem is bound to the distortion introduced in the image? I'm not sure if I got that right. You are complaining about the image being blurry, which is the proper result of a reprojection, I guess.
Your overall explanation below is clear, but I do not understand exactly were the missing point is. Sorry, if you can give me some more input... Andrea > > 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
