[postgis-devel] ST_Intersection(raster, geom).val returning integer while expecting float

[Bborie Park]

On Sun, Dec 4, 2011 at 10:39 AM, Tom van Tilburg
<tom.van.tilburg at gmail.com> wrote:
> Thanks for pointing me out, I would have never guessed GDAL didn't (yet).
>
> However this raises another question: I don't understand why sometimes I can
> work with floating numbers with rasters in postgis.  (ie. doing a
> summarystats, but also reading the data in QGIS)
> Obviously I'm missing something.
>

You're not missing anything.  The question is "Does this function
operate in vector or raster space?".  ST_SummaryStats (and most other
functions) operate in raster space.  The current ST_Intersection
function operates in vector space where the raster is converted in
geometries and then processed.  I need to write the raster space
version of ST_Intersection within this month though.

In the end, there will be two types of raster functions, some that run
in vector space and some that run in raster space.  A good case in
point is ST_Intersects.  Any ST_Intersects function that looks like

ST_Intersects(raster, geometry)

has the internal operation done in raster space while any function
that looks like

ST_Intersects(geometry, raster)

has the internal operation done in vector space.  The order in which
the raster and geometry is passed into the function determines the
space that the function works in.

We decided to have functions that operate in both spaces because there
are situations where the answer you get can differ.  The standard case
I use is a corner of a triangular polygon touching a raster.

http://trac.osgeo.org/postgis/attachment/wiki/WKTRaster/SpecificationWorking03/st_intersects_triangle.png

As you can see, when the intersects test is done in vector space, the
raster converted to a geometry and the geometry intersects BUT if the
geometry is converted to raster, there is no intersection.

-bborie