Topological Coverage Summary
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.
The common example of the topological model is the ESRI "Coverage" model used in the early Arc/INFO workstation GIS systems. Coverage models have the advantage of not storing duplicate data for shared edges, and providing more efficient implementations of GIS operations like dissolves and overlays than are available using a "simple features" model.
The disadvantage of coverage models is the specialized tools required for editing features, to handle the relationships between features that share boundaries. Changing a boundary from a single shared edge to multiple un-shared edges can take a good deal of work without a specialized topology editing client.Topological coverage models are common in the cadastral data arena, because the parcel fabric is made up of non-overlapping, or hierarchically constructed entities that share boundaries regularly. The TIGER/Census data in the United States is another example of a large-scale topological coverage.
Implementation of coverages will include the following items:
- Harmonization of existing
topology/prototype with current SQL/MM model - Addition of topology building functions to create a topology from a set of polygons
- Completion of topology functions to allow extraction of polygons from topology model
- Implementation of topology overlay to turn two topologies into a new resultant
- Implementation of topology functions to allow dissolve operations on topology models
Funding
This roadmap item is currently unfunded.
Add your support for this item by contacting us for a quote and discussion of the particular features you need.
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
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.
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.
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.