[postgis-users] Re: A PostGIS-Raster data proposal
pramsey at refractions.net
Wed Oct 25 19:13:36 PDT 2006
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 was
> contracting for the EPA in New Orleans cleanup effort, we stored
> multi-gigabyte rasters in a geodatabase using ESRI's (ack!) database
> frontend and a MS-SQL backend (it was transparent to users, so it
> have been Oracle). It made image retrieval much faster over the
> and dramatically cut processing time. If we had to build our own
> 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
More information about the postgis-users