[OSGeo-Discuss] Image Management in an RDBMS...(was OS Spatial environment 'sizing')

[Bruce.Bannerman at dpi.vic.gov.au]

IMO:

Hi Randy, Ivan and Arnulf,


I seem to have spawned another thread, moving away from my original post 
and Randy's excellent response. 

Sorry.

I've renamed this thread accordingly.

more below...


discuss-bounces at lists.osgeo.org wrote on 21/02/2008 02:38:13 AM:

> Hi Ivan and Bruce,
> 
> 
>    I am curious to know what advantage an arcSDE/Oracle stack would
> provide on image storage. I had understood imagery was simply stored as
> large blob fields and streamed in and out of the DB where it is
> processed/viewed etc. The original state I had understood was unchanged
> (lossy, wavelet, pk or otherwise happening outside the DB), just 
residing in
> the DB directory rather than the disk hierarchy. Other than possible 
table
> corruption issues I imagined that the overhead for streaming a blob into 
an
> image object was the only real concern on DB storage.



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.

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.

Having said that I found ArcSDE to be quite effective for orthophoto 
mosaics of aerial photography as I described earlier.

The data that we used was:

aerial photography: 

- approx 500 individual images from around fifteen runs of photography
- approx 140 panelled ground control points and airbourne GPS
- photography was scanned and aerotriangulated
- imagery was then mosaiced, orthorectified and colour balanced
- imagery then diced into around 70 RGB TIFF6 files, each around 1 GB, ~6 
cm ground resolution.
- imagery loaded into Oracle/ArcSDE
- positional accuracy determined (~0.1m) using stats and spread of error 
viewed usinging krieging techniques.


In short ESRI's approach with ArcSDE (as I understand it) is:

- images broken down into small blobs (we used 128k x 128k tiles, LZ77 
compressed TIFF) and loaded with one 128k blob per database record.

- statistics calculated on imagery

- 7 pyramid layers created


This gave us the ability to:

- store a relatively large amount imagery and utilise it as a single 
entity (e.g. a layer).

- only retrieve the records (tiles) required for the geographic area being 
viewed. That is
  we did not need to load the entire mosaic into memory, just stream the 
records required.

- only utilised an appropriate image sample for the viewing scale utilised 
via the pyramid 
  layers (a common technique used by RS products).

- if required, add additional data to the mosaic.

- take advantage of corporate data management techniques as discussed 
previously.


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.

Also for Arnulf:

- 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. 

- 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. 

- I personally think that the case for raster in a DB has been made.



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).

Does anyone know of any solutions, preferrably OS?


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.



Bruce Bannerman









Notice:
This email and any attachments may contain information that is personal, 
confidential, legally privileged and/or copyright.No part of it should be reproduced, 
adapted or communicated without the prior written consent of the copyright owner. 

It is the responsibility of the recipient to check for and remove viruses.
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.

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20080221/e4c3d794/attachment-0002.html>