[postgis-users] RE: WKT Raster project: call for fundings

[Pierre Racine]

Hi Tyler,

I CC people interested by raster support so they get an update on the progress of the project... I also CC to PostGIS Users (removed any private info).

I have a lot of experience in software development in the geospatial industry and I can tell you that with the money we gave to Sandro, he did a very professional and robust code base handling some very hard low level programming hard to handle for most programmers unfamiliar with object oriented database development like PostgreSQL.

We now have a georeferenced rasters type in PostgreSQL. Effective band data can be stored in-the-db or out-the-db (as JPEG or TIFF tiles). The type supports variable width & height (necessary for easy rasterization of vector layers and seamless raster/vector operations), nodata value, multiple band, georeference, and most pixel types supported. We can now go further with developing a tools for solving real problems...

Our plan goes as follow:

We need a tool (raster2pgsql) to import file based rasters (we will start with TIFF) into this db type. I plan to work on this in march and april. I'm going to the Toronto Code Sprint organized by Paul Ramsey in march (http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009) to discuss with people involved in the open source software industry (like Paul and Regina Obe (PostGIS) and Frank Warmerdam (GDAL)) about design issues and how to get GDAL (and maybe MapServer) to support WKT Raster. (As a key user, you could be there too...)

After having the importer I should attack the problem of intersection between raster layers and vector layers. For this we first need a good indexing infrastructure. This require RT_BBOX(), RT_Envelope() and RT_Shape(), to be used by the && and the RT_Intersects() operators. This indexing is what is going to make our system the fastest and the most robust in the world... No joke!

Then I can implement RT_Intersections() which is really the function we need. For this we need RT_AsPolygon() which will convert selected raster tiles (by the index) to polygons for intersecting using normal PostGIS functions.

I should have this by june 2009 if Sandro helps me with some esoteric indexing problems and other problems I'm not very familiar with. He could work on the "Being able to select RASTER values based on bbox spatial relation" section of the new updated schedule: http://www.cef-cfr.ca/index.php?n=Membres.PierreRacineWKTRaster. This is 2400$US though...

As discussed with Sandro, ST_RasterFromText() & ST_RasterFromWKB() are actually not very useful functions for now. We should focus on and only on everything leading to RT_Intersections().

Steve Cumming gave 2400$US to pay for Sandro's services and Martin Daly from CadCorp gave 2600$US. This was one month salary for Sandro (not counting our correspondence which is about one month work...) Steve is also paying me half time to work on the project. I should start in march but the way will be longer without Sandro.

See more comments below...

>-----Original Message-----
>From: Tyler Erickson [mailto:tyler.erickson at mtu.edu]
>Sent: 3 février 2009 12:21
>To: Sandro Santilli
>Cc: Pierre Racine
>Subject: Re: WKT Raster project: call for fundings
>
>Sandro,

...

>Our basic need is to combine fire perimeter boundaries (polygons) with a
>map of land classes (an indexed raster) and then pass the result to
>python for further processing.  There are around 100 land classes, and
>there are about 30 attributes for each land class that are stored in a
>separate PostGIS table.

As I mentionned in earlier mails. Your project is VERY similar to our one. So my WKT Raster roadmap should meet perfectly meet your needs (and the ones of many others).

>It looks like we could use the planned RT_Intersection (WKT Beta 0.2),
>RT_Intersects (WKT Beta 0.2) and RT_AsPolygon (WKT Raster Beta 0.1)
>functions to produce the results we need.  The land class raster would
>reside as a TIFF outside of PostGIS.

For better performance I would recommand storing inside the DB. Sandro could comment on this but from I know:

-in-db raster tile data will have a better byte alignment implying faster access (Sandro?)
-in-db tiles will be much simpler/faster (to read) than file based TIFF tiles (better byte alignment, no header, Sandro?)
-even though it is planned we have not plan yet to be able to seamlessy do RT_Intersection() with out-db tiles. This implies reading values from files and a bit more work. Sandro? 

>SELECT
>RT_AsPolygon(RT_Intersection(fireperimeter.polygon,cover.raster)) as raster,
>cover.id,
>fuelbeds.shrub, fuelbeds.duff_depth, fuelbeds.overstory
>FROM fireperimeter, cover
>INNER JOIN fuelbeds ON cover.id=fuelbeds.id
>WHERE RT_Intersects(fireperimeter.polygon,cover.raster);

Actually your query would look a bit more simple:

SELECT
RT_Intersection(fireperimeter.polygon,cover.raster) as raster,
cover.id, fuelbeds.shrub, fuelbeds.duff_depth, fuelbeds.overstory
FROM fireperimeter, cover
INNER JOIN fuelbeds ON cover.id=fuelbeds.id
WHERE RT_Intersects(fireperimeter.polygon,cover.raster);

The default behaviour of RT_Intersection() (as specified in slide 29)  is to return geometries...

>Given these needs, I would like to tie our contribution to the "Being
>able to intersect vector and raster to produce vector"  section of WKT
>Raster Beta 0.1 which contains the RT_AsPolygon function and the vector
>output forms of the RT_Intersects/RT_Intersection functions.  

Again it would be nice if you agree with Sandro about everything included in the "Being able to select RASTER values based on bbox spatial relation" section of the new schedule.

We need your contribution Tyler!

Pierre