How It Works

PostGIS adds extra types (geometry, geography, raster and others) to the PostgreSQL database. It also adds functions and indexes that apply to those types. It does this by:

• Building a C library that PostgreSQL can load into a postgres backend.
• Binding the functions and structures in that library to SQL types and functions.

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 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

Developer Documentation

• PostGIS 3.3 doxygen

• PostGIS 3.2 doxygen

• PostGIS 3.1 doxygen

• PostGIS 3.0 doxygen

• PostGIS 2.5 doxygen

• PostGIS 2.4 doxygen

• PostGIS 2.3 doxygen

Getting Involved

PostGIS is an open source development community of people, so the best way to get involved is to get to know the people while building useful things for the community:

• Join the PostGIS users e-mail list (archives) and help answer new users' questions.
• Grab the source code from our source code repository and read up on memory handling, PostgreSQL binding, and other architecture discussions; all detailed on our PostGIS developer wiki.
• Follow our coding and documentation style guidelines as detailed in committer guidelines
• Pick a section of the documentation that you think can be improved and provide a patch.
• Help translate the documentation PostGIS OSGeo Weblate project and/or the PostGIS Workshop
• Join the PostGIS development e-mail list (archives) and see what people are talking about and who is talking.
• Pick an open ticket that interests you or create one, discuss solutions on the e-mail list, and provide a patch.

Providing Patches

PostGIS project accepts patches for bugs as well as new features. All patches must be submitted via our ticket tracking as mentioned in Reporting Problems section. We also accept patches as pull requests from our primary repo and various mirrors listed in source page. Key things we need:

1. When you submit, please make sure to set type to patch.
2. For enhancements and new features we expect CUnit tests and PostgreSQL test included. Non-lwgeom patches don't need CUnit tests.
3. For new features we expect a documentation patch.
4. Make sure your code has copyright info and is GPLv2 compatible.