Geodetic Functions 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 number of functions currently supported is low, and more functions would make the GEOGRAPHY type more useful.
The functions currently supported in GEOGRAPHY are
- ST_Area(GEOGRAPHY)
- ST_Length(GEOGRAPHY)
- ST_Distance(GEOGRAPHY, GEOGRAPHY)
- ST_DWithin(GEOGRAPHY, GEOGRAPHY, DISTANCE)
- ST_Perimeter(GEOGRAPHY)
This roadmap item would add support for
- ST_Union(GEOGRAPHY, GEOGRAPHY)
- ST_Difference(GEOGRAPHY, GEOGRAPHY)
- ST_Intersection(GEOGRAPHY, GEOGRAPHY)
- ST_Intersects(GEOGRAPHY, GEOGRAPHY)
- ST_Contains(GEOGRAPHY, GEOGRAPHY)
- ST_Within(GEOGRAPHY, GEOGRAPHY)
- ST_Buffer(GEOGRAPHY, DISTANCE)
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 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.
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.
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.