[postgis-devel] PostGIS 3 thought experiment

[Darafei "Komяpa" Praliaskouski]

In no particular order:

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

ср, 17 янв. 2018 г. в 20:44, Paul Ramsey <pramsey at cleverelephant.ca>:

> What else is on everyone's wish list? Preferably things you'd do if
> you didn't think everyone would shoot you down for being too
> disruptive.
>
> https://trac.osgeo.org/postgis/wiki/PostGIS3
>
> * Break out a postgis_raster extension with a postgis dependency, so
> raster support becomes optional.
> * Require installation in a 'postgis' schema, always and for ever
>
> * 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?
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180117/728b5378/attachment-0001.html>