[postgis-users] rasters in PostGIS...

[Randy George]

Hi Frank,

	One place to look for a standard summary would be over at OGC,
http://www.opengeospatial.org/specs/?page=specs  "OpenGISR Grid Coverage
Service Implementation Specification (GC)"

	They have similar basic divisions as you have outlined:

"The architecture of the grid coverage specification is composed of three
packages as shown in Figure 1. 
1. The specification includes a package for the general coverage
specification (CV)
	CV_ColorInterpretation+ 
	CV_PaletteInterpretation+ 
	CV_SampleDimensionType+ 
	CV_Coverage+ 
	CV_SampleDimensionGC+

2. a package specifically for grid coverages (GC) 
	SampleDimensionGC+ 
	GC_ByteInValuePacking+ 
	GC_ValueInBytePacking+ 
	GC_Format+ 
	GC_GridCoverage+ 
	GC_GridCoverageExchange+ 
	GC_GridGeometry+ 
	GC_GridPacking+ 
	GC_GridRange+ 
	GC_Parameter+ 
	GC_ParameterInfoGP+

3. and a package for grid coverage processing (GP).
	GP_GridAnalysis+ 
	GP_GridCoverageProcessor+
	GP_Operation
		Gray Scale Threshold
		Image Enhancements
 			Linear Enhancement
			Root Enhancement
			Equalization Enhancement
			Infrequency Enhancement
		Interpolate
		Band Ratioing
		Spatial Filtering
			Mean Filter
			Mode Filter
			Median Filter
			Gausian Filter
			LaplacianType 1 Filter
			Laplacian Type 2 Filter
		Select Sample Dimensions
		Resample
		Sequence
		Density Slice"

Thanks
Randy

 -----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Frank
Warmerdam
Sent: Friday, September 30, 2005 7:56 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] rasters in PostGIS...

Folks,

I'm a bit late to the rasters and postgis discussion.  It seems I setup
a filter on postgis-users during the summer to skip my inbox and I haven't
visited my "all mail" folder since.

On 9/30/05, Matthew Perry <perrygeo at gmail.com> wrote:
> I have no idea what it would take to truly implement rasters in postgis
but
> I've been lurking on this whole debate and I have two major questions:
>
>  1. If you're going to run any useful SQL, your "atomic unit" has got to
be
> a single "cell", correct? What are the disk space costs of doing this? I
can
> imagine storing each cell of 16-bit tiff as a row in my "raster table"
would
> take massive amounts of disk space and be painfully slow to access.

The single cell should be addressable somehow in SQL, but the "object"
you put in the database field would presumably be a tile or whole image.

I have skimmed a variety of the other messages in this (lengthy) thread.

I personally hadn't tried to crack the raster-in-rdbms nut with GDAL yet
because I thought it required some thought to do it in a useful way.

Is there someone here who is familiar with the Oracle GeoRaster capabilities
and could summarize them?

Guido Lemoine writes:
> 1. sub-image extracts (e.g. for a polygon, along a line, or plane, for
> 3D data);
> 2. running image processing routines (filters, histogram analysis,
> enhancement);
> 3. data look up (e.g. extract all pixels/regions with a certain [range
> of] values;
> 4. image classification (segmentation), which would be some combination
> of 1-3.
>
> The db should handle *ALL* image metadata, including transformation
between
> image space and projections (avoiding reprojection of the images), look
> up tables, tile indexing, etc.

This seems like a reasonable set of desirable functionality.   I would add
that
"raster modelling" in the sense of applying various kinds of arithmetic and
logical operators would be desirable.

But we are really talking about implementing a full raster processing and
modelling environment in SQL here.  I think we could define a few levels
of implementation:

 1) Basic raster support in postgres.
     - raster object: supports the various pixel data types in a BLOB format
       that includes metadata on the data type, internal format (just
uncompressed
       raw binary for now),
     - extract subarea (possibly including masked under a postgis polygon)
     - convert data type (16bit->8bit, etc)
     - extract pixel values as a rowset.
     - extract histograms with providing binning parameters.

     This level should not need to depend on external libraries like GDAL,
and
     should be a minimum sufficient to use PostgreSQL for raster data
warehousing.

 2) GDAL Enabled
     - Data format translation (to/from any GDAL supported formats
that make sense)
     - image reprojection (possibly using GDAL Warp API)
     - support for storing raster data in particular formats in the
database (ie. GeoTIFF)

 3)  One million operators:
     - arithmetic and logical operators operators
     - various algorithms like classification, etc.

Personally, I feel rather uncomfortable with forging a long ways down this
road
without a standard to base implementation on, or at least a good
understanding
of how rasters are handled in other RDBMSes.   Funding to support such a
substantial effort is also an issue of course.

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
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users