RE: [OSGeo-Discuss] Re: Raster data on RDBMS
ivan.lucena at pmldnet.com
Fri Oct 31 03:42:54 PDT 2008
> > 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.
> -------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?
> Another 2 cents,
> 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
> 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.
> > -------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
More information about the Discuss