Difference between revisions of "Paris Code Sprint 2016 : PostGIS Agenda"
Jump to navigation
Jump to search
(→Tasks) |
|||
| Line 18: | Line 18: | ||
** Implications / difficulties | ** Implications / difficulties | ||
* GEOS improvements that would help PostGIS | * 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) | * Using FDW with PostGIS (hold off on talking about this until Regina comes) | ||
** Functions pushdown | ** Functions pushdown | ||
Revision as of 12:20, 18 February 2016
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
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
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