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

[Arnulf Christl]

Randy George wrote:
> 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, 

BEEP!

The opposite to "FOSS" is "proprietary"! Some related information can be found here:
http://wiki.osgeo.org/wiki/Commercial_Services
and here:
http://wiki.osgeo.org/wiki/Category:Advocacy

Regards, 
Arnulf. 

(sorry to be picky, but its my job)

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.
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss