Changes between Version 19 and Version 20 of PostGIS3
- Timestamp:
- 05/09/19 10:47:01 (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
PostGIS3
v19 v20 7 7 * strk and robe to help set up OSGeo7 via Jitsi 8 8 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 9 18 == Ideas 10 19 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 20 * 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 users14 21 * Yet another serialization, this time changing to use `external` storage type, and adding our own compression scheme for coordinates. 15 22 * An uncompressed header, so header info can always be efficiently "sliced" and read, even for very large objects … … 18 25 * Other compression formats with other tradeoffs (?) like TWKB for higher ratio with precision loss 19 26 * 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 that21 * 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?24 27 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? 25 30 * Have some strategy for storing and tracking coordinate precision 26 31 * Allow storage of non-double coordinates (integers, single-precision, exact, timestamp) … … 36 41 * 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; 37 42 * 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;40 43 * 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"); 41 44 * Make ST_ClusterWithin and ST_ClusterIntersecting window just like ST_ClusterDBSCAN