Business Intelligence Utilities
Business intelligence applications take collections of data and provide succinct analysis, usually in graphical or tabular form. Aggregating spatial data into visually useful proxies can be difficult as data volumes grow. Tools like spatial union or collection can only go so far.
This enhancement would provide a few common tools for turning a collection of spatial information into a single visualization.
- ST_FrequencySurface([pointarray]) would take in an array of points (a simple aggregate variant could also be provided) and create a surface based on the frequency of points falling close to one another. The resulting surface could be passed to heat mapping, contouring, or polygon creation functions.
- ST_InterpolatedSurface([pointarray]) would take in an array of points (a simple aggregate variant could also be provided) and create a surface based on the z-values of the points. This would be useful for creating surfaces from measuring stations or other point-based sensors.
- ST_HeatMap([surface]) would take in a gridded surface object and output a PNG bytearray suitable for streaming to a client program.
- ST_Contour([surface],minvalue,maxvalue,interval) would take in a gridded surface object and output a multilinestring of contours, with the magnitude value encoded in the z-ordinate. If minvalue equals maxvalue, only one contour line will be returned.
- ST_Cluster([pointarray]) would take in an array of points and return a set of points that represent the clustering of those points. The API here will need some extra work to encapsulate as many use cases as possible.
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 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.
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.
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.