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

• Make geography a 3D aware thing, so cart2geog / geog2cart takes third coordinate into account;
• Make a new index tuple format, that can be keep srid, small geometry fully (so index-only scan may return it already), and convex/concave/multi-geometry that covers original but has constant known number of nodes;
• Zealous geometry operations, that retry a failing geometry operation using a next backend library, and opt-in-ally automagically reporting robustness-related errors to some upstream;
• osm2topology converter, and make sure postgis topology is able to represent whatever's found in OSM data, and that data is useful for both rendering and routing;
• Allow more dimensions than 4D, so we can store directly a thing that comes from GPS (heading, speed, timestamp[system/gps/server], accuracy, some external node id) and do perform math over it;
• support for S2 geometry cells, and have a look at making a fast ST_Intersects GIN index on geography using them;
• recheck on GIST operators, so that ST_Intersects has no chance to not inline;
• ST_AsGeoJSON/GeomFromGeoJSON that are aware of json/jsonb types. So, geometry::json is ST_AsGeoJSON(geometry). A documented function to turn a table into GeoJSON FeatureCollection, automagically finding the geometry field;
• Spatial clustering: GeometricMedioid, KMedioids, XMeans, and then combine them into non-existing XMedioids with flexible exit conditions ("max cluster radius is", "max cluster diameter is", "max number of clusters is");
• A way to store SRID and type in typmod only, so that 2D point columns take just 2*sizeof(double).

If some tweaks in postgres allowed in our experiment:

• faster GiST index creation, that would order geometry by spatial adjacency and then just take chunks and turn them into index pages, instead of checking each tuple with each index page box;
• keeping a CLUSTER index clustered by getting a next candidate page for tuple insertion not from free space map, but from index sibling tuples, and inserting to the new page if they're full.