PostGIS opens the future of open source spatial database (1)
In 1986, Professor Michael Stonebraker of the University of California at Berkeley led the Postgres project, which was the predecessor of PostgreSQL. Later, PostGIS appeared. PostGIS is an extension of the object-relational database system PostgreSQL. Its appearance makes people begin to pay attention to the spatial expansion method based on database management systems, and it is expected that PostGIS will become the mainstream technology for managing spatial data in the future.
Because spatial data has the characteristics of spatial location, unstructured, spatial relationship, classification and coding, and massive data, general commercial database management systems cannot meet the requirements.
In order to improve the ability of database management system (DBMS) to manage spatial data, there have been successive appearances at home and abroad: file and relational database hybrid management system, full relational spatial database management system, relational database + spatial data engine, extended object relational database Management system, and object-oriented spatial database management system and other solutions. At present, the more popular ones at home and abroad mainly focus on "relational database + spatial data engine" and "extended object relational database" .
"Relational database + spatial data engine" is usually a middleware solution developed by GIS vendors in recent years. Users hand over their own spatial data to a spatial data engine independent of the database. There is a spatial data engine to organize the storage of spatial data in a relational database; when the user needs to access the data, the spatial data engine is notified that there is an engine Extract data from relational databases and transform it into a way that customers can use.
Therefore, a relational database is only a container for storing spatial data, and a spatial data engine is a conversion channel for spatial data to enter and exit the container. Typical representatives of this type of system are ESRI's ArcSDE and MapInfo's SpatialWare. Its advantages are fast access speed, support for general relational database management system, spatial data access according to BLOB , cross-database platform, close integration with specific GIS platform, and flexible application. Its shortcomings are mainly manifested in that spatial operations and processing cannot be implemented in the database kernel, the data model is more complex, it is difficult to extend SQL, and it is not easy to achieve data sharing and interoperability.
The extended object relational database management system is a solution for managing spatial data developed by database vendors. Because it is difficult for relational databases to manage unstructured data (including spatial data), database vendors have borrowed from object-oriented technology and developed object-relational database management systems.
This system supports the definition of abstract data types (ADT) and related operations; users can use this ability to increase spatial data types and related functions, thereby transferring spatial data types and functions from middleware (spatial data engine) to the database In the management system, customers do not need to use the special interface of the spatial data engine for programming, but use the standard extended SQL language with the added spatial data types and functions to manipulate spatial data.
Such products that support spatial expansion include Oracle's Oracle Spatial, IBM's DB2 Spatial Extender, and Informix's Spatial DataBlade. The advantage is that the management of spatial data is integrated with the general database system. The spatial data is accessed by object, and spatial operation and processing can be realized in the database kernel. It is more convenient to extend SQL, and it is easier to realize data sharing and interoperability. Its shortcomings are mainly manifested as the difficulty of implementation and the difficulty of compressing data. There is still a gap between the current functions and performance of the first-type system.
At present, the most outstanding database software in the field of open source spatial information software is the PostgreSQL database, and the spatial object extension module PostGIS built on it makes it a truly large spatial database.
Originated from PostgrSQL
In 1986, Professor Michael Stonebraker of the University of California at Berkeley led the Postgres project, which was the predecessor of PostgreSQL. The results of this project are very significant, and a lot of contributions have been made in many aspects of modern databases, such as object-oriented databases, partial indexing techniques, rules, procedures, and database extensions. At the same time, Stonebraker incorporated PostgreSQL into the BSD copyright system, making PostgreSQL widely used in various scientific research institutions and some public service organizations.
Some basic collection entity types have been defined in PostgreSQL. These types include: POINT, LINE, LSEG, BOX, POLYGON, CIRCLE, etc.; PostgreSQL defines a series of functions and operators to implement geometric operations and operations; at the same time, PostgreSQL introduces the spatial data index R-tree.
Although PostgreSQL provides the above-mentioned features that support spatial data, the spatial features it provides are difficult to meet the requirements of GIS, mainly in: lack of complex spatial types; no spatial analysis; no projection transformation function. In order to make PostgreSQL provide better spatial information services, PostGIS came into being.
Introduction to PostGIS
PostGIS is an extension of the object-relational database system PostgreSQL. PostGIS provides the following spatial information service functions: spatial objects, spatial indexes, spatial operation functions and spatial operators. At the same time, PostGIS follows the specifications of OpenGIS.
The copyright of PostGIS is included in the GNU GPL, which means that anyone can freely obtain the source code of PostGIS and do research and improvement on it. It is precisely because of this that PostGIS has developed rapidly, and more and more enthusiasts and research institutions have participated in the development and improvement of PostGIS applications.
PostGIS development history
PostGIS was developed by Refractions Research Inc. Refractions is a GIS and database consulting company. Refraction initially studied the implementation of spatial databases on the basis of PostgreSQL. The spatial data types and functions provided by PostgreSQL are far from meeting the needs of GIS. , Research work often falls into a dilemma. The end result is often a lot of manpower and material resources, but the product is extremely complex and low performance. These reasons directly or indirectly contributed to the implementation of the PostGIS project.
The implementation of PostGIS has not been smooth sailing. It was not until the release of PostgreSQL 7.1 that the implementation of PostGIS became possible. The main reason was that the maximum record size supported by PostgreSQL before version 7.1 was 8Kb. Since 7.1, PostgreSQL has abandoned this limitation. Even with binary storage, spatial data objects often exceed 8Kb. If this restriction exists, the storage of spatial data is impossible.
With the elimination of this restriction, PostGIS research and development began in April 2001, and the first version of PostGIS (PostGIS V0.1) was released in May 2001. In the first version of PostGIS, it mainly includes spatial databases, spatial data objects using standard representations, spatial indexes that support quick query, and some simple analysis functions (such as area and length). The spatial data object types supported in PostGIS V0.1 include: point, line, polygon, geometric object types, and multi-point, multi-line, and multi-polygon geometric object types.
PostGIS V0.2, released in May 2001, added support for binary representation under the Windows platform and provided help documents for new users. However, users reported that the function naming of PostGIS did not follow the OpenGIS standard.
PostGIS V0.5 was released in July 2001. PostGIS added all the existing functional functions of OpenGIS and maintained the same naming of the functions. 24 OpenGIS access functions have been added, and non-standard original functions equivalent to these functions have been deleted.
With financial support from the British Columbia government, support for calculating the length of the sphere surface has also been added to version 0.5. In the same period, Refractions transplanted the digital road atlas of British Columbia to PostGIS, and used the model and data conversion function of the database to provide support for atlas customers (ambulance dispatch, emergency response, and other municipal affairs, etc.).
Another reason why PostGIS V0.5 is important is the release of Mapserver from the University of Minnesota. The Mapserver of the University of Minnesota is an open source Internet map publishing engine, just like ESRI's ArcIMS system, Mapserver also adds support for PostGIS.
-
PostGIS opens the future of open source spatial database (2)
In Mapserver, a Web-driven interface is provided, which is used to check the spatial characteristics of data in the database. In PostGIS, in order to enable Mapserver to provide better services, PostGIS provides a data source that is easy to read and write. This data source will play its role when the network is busy. For example, if a standard GIS file is used as the data source, if two users write to the same file concurrently, this will inevitably lead to operational conflicts, and PostGIS can solve this defect well. Ensure data integrity.
In September 2001, PostGIS V0.6 was released. PostGIS V0.6 provided complete OpenGIS support, added a standard metadata table, and provided support for spatial reference system identification. In addition, 12 functional functions supported by OpenGIS have been added, and the support for Mapserver has been further enhanced.
In February 2002, PostgreSQL V7.2 was released. In version 7.2, the API function of GIST index was improved a little. Because these API functions are also used in PostGIS, this has brought trouble to the application of PostGIS V0.6, prompting PostGIS to make improvements to adapt to the changes in PostgreSQL. PostGIS V0.7 was released in 2002. In version 0.7, it provided new API function support for GIST, and in this version, it provided support for coordinate transformation.
From 2002 to now, PostGIS has successively released a series of new versions. While inheriting the original advantages of PostGIS products, these PostGIS products have made further improvements to the problems and deficiencies of PostGIS itself. Up to now, the latest version of PostGIS is PostGIS V1.1.4. The main improvements of PostGIS V1.1.4 include: (1) Provides support for the upcoming PostgreSQL V8.2; (2) Fixes the bugs in the function collect; (3) Increases the matching check of SRID in MakeBox2d and MakeBox3d; (4) Improves Improved the running concurrency of pgsql2shp; ⑸ Further improved the support for Java.
PostGIS features
PostGIS supports all spatial data types, including: POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, and GEOMETRYCOLLECTION )Wait. PostGIS supports all object expression methods, such as WKT and WKB.
PostGIS supports all data access and construction methods, such as GeomFromText(), AsBinary(), and GeometryN().
PostGIS provides simple spatial analysis functions (such as Area and Length) as well as other functions with complex analysis functions, such as Distance.
PostGIS provides support for metadata, such as GEOMETRY_COLUMNS and SPATIAL_REF_SYS. At the same time, PostGIS also provides corresponding support functions, such as AddGeometryColumn and DropGeometryColumn.
PostGIS provides a series of binary predicates (such as Contains, Within, Overlaps and Touches) to detect the spatial relationship between spatial objects, and returns a Boolean value to characterize the relationship between objects.
PostGIS provides spatial operators (such as Union and Difference) for spatial data manipulation. For example, the Union operator fuses the boundaries between polygons. Two overlapping polygons will form a new polygon through the Union operation. The boundary of this new polygon is the largest boundary of the two polygons.
PostGIS also provides the following functions:
Database coordinate transformation
The geometry type in the database can be transformed from one projection system to another projection system through the Transform function. Geometry types in OpenGIS all use SRID as part of their structure, but for unknown reasons, Transform is not introduced in the SFSQL specification of OpenGIS.
Sphere length calculation
The collection type stored in the general geographic coordinate system cannot be calculated without coordinate transformation. The coordinate transformation provided by OpenGIS makes it possible to calculate the degree of accumulation type.
Three-dimensional geometry type
The SFSQL specification is only for two-dimensional collection types. OpenGIS provides support for 3D collection types, specifically using the input collection type dimension to determine the output representation. For example, even if all geometric objects are internally stored in three-dimensional form, pure two-dimensional intersections are usually returned in two-dimensional form. In addition, it also provides the function of converting geometric objects between different dimensions.
Spatial aggregate function
In the database, an aggregate function is a function that performs all data operations on a certain attribute column. For example, Sum and Average, Sum is the sum of the data of a certain relational attribute column, and Average is the average of the data of a certain relational attribute column. Corresponding to this, the spatial aggregate function also performs the same operation, but the object of the operation is spatial data. For example, the aggregate function Extent returns the largest wrapped rectangle in a series of elements. For example, the execution result of the SQL statement "SELECT EXTENT(GEOM) FROM ROADS" is to return all the wrapped rectangles in the ROADS data table.
Raster data type
PostGIS provides storage for large raster data objects through a new data type slice. The slice is composed of the following parts: wrapped rectangle, SRID, type and a byte sequence. By controlling the size of the slice below the database page value (32×32), fast random access becomes possible. Generally large pictures are also stored in the database by cutting them into 32×32 pixel slices.
PostGIS development outlook
At present, due to the advantages of "relational database + spatial data engine" technical solutions that are quickly accessed and closely connected with GIS, it has certain advantages in applications. However, the spatial data engine is independent of the database core, and it is difficult to make full use of each of the relational databases. This mature data management and access technology has become the Achilles heel of further development. In addition, it is difficult to support extended SQL, and data sharing and interoperability are gradually exposed.
Although the object-oriented spatial database management system is most suitable for the expression and management of spatial data, it not only supports variable-length records, but also supports the nesting of objects, the inheritance and aggregation of information. The object-oriented database management system has been researched for more than ten years. Due to the lack of a good data foundation, there has not been a major breakthrough in access speed and it is difficult to develop maturely. It is estimated that the object-oriented database management system will not be able to Replacement object relational database management system.
The extended object relational database management system will undoubtedly become the future development direction. Although the performance of PostGIS/PostgreSQL and Spatial Oracle still has a certain gap with ArcSDE, as database vendors continue to pay attention to the spatial data management market, further integration of structured data management methods and spatial data management methods, and data compression transmission technology With the continuous improvement of the database management system, the spatial expansion method based on the database management system will be continuously improved and become the mainstream technology for managing spatial data in the future. Most GIS vendors should focus on spatial analysis, spatial models, etc., so as to form a better social division of labor structure.
Currently, software open source has become a development trend in the IT industry, and more and more software is added to the open source system. PostGIS does not lag behind the spatial database of commercial GIS platforms in terms of function or scalability, and because of the openness of its source code, it is easier to attract fans to participate in the development of PostGIS, continuously improving existing functions and further expanding With new features, I believe PostGIS will have a very bright future.