Paris Code Sprint 2016 : PostGIS Agenda

Discussion and group review topics for the Paris Code Sprint 2016.

Discussion

 * Clustering functions: Aggregate or Window?
 * What naming convention
 * What to do with the existing aggregate functions
 * Expanded object headers, introduction and testing
 * How they work
 * Potential advantages, disadvantages
 * Discussion on clean implementation possibilities
 * Testing and benchmarks, is it worth it?
 * Alternate storage formats, beyond GSERIALIZED
 * Reasoning
 * How to add (version flags?)
 * Multiple co-existing formats?
 * Breaking raster out as postgis_raster extension (hold off on talking about this until Regina comes)
 * Implications / difficulties
 * GEOS improvements that would help PostGIS
 * Way to know/be sure a geometry is valid, without need to launch an IsValid test (SFCGAL initial purpose)
 * Using FDW with PostGIS (hold off on talking about this until Regina comes)
 * Functions pushdown
 * Current limitations
 * PostgreSQL improvements that would help PostGIS
 * Parallel query, review experiments, plan and execute more (hold off on talking about this until Regina comes)
 * Feed back parallel query results to pgsql-hackers
 * Open pull requests from GitHub
 * Merge, modify, or reject
 * Tickets with design implications
 * https://trac.osgeo.org/postgis/ticket/2529
 * https://trac.osgeo.org/postgis/ticket/3405
 * https://trac.osgeo.org/postgis/ticket/3246
 * https://trac.osgeo.org/postgis/ticket/3326
 * Do we want to bundle example datasets w/PostGIS for docs, tutorials?
 * Adding more checks to automated builds?
 * valgrind (would need to add suppressions for GEOS leaks)
 * gcov (identify untested or unused code paths)

Tasks

 * Benchmarking of expanded object headers test branch
 * Benchmarking of parallel query and parallel aggregate work from pgsql-hackers


 * BRIN indexes implementation for PostGIS geometries
 * postgis/lwgeom_in_* move to liblwgeom dir (or any code that doesn't depend on Postgres?)

Possible PostGIS function improvement and addition

 * improvement
 * st_pointN -> make a negative input count backward
 * st_setPoint -> make a negative input count backward
 * st_asText -> optionnal arg to limit digit number
 * st_centroid -> work on circular string (simply dump points, then classical centroid)
 * st_exteriorRing -> make it work on multipolygon, returns a collection
 * st_makeline -> make it work on multipoints
 * st_scale -> optionnal argument to define the center of scaling (allows to scale "in place")
 * st_split -> allow splitting (multi)line by (multi)point
 * st_asgml -> allow GML 3.2.1 support (not only namespace handle) http://portal.opengeospatial.org/files/?artifact_id=26765
 * st_asgml (and st_geomfromgml) -> handle gml:Envelope
 * slight addition
 * st_angle(P1,P2,P3)
 * st_MakeRing((multi) linestrings and/or points
 * st_DumpLines -> dump everything to line (rings in poly, lines in multilines, etc. )
 * st_DumpSegments -> dump segments (in the mathematical sense), that is every consecutive pairs of points in lines
 * big addition
 * generate grid (regular and hex)
 * st_snapToLine -> st_snap = snap vertex to vertex. This one = snap vertex to vertex or edge.
 * st_splitLineByPoint(line,point,tolerance) -> using curv absc, the only current way to not be sensible to precision issue (st_split doesnt work)
 * st_VariableBuffer(geomM) -> buffer on geometry, the radius is given by M of each vertex, linear transition between. A lots of uses
 * St_FindCurve(geom,radius_range,min_number_of_support_points,tolerance) -> in a classical geometry, find the point describing arcs
 * St_MakeArc(P1,P2,centre) and St_MakeArc(P1,P2,radius) -> create arcs (_not_ using 3 points on arc!)
 * St_OrientedBBox(geom) -> returns the oriented bbox of the geom (returns a geom and an angle)
 * ST_KMeans -> window function - pramsey to integrate into 2.3 code base - https://github.com/pramsey/postgis/tree/kmeans