Hello Andrea Andrea Aime a écrit : > 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.
I assume that "right form factor" == "square pixel" and "wrong form factor" == "rectangular pixel" here. It shouldn't matter if pixels are square or rectangular. A renderer should be able to display the coverage with the appropriate form factor even if pixels are rectangular, providing that the renderer setup its display affine transform correctly. In the particular case of cascading server, we can even forget this rendering issue. You can ask any size for the 4326 request without bothering about the form factor (assuming the target server accepts that). When projecting the coverage with the "Resample" operation, asking for a size like 600x247 (or yet better, asking for a gridToCRS transform with uniform scaleX and scaleY coefficient) is suffisient for getting an end result with the appropriate form factor no matter what was the form of the original coverage (not talking about blurring effect if the resolution is insuffisient in the source image). In the purpose of reducing network transmission, it is in our interest to *not* preserve the form factor in the 4326 request. Quite the opposite actually. If the targetCRS is going to be a mercator projection, then a 600 pixel width source coverage is enough for a 600 pixel width target coverage (because the mercator projection do not stretch pixel horizontally). Asking more would consume more bandwidth, more memory and more CPU for no gain I can see. We need to care only about the image height (for mercator projection - other projections are other stories). Assuming that the target coverage size is determined by the user request (so the problem is to determine the size to be cascaded to the 4326 request): Conceptually we need to project a pixel near the pole (but inside the bounding box) from mercator projection to 4326 and look at the resulting pixel size, so we can infer the whole image size. Actually what we are interested in is the *derivative* of the projection on the bounding box edge: http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/operation/MathTransform.html#derivative(org.opengis.geometry.DirectPosition) Proposed algorithm (more general than what we said for the mercator particular case - will probably need more though for making sure I'm not proposing something wrong): 1) Sample the *derivative* of the map projection along the bounding box edge (a little bit like what we do for projecting an envelope, except that this time we get the derivative instead of the projected points). 2) Compute the scaleX and scaleY factors of the sampled derivatives, in a way similar to what we do in XAffineTransform.getScaleX0/Y0. They are typically on the diagonal of the derivated matrix, but not always. 3) Find the minimal scaleX and scaleY values. Divide the 4326 bounding box width (in degrees) by scaleX and we get the width in pixels. Do the same for height using scaleY. Unfortunatly the above "derivative" method is not yet fully implemented in GeoTools. For now we can get some approximative result by projecting sample pixels near the edge of the bounding box. Ideally we should finish its implementation. This approach may leads to big image with much more resolution than needed near the equator. A more efficient (but more complex) approach could be to cut the image in vertical slices and emit many 4326 requests with different resolution depending on the latitude (or the be more generic: cut slices along the axes having significant variation in the derivative matrix), and assemble them in one final image on the server side using some mosaic operation. Martin ------------------------------------------------------------------------- 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
