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

[Paul Ramsey]

For those who haven't checked, there's some interesting reference  
material here:

<http://postgis.refractions.net/support/wiki/index.php?RasterNotes>

P


On 25-Oct-06, at 9:41 PM, Paul Ramsey wrote:

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