We can imagine a number of reasons why an JDBC Mosaic other then PostGrid is wanted. It could be lighter, target a wider range of database backend, apply mosaic without the restriction on integral subsampling (this is a balance between memory usage, performance, capability to handle arbitrary scales), etc.
However PostGrid is 5 years old and we gained some experience with it. So maybe I should share a few suggestions: You have a table with the following columns: ResX, ResY, MinX, MinY, MaxX, MaxY. We did something similar in the early days of PostGrid, and changed our mind. The first 4 columns are essentially the same than AffineTransform scaleX, scaleY, translateX and translateY coefficients when there is no rotation. The last two can be computed if we known the image size. I realize that they still useful for leveraging database index when searching for tiles in a given area, but we could also stores the image area as a PostGIS geometry and leverage the RTree, which is designed especially for this task. An other reasons is that, if the 4 first columns are affine transform coefficients, we could "finish the job" and put the last 2 remaining affine transform coefficients: shearX and shearY. You now have a full set of 2D affine transform coefficients in your table, allowing you to handle rotated images. They are not so unusual that they may seen (it was an IFREMER requirement on our side). If you happen to parse .TFW files that come with some .TIFF files, their content are exactly that: affine transform coefficients that you could put straight into your database. However if you include a full set of affine transform coefficient in your database, then "MinX" and "MinY" are not really minimal coordiantes anymore, but rather "translateX" and "translateY". The same applies to "MaxX" and "MaxY", which become slightly more difficult to define. So it may be better to not include them in the database and relies on a geometry column for indexed search instead, keeping in mind that the geometry can now be a rotated rectangle. For information if you wonder what may look like the table after such changes, you may look there and scroll down to the CREATE TABLE "Geoemtries" statement: https://svn.codehaus.org/constellation/trunk/postgrid/src/main/sql/postgres/postgrid.sql Note also the trigger defined just after the table, which create automatically for us the (potentially rotated) rectangle in the geometry column. The map projections are handled by PostGIS. An other question is whatever image should be stored in the database as BLOB or as ordinary files. On our side, we have choosen ordinary files. Given that a database engine do not index pixel values inside a BLOB to my knowledge, intuitively I would not expect a BLOB to be faster than a plain file... Regards, Martin ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
