De : Andrea Aime <andrea.aime@anonymised.com>
Date : 23 septembre 2006 13:14:17 HAEC
À : Vincent Heurteaux <vincent.heurteaux@anonymised.com>
Cc : Simone Giannecchini <simboss1@anonymised.com>, Geoserver-devel <geoserver-devel@lists.sourceforge.net>
Objet : Rép : [Geoserver-devel] Postgresql Datastore for rasterVincent Heurteaux ha scritto:
Ciao Simone,
In our case, postgresql doesn't store images in blobs. As Sandro explained last week during "Future directions of PostGIS <http://www.foss4g2006.org/contributionDisplay.py?contribId=109&sessionId=42&confId=1>" présentation, there is a lot of overhead with that. The method we're using consist in storing GridCoverage metadata in the database and images in the filesystem (this is an other way that Sandro wanted to investigate).I agree this is basically the way to go if you want good performance, and
it's also relatively easy to implement if your application is the only one using
that data (so you keep the raster on the same filesystem as you app, and use
postgis as an indexed metadata store).At same time it would be nice to have the database handle the details and provide
access to the images thru the standard jdbc channels, so that you can share the
same data with other applications. That is, have the database server store stuff on
its filesystem, instead of using normal table storage, and allow people to access
those the same way as blobs, or whatever other mean that does not require too much
overhead (I don't know, for example as something out of the jdbc standarard
that only postgresql supports, in order to have minimal overhead).Cheers
Andrea AimePS: this post won't probably be seen on the ml because my smtp is blacklisted,
can anyone of you resend this to the ml acting as a rounter?