What is the purpose of PostGIS on PostgreSQL?

If you re-wound the universe to early 2001, and not only let the inventors of PostGIS see the future, but also let the PSC of PgSQL see the future, perhaps PostGIS would be a series of patches on PgSQL. But at a minimum, if we had started as patches to core, the first thing we would have run up against is:

• core PgSQL areas don't support holes, but the GIS model really wants holes, can we change that?

And core PgSQL would have said: "no, of course not, areas have an existing well-understood semantic and we can't go making backwards incompatible changes like that".

As non-core developers, PostGIS was able to knock out monthly and 6-monthly releases for a number of years while PgSQL core plodded along with annual and longer releases. We were also able to add whatever features we wanted, whenever, since we had commit rights in our project, but gaining commit rights in PgSQL takes a Very Long Time.

By the time PostGIS was demonstrating enough external value that PgSQL core looked over and said to themselves "huh, that would have been nice to have in core as an extra feature", there was already so much code of such a different standard and style from PgSQL (not to mention under an incompatible license) that the idea of merging was not really possible.

Instead, PostGIS has become the canonical example of a Really Large Complex Extension that helps PgSQL remain modular and extensible. "How will this effect something like PostGIS" is a question often asked as core PgSQL evaluates some change. This is also a good thing, not perhaps quite as nice as PostGIS being part of core, but good enough.

There's other reasons, like the long list of dependencies PgSQL core would have hated to see, the generally lower code consistency and API cleanliness which they would have despaired of improving, and on and on. Even at conception, PostGIS was too big a hairball for PgSQL to swallow in one bite.

That's simply not true, PostgreSQL does not support Spatial data types. It supports geometric types. These are perfectly fine for some things, but they're totally separate from real world coordinate systems. Native types

• have no Spatial Reference System ID/SRSID.
• can never be re-projected.
• even on a spheroid, they provide very limited functionality.
• They're not standardized.
• They don't provide GIST indexes.

Update

As for the index question, it's in the FAQ

Why aren't PostgreSQL R-Tree indexes supported?

Early versions of PostGIS used the PostgreSQL R-Tree indexes. However, PostgreSQL R-Trees have been completely discarded since version 0.6, and spatial indexing is provided with an R-Tree-over-GiST scheme.

Our tests have shown search speed for native R-Tree and GiST to be comparable. Native PostgreSQL R-Trees have two limitations which make them undesirable for use with GIS features (note that these limitations are due to the current PostgreSQL native R-Tree implementation, not the R-Tree concept in general):

• R-Tree indexes in PostgreSQL cannot handle features which are larger than 8K in size. GiST indexes can, using the "lossy" trick of substituting the bounding box for the feature itself.

• R-Tree indexes in PostgreSQL are not "null safe", so building an index on a geometry column which contains null geometries will fail. [GiST indexes are null-safe]

PostGIS is a spatial database extender for PostgreSQL object-relational database. It adds support for geographic objects allowing location queries to be run in SQL.

SELECT superhero.name
FROM city, superhero
WHERE ST_Contains(city.geom, superhero.geom)
AND city.name = 'Gotham';

In addition to basic location awareness, PostGIS offers many features rarely found in other competing spatial databases such as Oracle Locator/Spatial and SQL Server. Refer to PostGIS Feature List for more details.

PostGIS Features list expands those capabilities as well:

PostGIS adds extra types (geometry, geography, raster and others) to the PostgreSQL database. It also adds functions, operators, and index enhancements that apply to these spatial types. These additonal functions, operators, index bindings and types augment the power of the core PostgreSQL DBMS, making it a fast, feature-plenty, and robust spatial database management system.

Feature List

The PostGIS 2+ series provides:

• Processing and analytic functions for both vector and raster data for splicing, dicing, morphing, reclassifying, and collecting/unioning with the power of SQL raster map algebra for fine-grained raster processing
• Spatial reprojection SQL callable functions for both vector and raster data Support for importing / exporting ESRI shapefile vector data via both commandline and GUI packaged tools and support for more formats via other 3rd-party Open Source tools

• Packaged command-line for importing raster data from many standard formats: GeoTiff, NetCDF, PNG, JPG

• Rendering and importing vector data support functions for standard textual formats such as KML,GML, GeoJSON,GeoHash and WKT using SQL Rendering raster data in various standard formats GeoTIFF, PNG, JPG, NetCDF, to name a few using SQL

• Seamless raster/vector SQL callable functions for extrusion of pixel values by geometric region, running stats by region, clipping rasters by a geometry, and vectorizing rasters 3D object support, spatial index, and functions Network Topology support Packaged Tiger Loader / Geocoder/ Reverse Geocoder / utilizing US Census Tiger data

Furthermore, to the points/parts mentioned already in this post. I would add as mentioned on the PostGIS website How it works

Since PostGIS is in C, it can make use of other libraries in C and C++, and it does so liberally. PostGIS depends on:

• GEOS for many geometry processing algorithms
• Proj.4 for coordinate re-projection functions
• GDAL for raster processing and format support
• LibXML2 for XML parsing
• JSON-C for JSON parsing
• SFCGAL for extended 3D support and additional geoprocessing algorithms