Thanks for your comments. Here are mine 1) Your comments on ResX, ResY, MinX, MinY, MaxX,MaxY. These attributes are in the META Table which has one record for each pyramid level. MinX, MinY, MaxX,MaxY are information for the whole extent of a pyramid level. ResX, ResY are the resolution for the pyramid level and are used to decide which pyramid to use.
All these fields have not to be filled in advance and are calculated in runtime. Storing back this values in the database is only for performance reasons. The plugin would work without these fields. 2) Storing the params for the Affine Transformation (mostly read from the world file) is currently not supported. We can discuss this after finishing the GSOC. At the moment rectangular tiles are supported. These tiles can be different in size and image format. 3) Storing the image area as a postgis geometry This is supported. If you have no spatial extension you can use the minx,miny,max,maxy approach, for postgis,mysql,oracle and db2 you can and should use the geometry column type with its associated spatial reference system. 4) Storing BLOBs as File and not in the database. In my opinion, this works only for small/medium images. In my project the largest pyramid has 2500000 tiles (yes, 2.5 millions). All maps together produce about 10 millions tiles. The deployment platform is an AIX P5 using 4 processors and using and IBM Storage tower. You cannot switch into a directory and make "ls *.tif". The result is "command line buffer exceeded". Try to move 2.5 Mio files from one directory into another. Coffee Time. And again, we are not talking about SATA II disks, we are talking about an IBM Shark System using fibre channels. Another reason is to get consistent backups. Storing on files means to backup the db and each file for its own. What happens in an error situation ?. Depended on the db you use, you can prepare physical storage for the images avoiding file system access at all (raw devices) . And finally, the default for almost any db handling blobs is to store them in the file system, the difference is you do not see the files. You are right, there is no way to create an index for pixels, but it would not make sense. Summary: We should discuss associating a tile with an affine transform. This would be an improvement , but first I have to finish the GSOC. Thanks for your hints christian Martin Desruisseaux-2 wrote: > > 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 > > -- View this message in context: http://www.nabble.com/Online-tests-and-jdbc-drivers-tp17689697p17706976.html Sent from the geotools-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------- 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
