= Code Sprint - Paris = == Code Sprint == A European PostGIS code sprint will be organized in Paris next 15th and 16th of May. The main aim is mainly to begin thinking about next releases... (and to give to Paul an opportunity to keep thinking about PostGIS even during holidays ^^) PostGIS (and related) devs who will be there: * Paul Ramsey (PostGIS) * Sandro Santilli (PostGIS & GEOS) * Mark Cave Ayland (PostGIS) * Mateusz Loskot (Cadcorp, PostGIS, Boost.Geometry) * Sébastien Loriot (CGAL) * Tim Manners (Ordnance Survey) * Mickael Borne (IGN) * Olivier Courtin (PostGIS) (If you are concerned and interested, just subscribe quickly) * Beginning at 2:00 PM on 15 May * Ending at 5:00 PM on 16 May === Venue From Charles de Gaulle Airport (about one hour) === * Take RER B (suburban metro) till "Gare du Nord" * Change to metro 5 (Direction Place d'Italie) till République station. * Here you are. === Code Sprint Place === * 5, avenue de la République 75011 Paris (2nd floor in Quelleville corporate place) * Map and contact: http://www.quelleville.fr/contact/ === Not to forget === * You're laptop with all softwares to work with * AC European adaptator (for your laptop) * If you have an RJ 45 wire that's a good point (if not we will provide) * Smile and happyness == Barcamp == On May 15th in the evening (6:00 PM) an event will be organized (still in Paris) to allow some happy few PostGIS (power) users to exchange with the PostGIS dev guys. The goal is to enlarge the vision to broader future axes, through discussions and/or small working groups. So if you are already involved in the PostGIS project (or willing to), want to exchange with the dev team, and/or meet some other PostGIS afficionados at a cool event, just come ! (beers included) For practical reasons we have to limit the amount of participants to about 15. First registered, first served. (if you want additional information, or want don't have osgeo id to registered on this Wiki, send a mail to ) Folks subscribted on the 15th evening: * Yves Jacolin * Vincent Habchi * Nicolas Ribot * Alexandre Bonnasseau * Thomas Brosset * David jonglez * Paul Ramsey * Sandro Santilli * Mark Cave Ayland * Mateusz Loskot * Sébastien Loriot * Tim Manners * Alexandre Liccardi * Olivier Courtin == Ideas and topics proposal == * Routing * Parallel processing * Large point clouds in db * 3D * CGAL inclusion * Boost.Geometry vs GEOS * Faster Union for Raster (native C instead of plpgsql) * ST_DelaunayTriangles (http://trac.osgeo.org/postgis/ticket/1215 ) with option to output as topology or TIN * Clustering of points * Data sampling based on geospatial indexes * !GeomAsJsTypedArrays * output of indexed geometries * Faster reprojection * switch to git * An another PostGIS European Code Sprint next year ? * Making functions interruptable * Add your own === Bar Camp Place === * AF83 * 15 rue Poissonnière * 75002 Paris * Map: http://tinyurl.com/bp4uohn === Venue from Code Sprint place === * Take metro line 9 (at République station) till "Bonne Nouvelle" stop * Exit on Blvd Bonne Nouvelle (70m) * Turn left on rue Poissonnière * Walk till 15 rue Poissonnière (170m) ----------- = PostGIS Code Sprint Notes = == Topic #1: What is bad about PostGIS now? == * Upgrades (history, backwards compatibility) * Repeated code blocks everywhere * Windows build/test situation (there is nothing standard) * We need a build farm * We have similar issues with 32-bit/64-bit testing on any OS * harder to catch 64-bit issues * Dependencies++ (so many of them, and more coming) * GEOS (too slow? maybe) * Translations (documentation, untranslated; GUI, untranslated) * Inconsistent function names (still) ST_this_thing versus ST_ThisThing * Versioning of loaders shp2pgsql, shp2pgsql-gui, etc. * if you install a lower version of PostGIS after newer version, it overwrites these files * 2.0.1 doesn't work for 9.2 * http://trac.osgeo.org/postgis/ticket/1820 (not sure where to put the include I described - in one file or all 3) - I accidentally committed but lower versions still seem to work (so this is working) topology however is broken ( http://trac.osgeo.org/postgis/ticket/1822 ) -- we probably shouldn't even have ALTER in creation script. == Discussion #1: GIT == * Do we want to move to git? * Yes. No. Advantages not so high to be worth the time/effort. Willing to move to git when someone steps up to do the migration, but migration MUST include trac tickets and history and links from commits to tickets to commits. * Decision: A svn clone will be added to the github postgis account, updated hourly automatically, so that git-lovers can clone/work from the same repo. == Discussion #2: CGAL == * Olivier, interest in CGAL is driven by 3D operations. Starting from an existing base of functionality rather than re-inventing parts. Triangulations, etc. * CGAL has CMake build system. == Discussion #3: GEOS == * MCA: worried about future of GEOS, the performance and design as inherited from JTS is not optimal, and the code is very specialist to the geospatial community * ML: when working on raster, advoctated for implementing algorithms natively, linking GDAL is bad idea when the algorithms you need are not so big * SS: GEOS is good enough, problem is not language or pattern, it's mostly just algorithms that can be made better * MB: BoostGeometry is very flexible, but, that's a drawback, it's hard to understand and get involved. * ML: For BoostGeometry, there are users, and questions (use of the library means specifying and generating custom library and test its behaviour -> complex task) , the project is alive. * SS: Extend the C-API to provide custom allocators (will also automatically provide interruptability when the allocators are installed by postgis) == Discussion #4: Raster improvements == * Faster ST_Union (dustymugs, pramsey fight it out) * should be part of larger map algebra rewrite for aggregate support * Aggregate versions of stats functions (dustymugs) * Faster out-of-db data loading (dustymugs) * current testing has shown that in-db is several times faster * GDAL * Irregular grid support (DZ) * Mapalgebra Nearest Neighborhood (ngb) (is there anything we can do about the border edges) perhaps an aggregate ngb function? (might be useful if n tiles in = n tiles out) but ngb operation works on adjacent tiles so you get same solution as ngb of a single raster retiled back out * GUI raster loader similar to shp2pgsql-gui * Function to Ununion (tilify in the db) == 2.1 Topics: MCA == * Performance of new libraries * Integration of new libraries * Changing build -- are we committed to CMake or not? == 2.1 Topics: SS == * EPSG code detection in loader * Faster (raster) reprojection * strk, can you elaborate on this? == 2.1 Topics: OC == * GML 3.2 support (for INSPIRE) * add an ID to every geometry * geometry_from_* in liblwgeom dir * Explore new topo libraries (3D context) == 2.1 Topics: PR == * Internal tree for geometry/geography * POINTCLOUD