Bruce,Baskar, and Steve, many questions, I will try to give good answers :-)
It is not true that the table has only one row. Each row is a map. If your enterprise has 20 different maps, you have 20 records in this table. You can assign a different raster data table for each of this 20 rows. Oracle will create 20 different raster data tables (RDT) holding the tiles for one map. You can look at these RDTs, you will have tons of rows in it. I believe, these RDTs are exactly what you want to create yourself. You can specify a lot of storage parameters for these RDTs like tablespace, blocksize of one tile,... About the 95 % no data value. Specify a "compression= ..." storage parameter. "compression=DEFLATE" is a simple gzip for example. Do you use pyramids ?. If you use your own tile table and generate pyramids for each tile, you will have a good chance to see the borders of the tiles on your map, looking like a chess board :-) I have this experience since I developed the gdal_retily.py utility. Building a pyramid for one tile means also to load all 8 neighbors, moasic the image, and crop the original rectangle. If you use your own tile table, it is likely to loose the oracle pyramid feature. For Oracle 10.2, I have not seen a possibilty to import an already tiled image into a georaster object. Is this right ? This means you have to use gdal_merge.py For Oracle 11.x, I have seen SDO_GEOR.updateRaster at http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28398/geor_ref.htm#CACHBIAE updateRaster gives you the possibility to update a part of the raster object and the pyramids are rebuild automatically. Here you can avoid gdal_merge.py. To be fair, I have not used it until know, but this could be a chance. so far, so good, hope that helped a little bit Quoting "Thelen, Bruce" <bthe...@corelogic.com>: > Christian, > > If I read these instructions and the other documentation correctly, > this module is only intended to work on an Oracle GeoRaster table > that includes one row, is this correct? > > What if we have a dataset, such as a 1/3 arc second elevation grid > from the USGS that will be extremely large? I it is likely possible > to use GDAL to merge one very large GeoTiff, then import that into > a single entry but that's certainly not optimal. We also have the > issue of a dataset that doesn't necessarily fit very well into a > single raster entry such as a coastal storm surge grid for the USA > Atlantic and Gulf Coasts (because it will be 95% no value cells > since it is only coastal regions that have values, but they we would > merge into one large mostly empty raster). These are two of the > datasets that Baskar is trying to work with in this effort. It is > possible to either use GDAL to merge these, or even to use > SDO_GEOR.mosaic in order to create a table with only one row, but > that's really not our preferred method of storing data. It may > become apparent that this is our only option, but we haven't decided > that yet. > > Thanks, > Bruce > > > -----Original Message----- > From: christian.muel...@nvoe.at [mailto:christian.muel...@nvoe.at] > Sent: Tuesday, May 04, 2010 1:46 AM > To: Baskar, Dhanapal > Cc: geotools-devel@lists.sourceforge.net > Subject: Re: [Geotools-devel] Proposed Mosaicing GeoRaster Module > > Hi Baskar, > > First, please do a "svn up" on trunk, I did some enhancements giving > the jdbc driver a chance to cache prepared statements. > > Second, there is a misunderstanding of the Oracle Georaster concept. > > Oracle does the tiling and mosaicing for you. Looking at the test > setup, there is one table called "raster" with two attributes "name" > and "image". There is only one row in it. The image itself is already > tiled and has pyramids. > > The raster data table is called raster_rdt and is created and > populated by Oracle itself. > > SQL> select count(*) from raster_rdt; > > COUNT(*) > ---------- > 1029 > > There 1029 tiles in the db for pyramid levels 0,1,2 > > SQL> desc raster_rdt; > > Name Null? Type > ----------------------------------------- -------- > ---------------------------- > RASTERID NOT NULL NUMBER > PYRAMIDLEVEL NOT NULL NUMBER > BANDBLOCKNUMBER NOT NULL NUMBER > ROWBLOCKNUMBER NOT NULL NUMBER > COLUMNBLOCKNUMBER NOT NULL NUMBER > BLOCKMBR MDSYS.SDO_GEOMETRY > RASTERBLOCK BLOB > > Looking at these attributes, you see what Oracle is doing for you. > Oracle itself does the mosaicing and cropping for a given pyramid level. > > One big image is stored as one Oracle Raster Object. > > Btw, do you know www.gdal.org. This is the swiss army knife for image > handling. > You can use gdal_merge.py to create a big image from your tiles and > import it like I do it in the GeoRasterOnlineTest class > > Download gdal from http://fwtools.maptools.org/, this is easiest way. > > Your concept is more like this one > http://trac.osgeo.org/postgis/wiki/WKTRaster > One Table is one image, each pyramid level has its own table. > > I hope I could clarify these different architectures. > > And finally, there is nothing bad the way you did it, but you are not > using the full power of Oracle Georaster. > > Christian > > ------------------------------------------------------------------------------ > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > *************************** > This message may contain confidential or proprietary information > intended only > for the use of the addressee(s) named above or may contain > information that is > legally privileged. If you are not the intended addressee, or the person > responsible for delivering it to the intended addressee, you are hereby > notified that reading, disseminating, distributing or copying this message is > strictly prohibited. If you have received this message by mistake, please > immediately notify us by replying to the message and delete the original > message and any copies immediately thereafter. > > Thank you. > **************************** > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
