[Gdal-dev] PostGIS CHIP Support - Tiled Pyramids?
Chris Hodgson
chodgson at refractions.net
Fri Feb 3 16:16:56 EST 2006
Frank and others,
I recently became aware of the work on the PGCHIP driver for gdal:
http://simon.benjamin.free.fr/pgchip/
This has resparked my interest in developing a raster storage system for
PostGIS. Paul Ramsey is generally opposed to this idea, and I think that
I agree with him in principal - however there is a continuous stream
of people interested in raster support for postgis.
So what I am looking for is a solution that puts the least possible
additional functionality into the database, but still allows maximal
functionality by leveraging other tools - I think GDAL may be the right
place for the additional functionality. The existing PGCHIP driver, as I
see it, allows a database table to essentially act like a tiff file, or
any other gdal datasource. This requires very minimal support from
PostGIS - the CHIP type is already there, with a few improvements and/or
a metadata table like geometry_columns, it should be able to do all that
is needed.
For good performance however, we need support for tiling, and
pyramidding. This COULD be built into the database, with additional
metadata tables defining the pyramids, but I think it might make more
sense to put this logic into GDAL. I think that anything involving
raster I/O would end up using GDAL anyway, and resampling and mosaicing
logic really doesn't belong in the database. GDAL already supports tiles
and pyramids that are internal to a datasource - Tiled TIFFs with
overviews, and JPEG-2000 or other wavelet based files come to mind. But
does it, or could it easily be made to, support external pyramids and
tiles?
As far as I can tell, the external tiling and pyramidding is handled in
Mapserver (Cheetah?), using gdaltindex and min/max resolutions on
multiple layers. What I'm thinking of is being able to define pyramid
sets in gdal-land, similar to the existing virtual raster support. Once
the pyramid set is defined, data could be loaded into and read from it
automagically... potentially the different layers of the pyramid could
even reside in different datasets - I can't see why you would want to do
that, but once you have that level of abstraction it should be easy.
Does something like this already exist? Have you ever thought about it
before, Frank? Would it be hard to do? I haven't previously had my
fingers too deep into the gdal codebase, but I'd be interested in trying
to implement this, with your guidance, assuming it isn't already there
and just hiding on me.
Let me know your thoughts,
Chris
More information about the Gdal-dev
mailing list