wiki:WKTRaster/PlanningAndFunding

PostGIS Raster Planning and Funding

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:

Unofficial PostGIS Raster development members with unofficially allocated tasks:

Funding Contributors

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

RoadMap

The RoadMap is now in the specification page.

Last modified 20 months ago Last modified on Jan 29, 2015 3:11:23 PM