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

Paragon Corporation lr at pcorp.us
Wed Feb 10 19:30:16 PST 2010


 Pierre,

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.

Leo and I discussed this a little more, and there are a couple of things
that we find a bit annoying.  I guess mostly in semantics of the functions.


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

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

We were thinking that raster and band number are such commonly recurring
patterns in your functions that they deserve to be a compound type.  Though
what name to give that thing.  We are not sure and we don't like the name we
came up with (as it sounds too much like a band in a raster)
A raster band or rasterbandpair or something.  Though not sure what people
think since it does require more typing, but is clearer in purpose.

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);

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.

We really would have preferred the raster object to be an indexable thing,
but I don't think that is possible.  Like raster[1:3], raster[1]  .. as that
would be the shortest to write and still be clear.

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







-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Pierre
Racine
Sent: Wednesday, February 10, 2010 1:45 PM
To: PostGIS Development Discussion; postgis-users at postgis.refractions.net
Subject: Re: [postgis-devel] RFQ: WKT Raster SQL API for being able to
intersect vector and raster tables

ST_Intersects(raster,geometry) takes NODATA values into account. That means
a polygon could intersect with one band of a raster, but not with another
band of the same raster. So yes, we would have to compute ST_Shape() for all
bands in order to determine the "absolute" intersection of a raster. This is
time consuming.

I agree that it would make more sence NOT to default to a somewhat band
number... even if this is time consuming and have the chance to be able to
determine "absolute" intersection.

Normally ST_Intersects is used in conjunction with ST_Intersection where you
are interested in the intersection with one specific band. Why would you be
interested by the "absolute" intersection with a multi band raster?

To take into consideration is also the fact that for many dataset the areas
with NODATA values are the same is all the bands.

Also the fact that most people will store only 1 band datasets; hence the
convenience of not having to specify band #1.

I don't know. We might adjust the API with usage and users' comments.

What do you think?

Thanks for giving a look.

Pierre


>-----Original Message-----
>From: postgis-devel-bounces at postgis.refractions.net 
>[mailto:postgis-devel- bounces at postgis.refractions.net] On Behalf Of 
>Paragon Corporation
>Sent: 10 février 2010 12:03
>To: 'PostGIS Development Discussion'; 
>postgis-users at postgis.refractions.net
>Subject: Re: [postgis-devel] RFQ: WKT Raster SQL API for being able to 
>intersect vector and raster tables
>
>Pierre,
>
>Still busy with getting the stack builder ready, but quickly scanning 
>this, Leo and I had one question.
>
>It might be a stupid question -- so pelase educate us.
>
>Pierre,
>On the ST_Intersects(raster,geometry), ST_Intersection(raster,geometry)
>
>Why do you default the band to #1.  It would seem useful (or at least 
>we would assume), that if we don't pass in a band number, that the 
>function would return true/(vector envelope) if any of the bands 
>intersect with the geometry.  Or is that not of common use or is it 
>just more computationally intensive?
>
>Thanks,
>Regina and Leo
>
>
>
>-----Original Message-----
>From: postgis-devel-bounces at postgis.refractions.net
>[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of 
>Pierre Racine
>Sent: Wednesday, February 10, 2010 10:04 AM
>To: PostGIS Development Discussion; 
>(postgis-users at postgis.refractions.net)
>Subject: Re: [postgis-devel] RFQ: WKT Raster SQL API for being able to 
>intersect vector and raster tables
>
>Ok: it should have been "RFC" instead of "RFQ". I don't know what I was 
>thinking about...
>
>Pierre
>
>>-----Original Message-----
>>From: postgis-devel-bounces at postgis.refractions.net
>>[mailto:postgis-devel- bounces at postgis.refractions.net] On Behalf Of 
>>Pierre Racine
>>Sent: 8 février 2010 13:52
>>To: postgis-devel at postgis.refractions.net;
>>(postgis-users at postgis.refractions.net)
>>Subject: [postgis-devel] RFQ: WKT Raster SQL API for being able to 
>>intersect vector and raster tables
>>
>>Hi PostGIS folks,
>>
>>Now that you have a little bit of time after the release of PostGIS 
>>1.5, I would like to request your comments on the WKT Raster 
>>specifications drawn to meet objective 0.1.6 - "Being able to 
>>intersect vector and raster to produce vector". In other word: what 
>>set of function do we need to be able to intersect a geometry layer 
>>with a raster layer? You will find the last version of the written 
>>specs
>>here:
>>
>>http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWork, 
>>STing01#Obj
>>ective0.1.6e- Beingabletointersectvectorandrastertoproducevector
>>
>>This kind of operation is a generalisation of the operation needed by 
>>many people doing spatial analysis involving raster and vector. Some 
>>examples of users expressing their needs for a similar
>>functionality:
>>
>>http://postgis.refractions.net/pipermail/postgis-users/2009-April/0232
>>1
>>8.html
>>
>>http://postgis.refractions.net/pipermail/postgis-users/2009-March/0228
>>9
>>0.html
>>
>>Some from the r-sig-geo group:
>>
>>https://stat.ethz.ch/pipermail/r-sig-geo/2009-December/007177.html
>>
>>https://stat.ethz.ch/pipermail/r-sig-geo/2009-November/006999.html
>>
>>We plan on reusing as much as possible existing PostGIS functions. The 
>>basic idea is to convert (only
>>the) WKT Raster tiles involved in the intersect to geometries and then 
>>to procede to a normal vector intersection using the PostGIS 
>>intersection function. It involves functions like: 
>>ST_Envelope(raster), ST_ConvexHull(raster), ST_Shape(raster, integer), 
>>ST_AsPolygon(raster, integer), ST_AsWKTPolygon(raster, integer), 
>>ST_Intersects(raster, integer,
>geometry), ST_Intersection(raster, integer, geometry). Jorge is in 
>charge of the implementation.
>>
>>We are now in the process of testing if it is worth using the 
>>polygonize function of GDAL, thus linking with GDAL, or implementing 
>>our own. A summany of the pros and cons is available at this
>>location:
>>
>>http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking01#Th
>>e
>>prosandconsofusingGDALvsimpleme
>>ntingourownrasterservices
>>
>>We are also discussing the pros and cons of directly returning PostGIS 
>>geometry objects, thus having to link with PostGIS at the C level and 
>>all it involve in term of release management or to return WKT 
>>geometries and thus using PostGIS just at the SQL level, facilitating
>supports for former/newer PostGIS versions. An argument against linking 
>with PostGIS is available at this location:
>>
>>http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking01#Wh
>>y
>>isitimportnattoavoidlinkingwith
>>PostGIS
>>
>>The most cited tool to do such operation right now is StarSpan
>>(http://starspan.projects.atlas.ca.gov)
>>
>>There is plan to implement a raster/raster intersection function as 
>>well but the exact result of such an operation is still to determine.
>>
>>Thanks for your thoughts.
>>
>>Pierre
>>
>>_______________________________________________
>>postgis-devel mailing list
>>postgis-devel at postgis.refractions.net
>>http://postgis.refractions.net/mailman/listinfo/postgis-devel
>_______________________________________________
>postgis-devel mailing list
>postgis-devel at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
>_______________________________________________
>postgis-devel mailing list
>postgis-devel at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel





More information about the postgis-devel mailing list