When using the ImageMosaic-JDBC plugin, suddenly a glitch appeared on a rendered GWC image (an empty pixel column). So that, I dived into the code and got some insight about the way it renders images.
This plugin is designed to render in two stages. The "decoder stage" consists of the following steps: 1. it queries the DB to get the tiles that intersect the requested region to render (the requested envelope), 2. for every tile, it intersects the requested envelope and the tile envelope, 3. for every intersected envelope, it gets the (approximate) subimage from the tile that correspond to this envelope, 4. then all this info is stored on a queue. Next, in the "composer stage": 5. for every region in the queue, it retrieves the intersected envelope and its raster data (the subimage from the tile), 6. then, the subimage is copied to a region of a "virtual image" of the same scale than the tile, but aligned with the requested envelope. This process uses some rounding to create the size of the virtual image, and some rounding to guess where to copy the subimage, because the requested envelope "virtual image" grid and the subimage grid do not necessarily match. 7. Finally, the "virtual image" is interpolated to the requested image scale via the interpolation method configured for this dataset (in the xml file). The scaling used is the one precomputed before rounding the virtual image size. On one hand, this render method may be fast and show nice results to the eye. But on the other hand, it introduces shifting, sometimes glitches and to sum up generates imprecise results. A simple way to get an insight of this effect is zoom in the dataset with a nearest neighbour interpolation, until we see big squared pixels. Suddenly, the rendered image will start shifting (jumping) as we zoom in and out. Transparent pixels may result sometimes in metatile borders when using GWC as well. Gutter may help, but then you are likely to get repeated rows or columns of pixels in metatile borders. In my opinion, there are some ways to circumvent this effect. a) Do not work with datasets prone to be zoomed and do not use this plugin with GWC or pray that you won't get a glitch. b) Just render this dataset using GWC, but first make sure that your dataset is aligned with the gridset in such away that render rounding effects disappear. An alternative to the design of the plugin, is to preshift the tile in the decoder stage before computing the intersection, in such a way that it will be already aligned with the requested envelope. So that, the rounding effect will be under control, and the true shifting may be logged to the user. This will prevent GWC metatile glitches but the shifting will be still present. I've developed a patch that implements this idea. Anyway, the best workaround is to prepare the dataset (e.g. with gdalwarp) and the gridset together, so both grids fit for all pyramid levels. Another problem is that the final interpolation using the precomputed scaling can produce images of different size than requested. I've patched that as well. Do I prepare a PR? Two PRs? Two PRs and two Jira tickets? I wonder whether the ImageMosaic plugin (not JDBC) is also affected. _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
