RE: [OSGeo-Discuss] Re: Raster data on RDBMS

[Lucena, Ivan]

SyIvan,

I wrote:

> >  That is not the answer your are waiting for but...

I let did not mention any "benefits".

Sorry if lead you to a misunderstanding but thank you for inputs.

Best regards,

Ivan


>  -------Original Message-------
>  From: Sylvan Ascent Inc. <sylvanascent at mail2web.net>
>  Subject: RE: [OSGeo-Discuss] Re: Raster data on RDBMS
>  Sent: Oct 31 '08 10:24
>  
>  Well, now we get to the crux of the matter, what are the benefits? Let's analyze this a bit more to see if anything seems important. You mention:
>  
>  1) Spatial Extension - not sure what this is, but maybe you can build image operations into the database.
>  2) Schemas - Schemas can be queried, put into views, massaged
>  3) Metadata - well that's always handy, and likely much easier to maintain and query in a database.
>  4) Georeferences definition - Right, like simple features georeferencing, built into the schema
>  5) Spatial Indexation - Could make tiles faster to retrieve, coupled with pyramiding, should be decent performance
>  
>  I'll add this:
>  6) As newer data comes in you can more easily upgrade a raster coverage, as the metadata (like the date) can be queried for the latest and greatest, while retaining the older stuff. This might be trickier in a file based system.
>  
>  and how about the usual rdbms stuff like
>  7) Replication - might be useful once in a while, esp in big systems
>  8) Scalability (not sure exactly if this is the word, but db vendors/OS projects have put a lot of effort into scaling over lots of users)
>  9) Backup
>  
>  10) Transactions, possibly, if you are bringing raster data in from a satellite and something goes wrong? Unlikely to be to much of a benefit though.
>  11) Potentially more robust than using a file system
>  
>  More anyone? How about disadvantages, like
>  
>  1) You have to import the raster data into the database.
>  2) Have to decide what format/projection/datum to use to store the data.
>  3) Possibly more storage is used, but these days who cares?
>  4) Tile edge effects (with most compression schemes, there is often a noticeable "joint" when joining two tiles)
>  5) Partial tiles - when you split up an image, it rarely fits perfectly into your chosen tile size. What do you do with the leftovers?
>  
>  More?
>  
>  Another 2 cents,
>  
>  Roger
>  
>  ________________________________
>  
>  From: discuss-bounces at lists.osgeo.org on behalf of Lucena, Ivan
>  Sent: Fri 10/31/2008 1:20 AM
>  To: OSGeo Discussions
>  Subject: Re: [OSGeo-Discuss] Re: Raster data on RDBMS
>  
>  
>  
>  Paul,
>  
>  That is not the answer your are waiting for but...
>  
>  IMHO, once you overcome the mythical concept that a database server will always perform slower than a direct file access then "Spatial is not special anymore!" [who said that?] and you can think on the benefits just like a banker or an accounting bureau. Database servers in general are capable of making a good use of the available resources. For raster what is needed is a good BLOB support with cursor preferably. Spatial extension and schemas are indispensable accessories, they should provide metadata, georeferences definition, spatial indexation, etc. but they should not drag down the performance.
>  
>  Just my two cents.
>  
>  Ivan
>  
>  >  -------Original Message-------
>  >  From: Paul Ramsey <pramsey at cleverelephant.ca>
>  >  Subject: Re: [OSGeo-Discuss] Re: Raster data on RDBMS
>  >  Sent: Oct 31 '08 02:11
>  >  
>  >  On Thu, Oct 30, 2008 at 5:25 PM, Gilberto Camara
>  >  <gilberto.camara at inpe.br> wrote:
>  >  > but the benefits of having
>  >  > raster data on a DBMS are much more important.
>  >  
>  >  And those benefits are....?
>  >  _______________________________________________
>  >  Discuss mailing list
>  >  Discuss at lists.osgeo.org
>  >  http://lists.osgeo.org/mailman/listinfo/discuss
>  >  
>  _______________________________________________
>  Discuss mailing list
>  Discuss at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/discuss
>  
>  
>