[postgis-users] Re: A PostGIS-Raster data proposal
carl.anderson at vadose.org
Wed Oct 25 20:04:00 PDT 2006
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
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.
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.
> 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
>> 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!
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
> postgis-users mailing list
> postgis-users at postgis.refractions.net
More information about the postgis-users