Purpose

This page is not a list of things that will happen it is a place to gather disruptive changes that might make sense for a PostGIS 3 release.

Ideas

• Break out a postgis_raster extension with a postgis dependency, so raster support becomes optional (experimental implementation: ​https://git.osgeo.org/gitea/postgis/postgis/pulls/20).
• Require installation in a 'postgis' schema, always and for ever
• Get rid of the Minor version in the lib file or at least make it not the default compile option, so pg_upgrade is easier for users
• Yet another serialization, this time changing to use external storage type, and adding our own compression scheme for coordinates.
  • An uncompressed header, so header info can always be efficiently "sliced" and read, even for very large objects
  • A hash key for use in fast and small equality comparisons (for use in cached comparison code)
  • A compression format optimized for doubles
  • Other compression formats with other tradeoffs (?) like TWKB for higher ratio with precision loss
  • Implies indirection in coordinate access again: smaller, more efficient must be balanced against direct access to coordinates
• Move up to "modern" C and use whatever cool features we like from that
• Modern GEOS version requirement?
  • Some major GEOS surgery to allow memory management by palloc?
  • Some major GEOS surgery to build coordinateSequence directly on top of PostGIS pointlists?

• Have some strategy for storing and tracking coordinate precision
• Make "PostGIS" source tree an even thin(ner?) wrapper that exposes other code to Postgres. Leave almost no processing logic here.
• Consider using C++ for some of what is currently in the "lwgeom" source tree
• Use GEOS C++ API to avoid verbose, complex code from dealing w/CAPI
• Build adapters to LWGEOM to boost::geometry and CGAL types so we can use those libraries directly