[postgis-users] rasters in PostGIS...

Gerry Creager gerry.creager at tamu.edu
Thu Sep 29 14:51:50 PDT 2005


One problem here, however, is everyone thinks of rasters in 2 
dimensions.  Some of us display 3d data in 2d as a convenience but for 
scientific review, it really has to be treated as A) a spatial 3d data 
set and B) not just a georeferenced picture.

My applications are satellite data and radar data.  Both have geospatial 
aspects and both have pixel or voxel data per bucket.  Registering the 
buckets is as important as registering the overall "image" to us.

If I'm trying to recall a time series of Radial 314, Elevation 3.4 deg, 
Gate 10024, that looks like a nice database problem to me, or an image 
pixel decoding nightmare.

So, what I'm saying is this:  Generalizing the raster case ignores that 
some of us have "raster" problems that aren't just a pretty picture. 
They're really data storage issues that are (usually) presented as a 
raster image.

gerry

Chapman, Martin wrote:
> Jeff,
> 
> Oracle also charges tens of thousands for that documentation. It's hard
> to beat free.  Plus it's Open Source, not Open Documentation.  
> 
> On another note, it's a bad idea to store rasters in an RDMS in general.
> Databases do not handle BLOB data efficiently.  A better solution is to
> store your rasters on a file system and keep path information in the
> database in order to access your image data.  There are numerous reasons
> this is better.  Listed below are just a few:
> 
> 1.  Your database will be faster and easier to manage.
> 2.  Your database will scale much easier.
> 3.  You will require less fast disk for your db.  Rasters can be stored
> on tape, while your db can run on expensive fast disk.
> 4.  You can open images with other application like ArcMap, Erdas, that
> have no knowledge of how to access raster data in a database without a
> specific driver.
> 5.  Easier and faster to ingest rasters into your application.  If you
> store rasters in a database you will have to copy all image data when
> importing into the database.  This can take a long time and require a
> lot of cpu power/ram/disk space.  
> 6.  Some databases, like SDE, actually split the image into tiles, which
> means your data is rendered useless from a scientific perspective,
> because once an image is clipped, you can never get the real image back,
> because pixels are changed/lossed in the clipping/mosaicking process.
> 7.  If your database size gets too big...it may be a lengthy, if not
> impossible task to back up the database.  
> 
> And the list goes on.
> 
> We have had numerous customers buy our software because their previous
> solutions stored raster data in the database and it quickly became
> unusable because of the time involved to ingest/process data.
> 
> The problems listed above may not specifically apply to your solution,
> but I would start to think about storing files externally if I were you
> because it's a better long term architecture for both large and small
> GIS systems. 
> 
> Hope this helps,
> Martin
> 
> 
> -----Original Message-----
> From: postgis-users-bounces at postgis.refractions.net
> [mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Thursday, September 29, 2005 9:42 AM
> To: Jeff D. Hamann; PostGIS Users Discussion
> Subject: Re: [postgis-users] rasters in PostGIS...
> 
> 
> 
>> I know it's a daunting task (the docs for Oracle spatial are over
>>600 pages!) but there has to be some effort otherwise PostGIS looks  
>>like another "hey look what I did, isn't it cool" tool that has no  
>>real staying power and application.
> 
> 
> That's just silly, and a little insulting.
> 
> P.
> _______________________________________________
> postgis-users mailing list postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 

-- 
Gerry Creager -- gerry.creager at tamu.edu
Texas Mesonet -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020
FAX:  979.847.8578 Pager:  979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843



More information about the postgis-users mailing list