Ciao Patrick, nice work. Together with staff member from the Univ. of Genoa in Italy, we are working for a customer on an approach to put generic rasters inside postgis. When I say generic I refer to multiband spatiotemporal rasters with multigranular resolutions.
Basically the idea is to ingest raster data into postgis that can span over time and elevation/depth doing some good old preprocessing on them which obviously includes tiling and adding overviews to the original data. Actually for the moment we are keen to keep the final data (tiles basically) outside postgis but we are trying to describe a db schema + a lib structure that could allow to store them right insided the db in case one wanted to do so. we are, of course, planning on making an extensive use of JAI and ImageIO. In the following weeks we should start sending out some schemas/code hopefully in order to get some feedback. Note that this work is not focused on creating a catalog of raster data but rather on finding a way to ingest data and keep them stored inside (or indeed by) a spatial db. In this perspective your code sounds like a nice effort that we would love to integrate somehow in the work we are carrying out. Ciao, Simone. On 8/16/07, Patrick Way <[EMAIL PROTECTED]> wrote: > > Hi Jody, > Thanks for the kind words and information about naming the java classes. I > would be interested in working with the community to improve this method of > managing rasters in the PostGIS database. My motivation for developing this > process was to achieve maximum performance with regards to rendering rasters. > If the grid size and resolution are chosen wisely then at any scale the sum > of the raster images required should not exceed 10-15 megabytes. By > preprocessing the images into smaller tiles the computer has less work to > perform and the image can be drawn faster. Also the GridCoverages generate a > bit faster than geotiffs partly because the transform and spatial reference > data are preprocessed as well. The cost for this concept is a large amount > of data stored which can be mitigated with a large hard drive. > Cheers, > Pat > > On Wednesday 15 August 2007 20:00, you wrote: > > This sounds like a great hack Pat, are you planning on taking this > > anywhere? > > > > The PostGIS community keeps on wondering how to represent rasters in the > > database, I know OracleSpatial already has some crazy construct for it. > > > > A couple of comments about your code: > > - Java classes usually begin with an uppercase letter (ie not vtRaster) > > - If you and the user list are interested you can set up an unsupported > > module to collaborate on this idea > > > > Cheers, > > Jody > > > > Patrick Way wrote: > > > Hello, > > > I have had success by creating image tiles of varying resolutions and > > > storing them in a postgresql/postgis database. The element that makes > > > this possible was figuring out how to store geotiff files in a database. > > > To do this I created an imagecatalog table: > > > float --> resolution > > > geom --> envelope > > > text --> crs > > > text --> transform > > > double --> scale > > > bytea --> image > > > > > > Then I wrote a java class for parsing a GridCoverage into the > > > binary,crs,and envelope data. Another class for the GridCoverage format > > > that is similar to a world file format. > > > > > > I have been working with large geotiff files, to make them manageable I > > > have tiled them into grids at various resolutions and stored the tiled > > > images in the image catalog table > > > > > > When I want to draw images on a map I use the map scale to determine the > > > appropriate resolution value then select the images from the image > > > catalog table that intersect the envelope and equal the resolution > > > value. > > > > > > The code for the two java classes follows. > > > > > > Pat > > ------------------------------------------------------- > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Geotools-gt2-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > -- ------------------------------------------------------- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it ------------------------------------------------------- ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
