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

[Pierre Racine]

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/SpecificationWorking01#Objective0.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/023218.html
>
>http://postgis.refractions.net/pipermail/postgis-users/2009-March/022890.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#TheprosandconsofusingGDALvsimpleme
>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#Whyisitimportnattoavoidlinkingwith
>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