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

Wed Feb 10 10:45:01 PST 2010

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/02321
>>8.html
>>
>>http://postgis.refractions.net/pipermail/postgis-users/2009-March/02289
>>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#The
>>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#Why
>>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