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
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.
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).
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.
A POINTPATCH type, and associated index and functions, for handling the management of multi-terrabyte collections of LIDAR point data.
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.
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.
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.
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.
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.
Business Intelligence Utilities
Functions to aggregate collections of records in useful ways for reporting, such as heat maps, influence polygons and clustering.
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.
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.
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.
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.