Changes between Version 19 and Version 20 of PostGIS3


Ignore:
Timestamp:
May 9, 2019, 10:47:01 AM (5 years ago)
Author:
komzpa
Comment:

—

Legend:

Unmodified
Added
Removed
Modified

  • PostGIS3

    v19 v20  
    77* strk and robe to help set up OSGeo7 via Jitsi
    88
     9== Done
     10
     11* 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). **Committed needs testing, also change in PostGI_Upgrade_Extensions required to properly handle split**
     12* 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
     13* Move up to "modern" C and use whatever cool features we like from that
     14* recheck on GIST operators, so that ST_Intersects has no chance to not inline; (done by change of support functions in Postgres 12)
     15* Modern GEOS version requirement
     16* 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;
     17
    918== Ideas
    1019
    11 * 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). **Committed needs testing, also change in PostGI_Upgrade_Extensions required to properly handle split**
    1220* Require installation in a 'postgis' schema, always and for ever **HOLD OFF not as important as it used to be now that its not movable**
    13 * 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
    1421* Yet another serialization, this time changing to use `external` storage type, and adding our own compression scheme for coordinates.
    1522  * An uncompressed header, so header info can always be efficiently "sliced" and read, even for very large objects
    … …  
    1825  * Other compression formats with other tradeoffs (?) like TWKB for higher ratio with precision loss
    1926  * Implies indirection in coordinate access again: smaller, more efficient must be balanced against direct access to coordinates
    20 * Move up to "modern" C and use whatever cool features we like from that
    21 * Modern GEOS version requirement?
    22   * Some major GEOS surgery to allow memory management by palloc?
    23   * Some major GEOS surgery to build coordinateSequence directly on top of PostGIS pointlists?
    2427
     28* Some major GEOS surgery to allow memory management by palloc?
     29* Some major GEOS surgery to build coordinateSequence directly on top of PostGIS pointlists?
    2530* Have some strategy for storing and tracking coordinate precision
    2631* Allow storage of non-double coordinates (integers, single-precision, exact, timestamp)
    … …  
    3641* 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;
    3742* support for S2 geometry cells, and have a look at making a fast ST_Intersects GIN index on geography using them;
    38 * recheck on GIST operators, so that ST_Intersects has no chance to not inline;
    39 * 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;
    4043* 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");
    4144* Make ST_ClusterWithin and ST_ClusterIntersecting window just like ST_ClusterDBSCAN