We'd like to give a big thanks to Olivier Courtin and Oslandia for organizing this year's OSGeo Code Sprint in Paris. It was quite memorable
and I walked away feeling energized.
Leo and I attended the Paris OSGeo Code Sprint for 1.5 days. I'm really glad we were able to attend at least part of it.
It would have been nicer to attend all of it. Though we didn't get too much done while there,
we did have some interesting conversations and learned about what others were doing.
I walked out with a TO DO list, of which I'm happy to say I've accomplished some of now.
While we were there Leo spent time cleaning up my Mingw64 compile scripts and starting to test PostGIS against PostgreSQL 9.6
in preparation for parallelization testing of PostGIS 2.3 features specifically targetted for PostgreSQL 9.6.
ODBC work, GDAL, and ogr_fdw
We cover this on our PostgresOnLine: OSGeo code sprint 2016, because our interest in GDAL ,OGR FDW, and beefing up ODBC support for GDAL has very little to do with Spatial or GIS.
Raster data and materialized views restore failures and Foreign table gotchas
We cover this at PostgresOnLine: OSGeo code sprint 2016 since I feel this is an issue that might effect other PostgreSQL extensions in the future.
X3D work
We also got side tracked with a lot of conversations. We met Tom Vantilburg for the first time who was showing us this glitsy rendering he did using
PostGIS ST_AsX3D function. I thought wow, someone is using my function to create a cool model. As it were I was trying to fix this issue he had ticketed https://trac.osgeo.org/postgis/ticket/3435. I discussed the issue with him that it had to do with the convex property bit, that if I put it in there concave objects rendered correctly. He did some tests and concluded I could just hard-code that setting since it seemed to have no effect on convex objects and he saw no performance degradation. So I've done that for upcoming PostGIS 2.2.2+. For PostGIS 2.3.0 I'm planning a complete rewrite to follow PostGIS's new string buffer paradigm and after that to implement support for curved geometries and also allow injection of other X3D properties.
What others were doing on PostGIS front
Dan Baston, new core developer kid on the PostGIS block, was there hacking away on hot and not so hot stuff.
The not so hot but painfully needed stuff
The not so hot stuff, upgrade problems. Dan was having an upgrade issue that only he and Sandro Santilli could replicate. With much help from Paul and Sandro, and Dan testing, the issue was resolved and will be in PostGIS 2.2.2 release. There was also the change of pgis_abs type which got changed in PostGIS 2.2. Unfortunately because it was not marked as changed, people coming from PostGIS 2.1 would get strange errors. I described how this is supposed to be done, but unfortunately has to be done at the first micro of a minor, so too late for PostGIS 2.2.2. Paul after the sprint came up with a hack to update the PostgreSQL catalogs directly to work around the limitation of not being able to alter a type without dropping it.
I didn't spend any time with the CGAL/SFCGAL folks but I'm looking forward to exercising their work. Only thing SFCGAL related I heard about was listening to Paul talk about future proofing the geometry gserialized headers so that we can get a version tag in there and add more bits that SFCGAL folks need for keeping track of validaty and other things.
I also helped some folks out with how they should specify their functions so upgrade machinery works right and use of the drop before and drop after scripts to handle addition of default args. It became painfully clear
that no one understood how the PostGIS upgrade machinery works and I only had like a 95% understanding of how it worked and how it had changed over the years.
I guess we are badly in need of developer documentation detailing how the upgrade generation script uses comments like Availability and Changed to do the right thing and what is legal to do in a micro release.
The hot stuff
Dan and Paul were busy closing out tickets
and working on the very first PostGIS Window functions - ST_ClusterKMeans and ST_ClusterDBSCAN of which they both finished and committed to PostGIS 2.3 (trunk). I contributed my 2 cents to the effort when I got back home
by coming up with a convention for representing window functions in the docs and changing the PostGIS XSL scripts to understand what a window function is. One XSL generates a special section of the docs based on special properties. PostGIS now has a section just for window functions. http://postgis.net/docs/manual-dev/PostGIS_Special_Functions_Index.html#PostGIS_Window_Functions
I also modified the garden XSL script, I affectionately call the moneky script, so it now understands how to recongize a window function in the docs and test them with OVER() syntax.
On first run, the improved monkey managed to crash ST_ClusterKMeans.
I also nagged Paul about his parallelism support for PostGIS of which I promised Leo and I would test. Sadly didn't get to doing that at the sprint, though he did commit I think so yet another thing to do.
As mentioned in BRIN for PostGIS: my story at the Code Sprint 2016 in Paris
Giuseppe Broccolo of 2nd Quadrant was working on BRIN indexes for PostGIS at the sprint. I sadly missed this conversation at the sprint, but looking forward to see a patch for their work for PostGIS 2.3 and to stress test it.
