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

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

IMO:

Paul,

> 
> On Feb 21, 2008, at 4:19 PM, Bruce.Bannerman at dpi.vic.gov.au wrote:
> >
> > What it comes down to is what is appropriate for your use case.
> 
> Indeed! However, there seem to be vanishingly few use cases for which 
> raster-in-database is actually the more appropriate solution.
> 

;-)  I beg to differ.


> (BTW, point-in-time recovery, a nice example of a place where database 
> semantics have an upper hand.  Although more modern file systems and 
> enterprise backup systems are pretty competitive now... even a 
> relatively simple hack like the OS/X Time Machine feature solves that 
> problem for-all-practical-purposes.)
>


Trying to manage very large regional datasets via a file based solution is 
problematic as described earlier with tile based approach to vector data 
in particular. Again for my use case the DB is better.


Just to throw in another related issue:

Lidar systems are throwing out an enormous amount of data. I had one 
dataset of only around 17 million odd records several years ago (of course 
stored in our corporate db ;-) ) that we could not handle with ArcGIS 
Desktop (v9.1). From memory it was a 32bit issue.

What approaches are people using with large Lidar datasets?


Bruce



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/20080222/f751f479/attachment-0002.html>