<br><font size=2 face="sans-serif">IMO:</font>
<br>
<br><font size=2 face="sans-serif">Hi Randy, Ivan and Arnulf,</font>
<br>
<br>
<br><font size=2 face="sans-serif">I seem to have spawned another thread,
moving away from my original post and Randy's excellent response. </font>
<br>
<br><font size=2 face="sans-serif">Sorry.</font>
<br>
<br><font size=2 face="sans-serif">I've renamed this thread accordingly.</font>
<br>
<br><font size=2 face="sans-serif">more below...</font>
<br>
<br>
<br><font size=2><tt>discuss-bounces@lists.osgeo.org wrote on 21/02/2008
02:38:13 AM:<br>
<br>
> Hi Ivan and Bruce,<br>
> <br>
> <br>
>    I am curious to know what advantage an arcSDE/Oracle
stack would<br>
> provide on image storage. I had understood imagery was simply stored
as<br>
> large blob fields and streamed in and out of the DB where it is<br>
> processed/viewed etc. The original state I had understood was unchanged<br>
> (lossy, wavelet, pk or otherwise happening outside the DB), just residing
in<br>
> the DB directory rather than the disk hierarchy. Other than possible
table<br>
> corruption issues I imagined that the overhead for streaming a blob
into an<br>
> image object was the only real concern on DB storage.</tt></font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">The ArcSDE storage of imagery solution
that I described in my earlier post was at a previous place of employment.
They still utilise the solution effectively.</font>
<br>
<br><font size=2 face="sans-serif">While the storage of imagery using ArcSDE
can technically utilise multiple bands of radiometric data, it is mainly
using a set of blob records as Randy identified. This limits the usefulness
of the product when you want a flexible tool to manage multi or hyper spectral
data. This is also one of the reasons that I'm looking for alternate RDBMS
based solutions.</font>
<br>
<br><font size=2 face="sans-serif">Having said that I found ArcSDE to be
quite effective for orthophoto mosaics of aerial photography as I described
earlier.</font>
<br>
<br><font size=2 face="sans-serif">The data that we used was:</font>
<br>
<br><font size=2 face="sans-serif">aerial photography: </font>
<br>
<br><font size=2 face="sans-serif">- approx 500 individual images from
around fifteen runs of photography</font>
<br><font size=2 face="sans-serif">- approx 140 panelled ground control
points and airbourne GPS</font>
<br><font size=2 face="sans-serif">- photography was scanned and aerotriangulated</font>
<br><font size=2 face="sans-serif">- imagery was then mosaiced, orthorectified
and colour balanced</font>
<br><font size=2 face="sans-serif">- imagery then diced into around 70
RGB TIFF6 files, each around 1 GB, ~6 cm ground resolution.</font>
<br><font size=2 face="sans-serif">- imagery loaded into Oracle/ArcSDE</font>
<br><font size=2 face="sans-serif">- positional accuracy determined (~0.1m)
using stats and spread of error viewed usinging krieging techniques.</font>
<br>
<br>
<br><font size=2 face="sans-serif">In short ESRI's approach with ArcSDE
(as I understand it) is:</font>
<br>
<br><font size=2 face="sans-serif">- images broken down into small blobs
(we used 128k x 128k tiles, LZ77 compressed TIFF) and loaded with one 128k
blob per database record.</font>
<br>
<br><font size=2 face="sans-serif">- statistics calculated on imagery</font>
<br>
<br><font size=2 face="sans-serif">- 7 pyramid layers created</font>
<br>
<br>
<br><font size=2 face="sans-serif">This gave us the ability to:</font>
<br>
<br><font size=2 face="sans-serif">- store a relatively large amount imagery
and utilise it as a single entity (e.g. a layer).</font>
<br>
<br><font size=2 face="sans-serif">- only retrieve the records (tiles)
required for the geographic area being viewed. That is</font>
<br><font size=2 face="sans-serif">  we did not need to load the entire
mosaic into memory, just stream the records required.</font>
<br>
<br><font size=2 face="sans-serif">- only utilised an appropriate image
sample for the viewing scale utilised via the pyramid </font>
<br><font size=2 face="sans-serif">  layers (a common technique used
by RS products).</font>
<br>
<br><font size=2 face="sans-serif">- if required, add additional data to
the mosaic.</font>
<br>
<br><font size=2 face="sans-serif">- take advantage of corporate data management
techniques as discussed previously.</font>
<br>
<br>
<br><font size=2 face="sans-serif">As Arnulf correctly identified, there
is a black box behind the data storage. But this is equally true for the
majority of spatial data that is under active management around the world.
Ideally we would utilise an open format for storage and an open format
for delivery.</font>
<br>
<br><font size=2 face="sans-serif">Also for Arnulf:</font>
<br>
<br><font size=2 face="sans-serif">- I think that the user requirement
is there for storing raster data in a DB. We have had two uses identified
by myself and by Ivan. </font>
<br>
<br><font size=2 face="sans-serif">- When you consider the complexities
that Google must be facing with GE in trying to manage 256x256k tiles of
imagery over the entire world, at multiple pyramid layers and with constant
revision of imagery, you can soon see that a file based approach would
lead to a major headache. </font>
<br>
<br><font size=2 face="sans-serif">- I personally think that the case for
raster in a DB has been made.</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Now what I'd ideally like to find is
a good solution for managing multi and hyper spectral data in an RDB with
the ability to serve whatever band combination that a **user** requires
via an appropriate standard (possibly via WMS 1.3+ or WCS).</font>
<br>
<br><font size=2 face="sans-serif">Does anyone know of any solutions, preferrably
OS?</font>
<br>
<br>
<br><font size=2 face="sans-serif">I do recall a product that came out
of a German Uni around 2003. There was some talk on GIS-L at the time,
however it has slipped off my radar. Does anyone know what became of it.
I do recall that they'd had discussions with Oracle. It was around this
time that Oracle announced their Georaster format.</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Bruce Bannerman</font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<P><FONT face=Arial size=2>Notice:</FONT><FONT 
style="BACKGROUND-COLOR: #ff0000"><BR></FONT><FONT size=2><FONT face=Arial>This 
email and any attachments may contain information that is personal, 
confidential,<BR>legally privileged and/or copyright.</FONT> <FONT face=Arial>No 
part of it should be reproduced, adapted or communicated </FONT><FONT 
face=Arial>without the prior written consent of the copyright owner. 
</FONT></FONT></P>
<P><FONT size=2><FONT face=Arial>It is the responsibility of the recipient to 
check for and remove viruses.</FONT></FONT></P>
<P><FONT face=Arial size=2>If you have received this email in error, please 
notify the sender by return email, delete it from your system and destroy any 
copies. You are not authorised to use, communicate or rely on the information 
contained in this email.</FONT></P>
<P><FONT face=Arial color=#008000 size=2>Please consider the environment before 
printing this email.</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P> </P>
<P> </P>