[OSGeo-Discuss] Raster data on RDBMS

[Sylvan Ascent Inc.]

I understand. It is the difference between having to (1)serve fixed size tiles really fast out to GEarth/OpenLayers/etc, or (2) having to provide a random image or derivation thereof in any size, format, projection(WCS?). In the second case, speeding up the backend is the only way, in the first case, a tile cache could be a better choice. 
 
There is another possibility, that of putting a self-building cache on the backend, between the raw datastore and the WCS server, it could even be a database with some PGChip scheme.
 
<<The real point is should we discard RDBMS for Raster storage just because we are sure that there will be overhead, ours direct fopen(), fread() will always be faster? Myth or fact? Those tests have proven otherwise so the question is what is going own?>>
 
It may be faster from the db, as you can leverage the spatial index, and only pull the tiles you need, but I think Frank can answer this better.
 
I'm currently most interested in the first case of serving tiles, so if anyone has ideas on best practice for this, that would be great.
 
Roger Bedell, President Sylvan Ascent Inc.

________________________________

From: discuss-bounces at lists.osgeo.org on behalf of G. Allegri
Sent: Wed 10/29/2008 12:50 PM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Raster data on RDBMS



Thanks everyone for this interesting thread. I think the two
approaches have different goals:

 - rendering-on-demand performance comparison
 - raster serving performance comparison

Both are of interest, but they shouldn't be confused.
It might be helpful to write a wiki page (or something else) where to
gather the "best-practices" on serving (big) rasters. Well, it could
be interesting for vectors too, but it's a different story.
It's a common task for many of us, and it would be of help for both
the newbies and the more experienced users...
Ok, sorry for this OT digression :)

2008/10/29 Frank Warmerdam <warmerdam at pobox.com>:
> Sylvan Ascent Inc. wrote:
>>
>> I think, that since the goal of all this storage of pyramids and the like
>> is
>> just to get speed, that they aren't apples/oranges, but apples apples,
>> since
>> they are both pyramid schemes, just in different places, either in front,
>> or
>> in back of the server.
>
> Roger,
>
> My point is that a tile caching approach is really comparing tile caching
> performance to rendering-on-demand performance while I think the original
> point was that rendering-from-database and rendering-from-filesystem could
> have similar performance for input raster data.
>
> Your comparison is also of interest but I don't think it is fair to compare
> rendering from Oracle through MapServer (or GeoServer) to satisfying
> map requests directly from a tile cache.
>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> _______________________________________________
> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 6745 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20081029/cdd154b3/attachment-0002.bin>