No. We deal with meteorological data rather than data images, and apart from
topography data (which can be pretty massive), none of our raw data is tiled.
A raster for us typically represents one meteorological parameter (e.g.,
temperature, daily precipitation, etc.) for a given time and data source. A
typical database of the kind we are working on now would hold such data for
several different parameters over lengthy time periods (30-50 years * daily
values * # parameters * # data sources) for about 3-5 TB of data. For a limited
system we might have only one raster definition, but a typical database would
probably have a handful or so.
A query using polygons as described above would, e.g., be to extract all the
data points within a region (a county, for instance) and aggregate the results
(typically avg, min or max) for each day or month over a thirty year period.
The result is outputted in all sorts of interesting graphs interactively, so we
need to do this in an effective manner. Not necessarily with sub-second
response times (our users do understand that they are asking for a lot of
data), but still snappily enough that people don't need to go out to lunch
while waiting for their data. :-)
We already do simple polygons with our existing WDB system, but:
- The algorithm is imprecise (just something simple that was hacked together at
need).
- It doesn't handle more complex polygons.
- Isn't fast enough (not optimized at all).
Thus our current interest in PostGIS raster.
Hey Michael,
I do something similar with meteorological/climate (temperature,
precipication, ndvi, gpp) datasets but the raw data is stored in rasters
(one image per day per variable) for 50+ years. In the current system,
the rasters are stored as massive tables with each row containing the
observation date, grid cell value and grid cell coordinates. I'm in the
process of testing the performance and storage requirements of PostGIS
Raster with a subset of the rasters for a variety of tile sizes. I
expect that I'll be moving over to using PostGIS Raster by the end of
this year.
I plan on writing a two raster ST_Intersects(raster, raster) function as
PostGIS Raster currently only has ST_Intersects(raster, geometry). The
additional hope is that I can get the two raster ST_MapAlgebra(raster,
raster) done by the time PostGIS 2.0 is branched.
-bborie
--
Bborie Park
Programmer
Center for Vectorborne Diseases
UC Davis
530-752-8380
[email protected]
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
