On Mon, Nov 03, 2008 at 10:13:49AM -0200, Gilberto Camara wrote:
> Dear all
>
> Concerning the benefits of having raster data
> stored together with vector data in a spatial
> database, let me first quote from an excellent
> paper from the late Jim Gray
> ("Scientific Data Management in the Coming Decade"):
>
> "What’s wrong with files?
>Everything builds from files as a base. HDF uses files.
>Database systems use files. But, file systems have no
>metadata beyond a hierarchical directory structure and file
>names. They encourage a do-it-yourself- data-model that
>will not benefit from the growing suite of data analysis
>tools. They encourage do-it-yourself-access-methods that
>will not do parallel, associative, temporal, or spatial
>search. They also lack a high-level query language.
>Lastly, most file systems can manage millions of files, but
>by the time a file system can deal with billions of files, it
>has become a database system."
>
> In other words, if you have substantial amounts of raster
> data (as is increasingly the case in geospatial application),
> you will need to develop a significant amount of software
> to manage your files. Unless... your data is handled by a
> raster-enabled spatial database.
I don't see anything in that paragraph that indicates that storing the
*image data* in the database is important. (A link to the paper online
or something could change that, of course.) Specifically, I don't think
there's any doubt that if you have many-many files, it makes sense to
store the *queryable image information* -- things like spatial extent,
temporal extent, etc. -- belong in a database. The question is, in the
"data" column, do you store a File Path, or the Image Data? Until/Unless
databases get/have image manipulation tools directly, I can't see the
value of storing the image data itself in the database.
The points above argue against file-system based metadata
storage/retrieval: sorting files by date, searching through index files,
etc., so far as I can tell, but I don't see a compelling argument for
image data in the database above.
Of course, this is assuming that the image data access pattern is the
same "in the database" and "on disk": for example, storing GeoTIFF data,
then using GDAL to parse the string from the database as a GeoTIFF file.
If the database you're using has a different (faster) Image access
algorithm, then of course there can be benefits. However, those same
benefits could presumably be realized with sufficiently complete
libraries for accessing the image externally: If Oracles' Database
product, for example, internally tiles the image, and they had a library
to access the image in the same way, presumably you could store those
bits on disk as well. However, if that library depends internally on a
database, then integration of all points into the same database might
help in some ways.
In any case, I think there's obvious reasons to store your image
metadata in a database -- and *using the same tools for accessing the
images*, I don't think we've yet seen a compelling argument for storing
image blobs in the database. Of course, all things are not equal :)
If your database has built in MrSID support, for example, you could
imagine using Database Storage for Images, because you'd get the
automatic compression combined with the querying -- but that's not about
the Database Specifically, just the image storage/reading library that
comes along with it.
Regards,
--
Christopher Schmidt
Web Developer
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
