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

[Paul Ramsey]

I should probably add that I have already come within a hair of  
funding some raster-in-database for client use and may yet cross that  
threshold, but the use case is, as Carl says, entirely internal to  
the RDBMS: convert vector features to raster, do raster operations,  
convert the results back out to vectors.  Basically GRASS-in-a- 
database.  Now that moves are afoot to move some of the GRASS  
analysis algorithms into a C API, this integration approach is  
getting even more interesting to me.

So I am not against raster-in-the-database in principle, lest anyone  
take my rhetoric the wrong way, I'm just not in favor of it as an end  
in itself.

Those who don't want to wait for me to cross the threshold should  
move of their own accord to document a design and get agreement from  
the community that the design looks workable.

I was fond of going to LO route in my flirting with the idea,  
precisely because it made the use of things like GDAL or (in the  
future) GRASS libraries pretty straightforward -- grab a file-handle  
and go.  Custom PgSQL types can include an LO reference.  I never  
investigated the transactional issues involved, that's an interesting  
point.

P

On 25-Oct-06, at 8:04 PM, Carl Anderson wrote:

> 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
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users