[OSGeo-Discuss] Raster data on RDBMS

G. Allegri giohappy at gmail.com
Wed Oct 29 09:50:38 PDT 2008


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
>



More information about the Discuss mailing list