[raster]: ST_Envelope for raster that considers only data values

[robe]

This would be like our current ST_Envelop (we could add an optional arg). This would essentially return the envelop of a raster not considering no data values.

We can do this now with ST_Envelope(ST_Polygon ..) but that process is slow because it has to consider all pixels. This one wouldn't need to consider all pixels because it would start at the outer perimeter, collapse inward and stop checking once it hit a pixel with data, since the envelop can't get any smaller.

In dustymug's words:

We're looking for a boundary function rather than a polygon function (which includes holes for interior NODATA pixels). I'm looking for less than that — since I still expect it to be a rectangle, not a concave hull

[Bborie Park]

This is more like ST_ConvexHull() rather than ST_Envelope() as the returning geometry would take into account the raster's rotation.

What should the function be called? ST_Boundary()

[robe]

Can we just add a flag to ST_ConvexHull?

I don't want to call it ST_Boundary because in geometry (for polygon) that would return the linestrings that define the rings of the polygon/multipolygon. I fear people might thing it means that.

[Bborie Park]

I don't know if that'll work. This function requires a parameter for band number since bands may have different "edges".

ST_XXX(raster rast, nband integer DEFAULT NULL)

If nband = NULL, all bands are considered.

[robe]

How about signature:

ST_ConvexHull(raster rast, exclude_no_data = false, band_num=NULL);

If band_nun is NULL then (all bands are considered as is current behavior) meaning the first band to hit a road block wins.

e.g.

Let's say you have 3 bands and for the sake of silly argument, band 1 is nothing but no data, but band 2 has all pixels with data, and band 3 has some.

Then an ST_ConvexHull that excludes no data will return the same as ST_ConvexHull that includes no data — since band 2 hits its limit first. In theory if there is any band that does not have a no data value you can return the same as current ST_ConvexHull if no bands are explicitly specified.

If you specify band 3 then you get a possibly smaller rectangle than the original and if you specify band 1 you get an EMPTY POLYGON.

[Bborie Park]

The signature looks good. I'll have to see what the hiccups are with upgrading though.

[Bborie Park]

Modifying ST_ConvexHull() may be a no-go as that function signature is critical for the raster to geometry cast. From the looks of the docs (and the error that forced me to look at the docs)…

Cast implementation functions can have one to three arguments. The first argument type must be identical to or binary-coercible from the cast's source type. The second argument, if present, must be type integer; it receives the type modifier associated with the destination type, or -1 if there is none. The third argument, if present, must be type boolean; it receives true if the cast is an explicit cast, false otherwise. (Bizarrely, the SQL standard demands different behaviors for explicit and implicit casts in some cases. This argument is supplied for functions that must implement such casts. It is not recommended that you design your own data types so that this matters.)

​http://www.postgresql.org/docs/9.0/interactive/sql-createcast.html

That definitely will not work for us. So, different signature?

[Bborie Park]

After additional testing of the changed ST_ConvexHull(), I think that path is an absolute minefield. I think we're better off with a new signature.

[Bborie Park]

How about ST_MinConvexHull(rast raster, nband integer DEFAULT NULL)?

[robe]

That works for me.

[pracine]

A nice way to propagate the concept of "with value" pixels (in opposition to "nodata value"): ST_WithValueExtent()

[Bborie Park]

Added in r11118