[postgis-devel] RFQ: WKT Raster SQL API for being able to intersect vector and raster tables

Pierre Racine Pierre.Racine at sbf.ulaval.ca
Thu Feb 11 08:38:01 PST 2010


>I guess the 1 band compare case is the common norm.  I was more thinking
>about the ST_Intersects case when I just want to know if a non-novalue pixel
>intersect my geometry of interest and don't particularly care the band.  In
>those cases its likely all bands will if one does I guess.

When would like to do that? Any example?

>1) Why is it ST_Shape? Sounds so ESRI.  Sounds like that should be another
>data type - what's the difference between a shape and a geometry?
>I guess its mostly the ST_Shape vs. ST_AsPolygon.  We see the difference
>after your description, but the naming of the functions doesn't help much.
>Leo likes ST_Geometry(..) better though that still leaves a bit to be
>desired .  Unfortunately we don't have any
>thoughts on how to improve it. It just irks us. Perhaps its standard
>terminology that we are not too familiar with since we don't work with
>rasters much. :)

It is not standard terminology. I must say I have been strugling to find meaningful names for all those functions. I ended with ST_Shape because it "returns the general shape" of the withvalue pixels, taking NODATA values into account but not splitting same value areas into multiple polygon. There is also no equivalent to this function in PostGIS. This semantic is restricted to raster (and furthermore to raster having NODATA value).

I find ST_Geometry is too confusing with ST_AsPolygon. It might let users think that they will get a shapefile, but we can not stop living because ESRI called it a shapefile...

I am very willing to change it for something more meaningful. What about ST_Outline()? ST_Silhouette()? I like the first...

>2) The recurring pattern of raster, band number.  This especially becomes
>annoying when you get to ST_Intersection as the permutations of that are a
>bit mind boggling and also prevents the functions from ever being completely
>symmetric. raster , band, raster,band (raster, raster, band), raster, band,
>geometry

This is something we agreed with Paul and Frank at the last Code Sprint. I did not expect it would have such a ugly impact on all the functions though. There is a ST_Band(raster, band) -> raster function planned. You would have to use it with any function defaulting to the first band. This looks much like what you are suggesting below, no? One problem is the overload that is involved in computing a new raster every time...

>A raster band or rasterbandpair or something.  Though not sure what people
>think since it does require more typing, but is clearer in purpose.

I like "rasterband"...

>This would significantly reduce the permutations of ST_Intersection and
>would have a side benefit of validating that someone doesn't specify a band
>number that is higher than the number of bands before it ever hits the
>intersection functions.
>So general idea -- create a type
>
>a) CREATE TYPE raster_band(rast raster, band_num integer);
>
>
>b) You would have a function to create such types that would take in a
>raster and a band number - ST_RasterBand(raster, band_num);

So this function is not returning a raster but just a composite type. Right? That means there is no overhead raster copy?

>c) You would possibly have an autocast (I know I said autocasts were evil :)
>) that would convert a raster to a raster_band (setting band_num value to
>1).
>
>Then your ST_Intersection functions reduce to
>
>ST_Intersection(raster_band, geometry)
>ST_Intersection(geometry, raster_band)
>ST_Intersection(raster_band, raster_band)
>
>
>(with the autocast in most cases you can just pass in the raster) and it
>would take on the default behavior you describe.

In the simplest case both solutions reduce to:

ST_Intersection(raster, raster)

But in the worst case if I want to refer to band #2 I will have to do:

ST_Intersection(ST_RasterBand(raster, 2), ST_RasterBand(raster, 2))

Is this really simpler than:

ST_Intersection(raster, 2, raster, 2)?

Maybe it reduce the numbre of variant in the documentation but it does not really simplify the queries in general. What do you prefer to simplify: the doc or the queries?

>d) We hate ST_Intersection used to return Raster.  We think ST_Intersection
>should be set aside to just return geometry.  This is just too much
>overloading even for me.

What's wrong with overloading? The idea is to be able to put the parameter in whatever order you want so you don't always have to refer to the documentation to avoid mistakes.

>What Leo was thinking was  ST_IntersectionRaster  -- that alleviates the
>need of having the 'geometry', 'raster' and counting on that being spelled
>right and reduces the permutations a bit.
>
>So in the end you have
>
>ST_Intersection(raster_band, geometry)
>ST_Intersection(geometry, raster_band)
>ST_IntersectionRaster(raster_band, raster_band)
>ST_IntersectionRaster(raster_band, geometry)
>ST_IntersectionRaster(geometry, raster_band)
>
>Instead of 12 permutations.

You forget ST_Intersection(raster_band, raster_band) -> geometry set

Is really ST_IntersectionRaster(raster_band, raster_band) simpler than ST_Intersection(raster_band, raster_band, 'Raster')? The new name play no role in reducing the number of overload. The composite type does however.

If we make ST_RasterBand() -> rasterband we will also have to do ST_Band(raster, band) -> raster.

And why not support everything? Give flexibility to the user. And the variant are so trivial to write on our side.

Pierre



More information about the postgis-devel mailing list