[postgis-users] Re: A PostGIS-Raster data proposal

[Carl Anderson]

Now that Paul is up on a soap box I feel compelled to throw my 2 cents in.

I agree with Paul, I have found that is it easier to tune and set up 
caching for WMS and WC services than it is to try and tune or add 
caching to database based image sources.  In  mixed client software 
environments even more so.
If you believe that the speed of GOOGLE Earth comes from massive image 
caching you might agree.

The compelling reason to put cell / grid /raster data into PostGIS has 
to be bound to one or more use profiles.  Each which can be evaluated 
and understood.

Elevation data comes to mind.  A DEM is a regular gridded set of 
elevation samples.  Sometimes it is convenient to programmatically 
convert 2 dimensional LineStrings into 3 dimensional (Z) LineStrings.

Looking at this goal, being able to resample a single elvation from an 
elevation fabric (source).
Converting the DEM into a TIN and then representing each polygon in the 
TIN as a 3D (Z) dimensional plane in PostGIS and creating some sort of 
resampling function might work better and faster than supporting the 
original gridded elevation set.  The TIN method actually does run faster 
in my own tests.

I am looking for a compelling use case to house Raster in a RDBMS.  
Client centric reasons are not so strong to me.  Reasons compelled by an 
internal RDBMS issue is stronger.

C.



Paul Ramsey wrote:
> SDE's raster-in-database support is only faster than other 
> alternatives because ESRI chooses not to make the alternatives 
> faster.  If you are ESRI, what's better for you, optimizing file-based 
> imagery access, or telling people to buy SDE?  Trust me, if you just 
> want fast access to a large set of imagery, stuff it in a directory, 
> build a mapserver tileindex on it and serve it as a WMS service.  
> Raster-in-database for performance is a red-herring propogated by ESRI 
> and Oracle who have an interest in selling said databases -- I have no 
> such interest.
>
> Arguments about unified user and access management, and integrated 
> raster analysis somewhat persuade me, but if people really want this 
> they are going to need to do it themselves, and job one of that is 
> creating a design.  I would suggest hitting the wiki, starting to 
> layout some standard table structures and descriptions of where data 
> goes, and function signatures for accessing things.  Once a design is 
> in place, it is possible for folks to take a piecemeal approach to 
> implementing things a function at a time, but until then nothing much 
> will happen except jawboning.
>
> PS - Copying other people's implementation designs is also acceptable, 
> though really abstract designs like oracle's georaster will have a 
> pretty high implementation overhead.
>
> PPS - We have avoided having to design anything in the past by simply 
> aping the standard, but there is no standard to ape in this case.
>
> P
>
> On 25-Oct-06, at 3:38 PM, galen at shackprices.com wrote:
>
>>
>> I'm not familiar with the specifics of the implementation, but when I 
>> was
>> contracting for the EPA in New Orleans cleanup effort, we stored massive
>> multi-gigabyte rasters in a geodatabase using ESRI's (ack!) database
>> frontend and a MS-SQL backend (it was transparent to users, so it could
>> have been Oracle).  It made image retrieval much faster over the network
>> and dramatically cut processing time. If we had to build our own system,
>> it would have been more expensive and time consuming.
>>
>> Here's a vote of support for the proposal!
>>
>> -Galen
>>
>> _______________________________________________
>> 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