[postgis-users] Re: Re: Rasters (once more)

[Patrick]

On 17-Oct-2005, Frank Warmerdam <warmerdam at pobox.com> ever so gracefully
noted:

> This brings up another issue.  Your formulation does not seem to address
> the georeferencing at all.  I normally associate georeferencing with the
> raster (dataset in GDAL-speak) and this is one of the reasons that all the
> bands are required to have the same size.

Frank,

The raster table contains an srid which references a coordinate system, a
single tie point in the form of ulx and uly, a pixel size, an implied grid
coordinate system starting at [0,0] in the upper-left corner, and an implied
north-orientation. What information is lacking?

The implied north-orientation is another point for discussion, by the way.

> > * Bands are 2-dimensional. Could be changed, but I would like to hear
> > some good arguments to do so.
>
> This is very much my bias as well, but I am learning for the meteological,
> and oceanography communities that my remote sensing / gis bias may be
> limiting.  I think this might need some further consideration though bands
> of more than 2 dimensions will substantially complicate some things.
> Amoung other things, it would raise the question of whether we need
> distinct bands, or whether a stack of 2D bands should just be a 3d object.

I agree with you on both counts (the need and the complexity), and I am
"blessed" with the same bias as you are. I suppose that some input from the
meteorologic, atmospheric, oceanographic and geologic communities could be
very useful here. Two scenarios should at least be considered: 1) general
multidimensionality, potentially beyond 3D; and 2) time series. As you said,
everything can be solved with 2D bands, but more elegant and efficient (time
series) solutions may exist.

> Your proposed set of pixel types differs from that of GDAL in several
> regards.
> You have various partial-byte types which GDAL lacks.  I can see real
> value
> in the 1-bit type for masking but you might find it better eventually to
> drop the
> rest.  Likewise, I don't bother modelling a signed 8bit type.  It has
> little utility
> and can be easily handled by 16bit signed values where needed.

The 2-bit and 4-bit types are in the OGC spec. I admit that I do not use
them myself, but there should still be a vast body of older satellite
imagery with 4-bit classification out there. Int8 is another borderline
case. Does anybody ever use it? Anyway, I don't think there is a major
penalty for supporting it.

In general, I prefer to stay as close to GDAL as possible (even if I use my
own home-grown Delphi DAL) so any help you can offer is greatly appreciated.

Best regards,
Patrick