PostGIS Core Development

Get a quote now!

Get a quote or read more about core development to add your support to a road-map item.

What is Core Development?

Core development adds new features to the open source projects in which we participate. The roadmap items to the right are projects that we consider important to the continued growth and maturity of these projects.

OpenGeo offers reduced rates on items from our core development roadmaps.

One common question we get is “Will this feature be in the next release?” The only way to ensure a feature is added on a particular schedule or before a particular release is to fund the development of that feature. We will combine your support with that of others until there is enough backing to complete the feature.

For more information see the FAQ.

Roadmap Items

Indexed Nearest Neighbor Searches

Currently nearest-neighbor searching is carried out with ad hoc tricks that expand a search radius until a candidate set is generated, then finding the closest value in the candidate set. A directly indexed approach would be optimally fast.

Faster Geodetic Functions

The geodetic GEOGRAPHY operations are currently very CPU intensive, because they involved multiple trancendental math calls. Performance could be improved through caching of calculations, both at a low level (coordinates) and a high level (data structures).

More Geodetic Functions

Support for ST_Union(), ST_Difference(), and true/false predicate tests calculated natively on the sphere for the GEOGRAPHY type introduced in PostGIS 1.5.

Asset Tracking Model

Tracking collections of moving objects, querying the historical data for relationships, and maintaining alarms when objects enter/leave areas is now a very common use case. The objects might be trucks, planes, boats, people, and so on. A standard data model, support functions, and API for efficient handling of this case would be helpful.

Higher Dimensional Index

The PostGIS spatial index currently works exclusively in the X/Y plane. For data such as fleet tracking the “Z” or “time” dimension can serve as a useful query restriction. Higher dimensional indexes are needed.

Linear Referencing Update

The LRS functions in PostGIS are a mismatched combination of functions that operate on measures and functions that use length as a proxy to measure. A re-work to formalize the LRS handling is needed.

Topological Coverage

The ISO SQL/MM model includes an extension for a topological coverage: a geometry model in which nodes and edges are the basic building blocks and area covers are built up from those primitives. This allows very fast tests for adjacency and geometry unions, as well as editing and simplifying shared lines.

Loose Geometry Matching

Geometry matching function in PostGIS are currently biased toward exact matches. However, spatial data is often “logically equivalent but physically disjoint” – the machine representations are close but not exact even though the geometries represent the same features.

Point Cloud Types

A POINTPATCH type, and associated index and functions, for handling the management of multi-terrabyte collections of LIDAR point data.

Business Intelligence Utilities

Functions to aggregate collections of records in useful ways for reporting, such as heat maps, influence polygons and clustering.

Better Estimated Extent

Client software, particularly software that does coordinate system reprojection, requires the extent of a layer in order to integrate it with other layers. Spatial databases are generally slow at returning that information.

R-Tree Index Packing

The PostGIS spatial index currently splits pages based on longest edge. This results in trees that have sub-optimal spatial clustering in the branches, which in turn makes for sub-optimal clustering. A packed R-Tree would provide the highest performance clustering.

Spatial Partitioning Indexes

For GIS data, spatial partitioning indexes (quadtree, kd-tree) have been shown to be significantly faster than more general balanced indexes (r-tree). PostGIS currently uses an r-tree index. Adding SP-GiST (a generic API for partitioned indexes) to PostgreSQL will allow much faster spatial searching in PostGIS.

Extra Dimensionality Support

The support for dimensions higher than X/Y is uneven as currently implemented. Most operations support clean handling of the Z dimension (but a few do not). A reasonable number of important functions do not support handling of the M dimension. This item would fix functions not handling higher dimensions.