The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences. Vol. XXXVII. Part B4. Beijing 2008
To get an idea of how GeoRaster performs, we tested on the key
tuning function, called changeFormatCopy. It can adjust the
internal storage format based on user specifications, such as
blocking size, interleaving type, cell depth and compression
type. The size of the GeoRaster object used is 96M. It has 8000
rows, 4000 columns and 3 bands. The cell depth is 8 bit
unsigned. The interleaving type is BIP. They are all three-band
true-color images. In the test, the database buffer cache and
shared pool are flushed to make sure every measure on the
procedure is of a new execution of the procedure itself. The
results are shown in Table 1. The tests only do reblocking of the
GeoRaster object (no interleaving and other changes combined)
and “noblock” means the image is not blocked, or in other
words, the whole image is one block without padding. The
blocking size is specified in the order of row, column, and band.
For example, a blocking size of 512x512x3 means each block
would have 512 pixels in row dimension, 512 pixels in column
dimension and 3 bands.
Original raster
block size
New raster block size after changeFormatCopy
256x256x3
1024x1024x3
2048x2048x3
noblock
64x64x3
59.90
57.94
57.97
58.54
128x128x3
49.31
48.96
59.29
55.50
256x256x3
42.74
54.51
49.43
54.05
512x512x3
52.47
42.72
44.68
47.63
1024x1024x3
47.00
37.65
40.48
45.98
2048X2048x3
46.10
41.09
37.61
42.90
Table 1. Average execution time in seconds
to change internal raster block sizes
The changeFormatCopy procedure consists of two major
processes. One is to change the format of the GeoRaster object.
Another one is to make a copy of the original data. As you can
see from Table 1, the speed is very fast. One observation is that
when we call the procedure to change the block size to the same
block size of the original object, the procedure is basically
equivalent to copying the original blocks directly to the new
object. Based on the data in Table 1, it means that most of the
execution time is spent on simply copying data from one
GeoRaster object to another while the data manipulation inside
the database server is actually much faster. Like most other
functions, this one is obviously I/O intensive and better I/O
throughput would help in general. Efficient I/O operation is one
of the key directions in improving performance.
Query is very important for such databases and the speed of
such query is critical. So, we did some tests on the major
GeoRaster query function, called getRasterSubset. It returns a
subset of a GeoRaster object based on the query window, no
matter how big the GeoRaster object is or how it is stored
internally
Retrieving
window size
GeoRaster block size
128x128x3
256x256x3
512x512x3
1024x1024x3
2048x2048x3
256x256x3
0.3528
0.3194
0.3256
0.3178
0.3722
512x512x3
0.3970
0.3666
0.3424
0.3804
0.4478
1024x1024x3
0.5388
0.5068
0.4602
0.4766
0.5882
2048x2048x3
1.1450
0.9680
0.9028
0.8924
0.8848
Table 2. Average execution time in seconds to retrieve different
subsets of raster data from differently blocked GeoRaster
objects
We called getRasterSusbet 50 times continuously to get the
average execution time. In this test, the buffer cache and shared
pool were flushed out before every execution of the
getRasterSubset procedure to make sure the measures are the
pure running time of each independent call of the
getRasterSubset and do not take advantages of database caches.
We used various retrieving window sizes to retrieve data from
the GeoRaster objects that have various GeoRaster block sizes.
Results are shown in Table 2.
From this test, the AOI (area of interest) queries took only sub
seconds and showed very good performance. Properly tuning
the blocking size may improve the performance as well.
GeoRaster provides such tuning tool through functions like
changeFormatCopy and so you can easily adjust the internal
storage to meet specific application requirements.
5. THE USABILITY
The other challenge we discussed earlier in this paper is how to
attract more users and push geoimagery into enterprise systems
so that more people and more businesses can benefit from the
achievements of the geoimaging and geospatial professionals.
So, enterprise integration and usability becomes another key of
the design of this database-centric approach.
Obviously the native data type and building the processing
system from inside the commercial database server enable easy
integration of enterprise data and geospatial raster data. It
allows users to define a relational table in which images and
other enterprise data can be stored together and those tables can
be joined by defining their relationships. In order to build a
single data type for different data sources, the native GeoRaster
data type uses a single and integrated data model and thus
simplifies the understanding and usage of such raster datasets.
Even more important is the SQL API provided with GeoRaster.
SQL is the language of commercial database systems. Most
Oracle database users and system integrators are familiar with
the usage of the standard SQL and PL/SQL language. The
language is simple, easy-to-use and has good modularity. It
gives user the flexibility of data manipulations either through
simple data queries or by packaging many functions into one
package to achieve more complex goals.
For example, users can query the total band number of a
GeoRaster object as follows:
select sdo_geor.getbanddimsize(t.my_image)
from mytable t where id=21;
Users can simply write the following PL/SQL block to tune the
block size of a GeoRaster object (georl) and apply JPEG
compression and store it in another GeoRaster object (geor2).
declare
georl sdogeoraster;
geor2 sdo georaster;
begin
select my_image into georl from my table where id = 1;
select my_image into geor2 from my table where id = 2
for update;
sdo_geor. changeformatcopy(geor 1,
'blocksize=(256,256,3) compression=JPEG-B',
geor2);
update my table set my_image=geor2 where id=2;
commit;
end;
202
