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

Paul Ramsey 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.

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




More information about the postgis-users mailing list