PostGIS Roadmap
Get a quote now!
Get a quote on road-map development and add your support to a road-map item.
PostGIS @ OpenGeo
Paul has worked on geospatial software for over 13 years, as a programmer and consultant. He co-founded the PostGIS spatial database project in 2001, and is an active developer and project steering committee member.
Roadmap Items
A POINTPATCH type, and associated index and functions, for handling the management of multi-terrabyte collections of LIDAR point data.
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.
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.
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.
Business Intelligence Utilities
Functions to aggregate collections of records in useful ways for reporting, such as heat maps, influence polygons and clustering.
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.
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.
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.
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 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.
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.
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).
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.