Au commencement

Dans les premiÚres implémentations :term:`SIG` historiques, toutes les données spatiales étaient stoquées sous la forme de fichiers plats et certaines applications

:term:`SIG` spécifiques étaient nécessaires pour interpréter et manipuler les données.

System Message: ERROR/3 (<string>, line 29); backlink

Unknown interpreted text role "term".

Ces outils de gestion de premiÚre génération, avaient été conçu pour répondre aux besoins des utilisateurs pour lesquels toute les données étaient localisé au sein de leur agence. C'est outils étaient propriétaire, des systÚme specifiquement créé pour gérer les données spatiales.

La seconde génération des systÚmes de gestion de données spatiales stoque certaines données dans une base de données relationelle

Second-generation spatial systems store some data in relational databases (usually the "attribute" or non-spatial parts) but still lack the flexibility afforded with direct integration.

Effectivement, les bases de données spatiales sont nés lorsque les gens ont commencé à considérer les objet spatiaux comme des objets de base de données.

Spatial databases fully integrate spatial data with an object relational database. The orientation changes from GIS-centric to database-centric.

Spatial Data Types

An ordinary database has strings, numbers, and dates. A spatial database adds additional (spatial) types for representing geographic features. These spatial data types abstract and encapsulate spatial structures such as boundary and dimension. In many respects, spatial data types can be understood simply as shapes.

Spatial data types are organized in a type hierarchy. Each sub-type inherits the structure (attributes) and the behavior (methods or functions) of its super-type.

Spatial Indexes and Bounding Boxes

An ordinary database provides "access methods" -- commonly known as indexes -- to allow for fast and random access to subsets of data. Indexing for standard types (numbers, strings, dates) is usually done with B-tree indexes. A B-tree partitions the data using the natural sort order to put the data into a hierarchical tree.

The natural sort order of numbers, strings, and dates is simple to determine -- every value is less than, greater than or equal to every other value. But because polygons can overlap, can be contained in one another, and are arrayed in a two-dimensional (or more) space, a B-tree cannot be used to efficiently index them. Real spatial databases provide a "spatial index" that instead answers the question "which objects are within this particular bounding box?".

A bounding box is the smallest size rectangle capable of containing a given feature.

Bounding boxes are used because answering the question "is A inside B?" is very computationally intensive for polygons but very fast in the case of rectangles. Even the most complex polygons and linestrings can be represented by a simple bounding box.

Indexes have to perform quickly in order to be useful. So instead of providing exact results, as B-trees do, spatial indexes provide approximate results. The question "what lines are inside this polygon?" will be instead interpreted by a spatial index as "what lines have bounding boxes that are contained inside this polygon's bounding box?"

The actual spatial indexes implemented by various databases vary widely. The most common implementation is the R-tree (used in PostGIS), but there are also implementations of Quadtrees, and grid-based indexes in shipping spatial databases.

Spatial Functions

For manipulating data during a query, an ordinary database provides functions such as concatenating strings, performing hash operations on strings, doing mathematics on numbers, and extracting information from dates. A spatial database provides a complete set of functions for analyzing geometric components, determining spatial relationships, and manipulating geometries. These spatial functions serve as the building block for any spatial project.

The majority of all spatial functions can be grouped into one of the following five categories:

1. Conversion: Functions that convert between geometries and external data formats.
2. Management: Functions that manage information about spatial tables and PostGIS administration.
3. Retrieval: Functions that retrieve properties and measurements of a Geometry.
4. Comparison: Functions that compare two geometries with respect to their spatial relation.
5. Generation: Functions that generate new geometries from others.

The list of possible functions is very large, but a common set of functions is defined by the :term:`OGC` :term:`SFSQL` and implemented (along with additional useful functions) by PostGIS.

But what is PostgreSQL?

PostgreSQL is a powerful, object-relational database management system (ORDBMS). It is released under a BSD-style license and is thus free and open source software. As with many other open source programs, PostgreSQL is not controlled by any single company, but has a global community of developers and companies to develop it.

PostgreSQL was designed from the very start with type extension in mind -- the ability to add new data types, functions and access methods at run-time. Because of this, the PostGIS extension can be developed by a separate development team, yet still integrate very tightly into the core PostgreSQL database.

Why not Shapefiles?

The shapefile (and other file formats) have been the standard way of storing and interacting with spatial data since GIS software was first written. However, these "flat" files have the following disadvantages:

• Files require special software to read and write. SQL is an abstraction for random data access and analysis. Without that abstraction, you will need to write all the access and analysis code yourself.
• Concurrent users can cause corruption. While it's possible to write extra code to ensure that multiple writes to the same file do not corrupt the data, by the time you have solved the problem and also solved the associated performance problem, you will have written the better part of a database system. Why not just use a standard database?
• Complicated questions require complicated software to answer. Complicated and interesting questions (spatial joins, aggregations, etc) that are expressible in one line of SQL in the database take hundreds of lines of specialized code to answer when programming against files.

Most users of PostGIS are setting up systems where multiple applications will be expected to access the data, so having a standard SQL access method simplifies deployment and development. Some users are working with large data sets; with files, they might be segmented into multiple files, but in a database they can be stored as a single large table.

In summation, the combination of support for multiple users, complex ad hoc queries, and performance on large data sets are what sets spatial databases apart from file-based systems.

A brief history of PostGIS

In the May of 2001, Refractions Research released the first version of PostGIS. PostGIS 0.1 had objects, indexes and a handful of functions. The result was a database suitable for storage and retrieval, but not analysis.

As the number of functions increased, the need for an organizing principle became clear. The "Simple Features for SQL" (:term:`SFSQL`) specification from the Open Geospatial Consortium provided such structure with guidelines for function naming and requirements.

With PostGIS support for simple analysis and spatial joins, Mapserver became the first external application to provide visualization of data in the database.

Over the next several years the number of PostGIS functions grew, but its power remained limited. Many of the most interesting functions (e.g., ST_Intersects(), ST_Buffer(), ST_Union()) were very difficult to code. Writing them from scratch promised years of work.

Fortunately a second project, the "Geometry Engine, Open Source" or GEOS, came along. The GEOS library provides the necessary algorithms for implementing the :term:`SFSQL` specification. By linking in GEOS, PostGIS provided complete support for :term:`SFSQL` by version 0.8.

As PostGIS data capacity grew, another issue surfaced: the representation used to store geometry proved relatively inefficient. For small objects like points and short lines, the metadata in the representation had as much as a 300% overhead. For performance reasons, it was necessary to put the representation on a diet. By shrinking the metadata header and required dimensions, overhead greatly reduced. In PostGIS 1.0, this new, faster, lightweight representation became the default.

Recent updates of PostGIS have worked on expanding standards compliance, adding support for curve-based geometries and function signatures specified in the ISO :term:`SQL/MM` standard. Through a continued focus on performance, PostGIS 1.4 significantly improved the speed of geometry testing routines.

Who uses PostGIS?

For a complete list of case studies, see the PostGIS case studies page.

What applications support PostGIS?

PostGIS has become a widely used spatial database, and the number of third-party programs that support storing and retrieving data using it has increased as well. The programs that support PostGIS include both open source and proprietary software on both server and desktop systems.

The following table shows a list of some of the software that leverages PostGIS: