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

[Randy George]

Hi Bruce,

 

"What approaches are people using with large Lidar datasets?"

 

You might take a look at the WeoGeo group. They are a commercial operation,
not FOSS, but they are throwing dedicated AWS instances at the issue of
lidar file serving. The dedicated instance, I gather, is for the sole use of
the download client with any clip, re-project, or re-format processing
requested. Paul Bisset would be happy to clarify.   http://www.weogeo.com/ 

Some more details here: http://www.cadmaps.com/gisblog/?p=25

 

The lidar itself is I assume a raw file, probably split into a set of S3
objects which are stream concatenated and run through the processing
instance and out to the requestor. Since the data sets are very large the
dedicated assignment of a temporary cpu or two is justified.

 

Beyond that I would like to see at least some lidar sets treated like the
JPL srtm which is made accessible via WMS with pixel coded elevation as
grayscale. Paul Ramsey's inimitable advice would work well for lidar too.
The end client can turn a WMS request on a lidar image pyramid behind say
Geoserver into whatever is desired, in my case I would turn it into 3D xaml
meshes.  I imagine this could be done in a more standards compliant manner
through the WCS spec. I believe that the JPL srtm was made public before an
implementation of WCS was accessible. 

 

http://onearth.jpl.nasa.gov/index.html

The default styles for the elevation layers are a version of the elevation
maps scaled to 8 bit. The full elevation values can be retrieved from this
server by requesting the short_int or feet_short_int styles in combination
with the image/png image/geotiff or image/tiff value for the format
argument. The result of such a request will be an image where the signed
short integer values contained in the image file for each pixel are the
elevation of the respective point on the map, in either meters or feet. The
base data is in meters. The us_ned layer base data is floating point real
numbers in meters, data which can be retried in tiff or geotiff format when
using the real or feet_real as styles.

 

I like the interchange of comments on this subject . In the end I'm inclined
to stick with the simplicity of file storage for imagery.  

 

Thanks

Randy

 

 

From: discuss-bounces at lists.osgeo.org
[mailto:discuss-bounces at lists.osgeo.org] On Behalf Of
Bruce.Bannerman at dpi.vic.gov.au
Sent: Thursday, February 21, 2008 6:25 PM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Image Management in an RDBMS...(was OS Spatial
environment 'sizing')

 


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/20080221/d02cb6ae/attachment-0002.html>