Difference between revisions of "Paris Code Sprint 2016 : GDAL Agenda"

Revision as of 09:15, 15 February 2016

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

Extending RFC 61 - Support for measured geometries :
- Python testing of new methods
- Implementation in drivers that support it : PostGIS (if not already completed), SQLite/Spatialite, FileGDB, OpenFileGDB, GPKG, Oracle. Check that it works with CSV, VRT, MEM
- Check how that works with reprojection. Probably need ogr2ogr hack
- Review remaining tasks in https://trac.osgeo.org/gdal/wiki/MeasuredGeometriesInDrivers

Breaking cyclic dependency spatialite->postgis->gdal->spatialite that cause issues in DebianGIS packaging, possibly by dlopen()'ing spatialite

Improve error handling of libcurl errors and other network errors for vsi* drivers
- See: https://github.com/mapbox/rasterio/issues/538 for discussion

Improve performance of ODBC and related drivers - right now if you don't specify table filter it is too slow against large

databases as it seems every table call requeries all metadata of all tables. This I ran into when using ogr-fdw

- See: https://github.com/pramsey/pgsql-ogr-fdw/issues/50 (but concluded the issue is in GDAL/OGR since querying with ogrinfo and friends is just as slow)

@@ Line 13: / Line 13: @@
 *Improve error handling of libcurl errors and other network errors for vsi* drivers
 ** See: https://github.com/mapbox/rasterio/issues/538 for discussion
+* Improve performance of ODBC and related drivers - right now if you don't specify table filter it is too slow against large
+databases as it seems every table call requeries all metadata of all tables. This I ran into when using ogr-fdw
+** See: https://github.com/pramsey/pgsql-ogr-fdw/issues/50 (but concluded the issue is in GDAL/OGR since querying with ogrinfo and friends is just as slow)
+* Configure script for mingw64 ODBC - https://trac.osgeo.org/gdal/ticket/6000
 == Discussions ==