Geodetic Performance Summary
The new GEOGRAPHY type introduced in PostGIS 1.5 has allowed native support for data in longitude/latitude coordinates, with indexing and functions that work directly on the sphere, without issues over the dateline or poles. However, the performance of the functions against large objects (country boundaries, etc) is relatively slow compared to GEOMETRY.
Performance can be improved in three ways:
- Reduce the number of transcendental operations. Calculations on the sphere involve doing a number of calls to sin(), cos(), asin() and acos(), and enriching the data structures under the geography calculations could allow those values to be cached for each coordinate. This could provide a 50% performance boost.
- Apply "prepared geometry" sematics to geography. As in the geometry case, most calculations are called with one argument held constant while the second argument changes rapidly. By caching an index structure for the constant argument, performance can be improved by an order of magnitude.
- Use opportunistic indexing. For large objects, a simple edge index can be build in O(n) time for each object, then the calculation performed in O(lon(n) * lon(m)) time. This works for distance calculations, intersection calculations, and point-in-polygon operations.
Funding
This roadmap item is currently unfunded.
Get a quote now!
Get a quote or read more about core development to add your support to a road-map item.
Other Roadmap Items
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.
A POINTPATCH type, and associated index and functions, for handling the management of multi-terrabyte collections of LIDAR point data.
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.