PostGIS Raster Planning and Funding

Quick Links

• PostGIS Raster Home Page

• Working Specifications for Future Versions
• Old Specifications for PostGIS 2.0
• Old Specifications for Beta 0.1.6

• Documentation

This is the development page of PostGIS Raster - a project extending PostGIS engine with raster support.

Need more PostGIS Raster features? - If you need support for raster in ​PostgreSQL or you have to do raster/vector operations, help us develop PostGIS Raster! PostGIS Raster development is a work in progress. Each slice of 2000$ will bring new functions in!

Time or Money - You can contribute with money or developer time (DevTime). Contributing give you the opportunity to have a word to say on the development priorities and on the schedule.

Coders have to be experienced C developer with a minimal object oriented database development experience. There are some developers out there willing to offer their services to implement your needs.

Expectations - We expect that contributors will:

• Try to follow the roadmap or at least arrange it to fit their particular needs as much as possible in accordance with the existing roadmap. The planning is divided into coherent groups of tasks. We are very flexible on modifying the content of those groups.
• Contribute to the specifications in order to come to an agreement on how things should be done and to keep track of what's done. Specifications of the intented development should be described in the Specifications page and submited to the postgis-devel mailing list for comments before starting development. Ask ​Pierre Racine to get write access to the specification page.
• Contribute to the Documentation as much as they can to make sure we produce a coherent and a professional open source product. Specifications should details the new functionality and be written so they can be used as a reference to document the new feature.

Advices to developers - We can assure degree of quality with obeying basic rules and development cycle process, most of them are easily executable:

1. If you add new C API function, always add test case for it in test/core.
2. If you add new SQL function, always add test case for it in test/regress.
3. Always do full build of PostGIS Raster before commit (with new tests included).
4. Always run all PostGIS Raster unit tests before commit (with new tests included).
5. Do not commit anything if any of the two occurs: a) PostGIS Raster build failed b) PostGIS Raster tests failed.
6. Try to do full rebuild and full tests run of all related components: GEOS + PostGIS + PostGIS Raster.
7. Frequently check if PostGIS Raster build is "green" in the very our :-) Hudson bay ​http://office.refractions.net:1500/view/WKTRaster/
8. Don't worry if something got broken after a commit. A broken code is a daily bread and errors are valuable. Just don't let buggy commits to accumulate, but fix as soon as first error is spotted.
9. Adding new test cases are the only time consuming element, but even a very simple test is worth (i.e. test/regress/rt_box2d.sql)

Objectives & Tasks - are arranged into coherent groups: Similar functions together and dependencies first.

Developers having worked or available for future work on the project

PostGIS Raster development team members with officially allocated tasks:

• ​Mateusz Loskot (ML) at ​Cadcorp
• ​Pierre Racine (PR) at ​University Laval
• ​Sandro Santilli (SS)
• ​Jorge Arévalo (JA) at ​Deimos Space
• ​Bborie Park (BP) at ​the Center for Vectorborne Diseases
• ​David Zwarg (DZ) at (​Azavea, Inc.)

Unofficial PostGIS Raster development members with unofficially allocated tasks:

• ​Regina Obe (RO) at (​Paragon Corporation)

Funding Contributors

Prime financial contributors who established development of the PostGIS Raster project:

• ​Steve Cumming (SC), (​University Laval): All of Pierre Racine's time (from June 2008 up to July 2012).
• ​Martin Daly (MD), (​Cadcorp): All of Mateusz Loskot's time (about six months up to june 2009).
• ​Tyler Erickson (TE), (​Michigan Tech Research Institute): $1200 USD
• ​DEIMOS Space (DS): All of Jorge Arevalo time (about two year up to June 2011).
• ​Center for Vectorborne Diseases at UC Davis (UC): All of Bborie Park time (from March 2010 up to July 2012).

RoadMap

• Write a "Best practices for storing raster in PostGIS"
• Write a "Best practices for third party applications wishing to read raster stored in PostGIS"
• Break up RASTER_mapAlgebra2 so that the main engine is in rt_core instead of rt_pg. This is needed for C-based aggregate functions that run against MapAlgebra.
• Optimized version of two rasters ST_MapAlgebra setting pixel areas when possible instead of just pixels by pixels
• Multi-band ST_AddBand()
• Different variant of ST_SetValues()
• C version of the ST_Union(raster) aggregate
• ST_UnionToRaster() and ST_BurnToRaster()
• MultiBand MapAlgebra(raster, raster)
• ST_CreateOverview(), ST_IsRegularlyTiled(), ST_HasOverlaps(), ST_HasGaps(), ST_HasTileSameSize(), ST_HasTileAligned()
• ST_Retile()
• Subtiling of rasters (PostGIS 3.0 or create a new raster type)
• Set and update of the IsNodataValue flag indicating the whole band is nodata.