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. <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > > 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 > > <[EMAIL PROTECTED]> wrote: > > > but the benefits of having > > > raster data on a DBMS are much more important. > > > > And those benefits are....? > > _______________________________________________ > > Discuss mailing list > >[EMAIL PROTECTED] > > http://lists.osgeo.org/mailman/listinfo/discuss > > > _______________________________________________ > Discuss mailing list > Discuss@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/discuss > > > _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss