[raster] ST_Summary(raster)

[strk]

I tried the select, for a quick & dirty summary of what's in a raster (for human consumption) but PostGIS has refused me an answer. Pity !

[strk]

What I'd want: dimensions, extent, number of bands and type of each band

[robe]

You mean for each tile? or the whole table?

raster_columns view generally gives you all that for whole table.

extent would be ST_Extent(rast::geometry) and other stuff would be in ST_MetaData and ST_BandMetaData

[strk]

ST_Summary is for single literal raster value (a tile, if you want to call it that way)

[dustymugs]

Can do…

[dustymugs]

ST_Summary(raster) would return the following…

1. dimensions
2. extent (are you sure about this? if so, box2d?)
3. skewed
4. # of bands
5. pixel type of each band
6. indication if band has NODATA value and what it is

Example output:

[Skewed] Raster of 800 by 600 pixels with # bands and an extent of BOX(...).
  Band 1 is of pixel type 8BUI and has no NODATA value.
  Band 2 is of pixel type 32BF and has the NODATA value of -9999.
  ...
  Band n is of pixel type PIXTYPE and has (no NODATA value|the NODATA value of ???).

Is that what you're looking for? Maybe too much verbiage…

[strk]

I think the example output is good. The extent can be kept out, you decide (we can always change later). If "skewed" is a flag (yes/no) consider using a single letter (presence for yes, absence for no) like it's done for presence/absence of BBOX/SRID in the geometries

[pracine]

ST_Summary() is for geometry. Try ST_SummaryStats() on raster instead. Read the doc before feeling a ticket…

[strk]

Pierre: the PostGIS Raster project main goal was "seamless integration". ST_Summary(geometry) exists for debugging purposes. The ticket is asking for the same thing for raster. If ST_SummaryStat has the same purpose, it's been an error to call it like that in the first place (why another name for a semantically equivalent function already existing for Geometry?).

Anyway, I think the docs say that SummaryStats needs to scan the whole raster pixel-by-pixel. This one wouldn't need it.

[dustymugs]

ST_SummaryStats provides basic statistics (count, sum, mean, std dev, min, max) about a raster's band. ST_Summary on the other hand is a combination of ST_Envelope(), ST_Metadata() and ST_BandMetadata().

[pracine]

The question now is: Is what strk looking for fulfilled by ST_SummaryStats? If yes why creating a new function? I'm wondering if it's not the ST_Summary result that should become more like the one provided by ST_SummaryStats: a multiple, typed, column result splittable on many columns with the "(result).*" syntax. What is the need for this verbose, ugly, human-only readable result? Seems to me that a result like the one provided by ST_SummaryStat is much more useful for any subsequent treatment (human or machine).

[dustymugs]

strk isn't looking for a band's stats. He just wants the metadata of a raster.

[pracine]

ST_Metadata(), ST_BandMetadata()

[strk]

Pierre: I'm sure there are way to obtain the information I want. This ticket is here because I thought postgis raster had to be "seamless" and that means, to me, being able to use the same functions, when they make sense. I've no willing to fight for it, anyway.

[pracine]

I agree that things should be seamless when they make sense. My question now is more on the real utility of ST_Summary. Could it be more useful if better structured?

[strk]

ST_Summary is a debug function. It's meant for developers to look at what's in a value. It's implemented in lwgeom_debug.c. No need for structure. in/out db flag is likely worth putting in the output too

[pracine]

All right then!

[dustymugs]

Added in r11326