Opened 6 years ago

Closed 6 years ago

#2280 closed enhancement (fixed)

[raster] ST_Summary(raster)

Reported by: strk Owned by: Bborie Park
Priority: medium Milestone: PostGIS 2.1.0
Component: raster Version: trunk
Keywords: history Cc:

Description

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 !

Change History (18)

comment:1 Changed 6 years ago by strk

Component: postgisraster
Owner: changed from pramsey to Bborie Park

comment:2 Changed 6 years ago by strk

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

comment:3 Changed 6 years ago by 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

comment:4 Changed 6 years ago by strk

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

comment:5 Changed 6 years ago by Bborie Park

Milestone: PostGIS FuturePostGIS 2.1.0
Status: newassigned
Summary: ST_Summary(raster)[raster] ST_Summary(raster)

Can do...

comment:6 Changed 6 years ago by Bborie Park

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...

comment:7 Changed 6 years ago by 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

comment:8 Changed 6 years ago by pracine

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

comment:9 Changed 6 years ago by 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.

comment:10 Changed 6 years ago by Bborie Park

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().

comment:11 Changed 6 years ago by 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).

comment:12 Changed 6 years ago by Bborie Park

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

comment:13 Changed 6 years ago by pracine

ST_Metadata(), ST_BandMetadata()

comment:14 Changed 6 years ago by 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.

comment:15 Changed 6 years ago by 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?

comment:16 Changed 6 years ago by 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

comment:17 Changed 6 years ago by pracine

All right then!

comment:18 Changed 6 years ago by Bborie Park

Keywords: history added
Resolution: fixed
Status: assignedclosed

Added in r11326

Note: See TracTickets for help on using tickets.