[postgis-users] Re: when rasters in Postgis?

[rb]

While I would not support acutally sticking the raster data into a db
table, there are many uses for rasters beyond masturbation. For that
matter, some of us actually USE raster data for analysis, not just
pretty pictures.

If you are dealing with environmental data, there are many compelling
reasons to prefer rasters, i.e. when analyzing a kajillion data points.
I have seen numerous posts on this list regarding the performance hit
that one encounters when analyzing point data that at times has struck
me as begging for a raster solution. For these limited situations, I
think that attaching file names in a field as another user has suggested
is reasonable, but then there is also the issue of allowing for raster
querying from SQL syntax. 

Consider a situation where one has raster land use data and vector
watershed data. The landuse data cannot be stored efficiently in either
point or polygon format, because at the current levels of resolution (1
meter cell width for lidar elevation data) it would cripple your system.
So, you want to know the breakdowns in land use by your sub-watersheds
-- this requires a zonal summary of raster data within a vector. Pull it
into ArcFOO and do the analysis, then bring it back to your data base
you may say? Perhaps, but what if this data is changing temporally, and
this is not the solution that you wish? A good example of temporally
changing raster data beyond landuse (slow change) is deposition of
atmospheric contaminants (changing over long and short time scales) and
rainfall (minute by minute). Plus, there is a reason we are trying to
avoid ArcFOO in the first place...

I think it is cool to look at a variety of the challenges and dead
ends/wrong turns that one may encounter in response to raster queries. 
I also understand that not everyone has the inclination or need to work
on a raster implementation of some sort, but there most definitely ARE
good uses of raster data that is integrated with, if not actually stored
in, an RDBMS.

my $0.02,
r.b.


On Mon, 2005-09-26 at 21:42, Paul Ramsey wrote:
> Thank you Patrick :) !!! It takes a raster geek to note that stuffing  
> data traditionally stored in multi-gigabyte files into a RDBMS does  
> not necessarily buy you *anything* of use.  And doing it well  
> involves a lot of trade offs.  In order for the database to perform  
> at random access of the data, it must be cut up into chunks of less  
> than the page size. So everything going in must be pre-processed. So  
> there's a format conversion step on the way in. And hopefully you  
> also push everything into the same SRS.
> 
> And when you're done, what do you do with it?  Let me guess, now you  
> want mapserver support or some kind of commandline support to pull  
> the stuff out into mosaics... Which is nothing more than what you can  
> do with mapserver and a bunch of TIFFs.
> 
> I have a huge problem with "raster in the database" because I do not  
> believe it has any practical purpose.  ESRI promotes it primarily as  
> a way to sell ArcSDE licenses, but this has led to a widespread  
> belief in the geospatial community that putting raster imagery into a  
> database is actually a useful exercise, not the masturbatory waste of  
> time it really is.
> 
> Buy a lot of disks. Convert your imagery to TIFF and create internal  
> pyramids (gdal will do all this for you). Create a tileindex, either  
> in shape or in postgis if you have some other programmatic use for  
> the index. Put mapserver on top of it and serve it as a WMS.  Want a  
> mosaic?  Run a simply curl call on it for the area and size you  
> want.  Want to see it in your GIS desktop (ArcMap, uDig, JUMP,  
> whathaveyou)? Point the thing at the WMS and you have instant tiled  
> complete imagery coverage within your application.
> 
> But please, god, don't stuff images into your database.
> 
> Paul
> 
> On 25-Sep-05, at 1:30 PM, Patrick wrote:
> >
> > Considering the traditional mismatch in granularity between raster  
> > data and
> > database storage, the challenge is in devising an efficient storage  
> > design
> > that does justice to both. That design would no doubt be based on  
> > some form
> > of tiling of the data, but then new issues surface, such as how to  
> > deal with
> > the diverse input formats, how to deal with reprojection, and how  
> > to present
> > data in response to queries (where most user programs expect entire  
> > rasters,
> > not tiles of data).
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
-- 
Non-point Source Data Analyst
University of Maryland, College Park
Chesapeake Bay Program Office
410 Severn Avenue, Suite 305B
Annapolis, MD, 21403
Phone: (410) 267-5779

rburghol at chesapeakebay.net