GDAL/OGR 2.0 Changes

From time to time there has been a suggestion we should at some point have a GDAL/OGR 2.0 release at which point we would relax the normally quite strict desire for backward compatibility in the GDAL/OGR API. Unification of the GDAL and OGR components of the library is often listed as the main objective of such an overhaul. However, this page is primarily intended to track various other smaller changes that are desirable from a cleanup point of view, but that have been avoided over the last decade to avoid backwards incompatibility.

Please list thoughts on stuff we should revisit at a GDAL/OGR 2.0 release here for future consideration.

Note that it is still hoped that old GDAL using applications should still be fairly easily recompiled with GDAL 2.0 with a minimum of adjustments, so radical restructuring - particularly on the GDAL side - is not necessarily on the table. But we can certainly afford C/C++ ABI incompatibility.

Get rid of CPL_STDCALL

CPL_STDCALL is a windows only macro marking parts of the GDAL C API as using standard call rather than cdecl calling conventions on windows. This was done to make these functions easier to call from traditional VB. It is not clear that this offers useful value, and it might be prudent to just strip all reference to CPL_STDCALL from the GDAL/OGR tree.

Fix const correctness

Try to correct const correctness though as much of the API as possible - particularly for strings, and string lists. I do not necessarily propose that "major objects" like GDALDataset or GDALRasterBand should have const operations on them.

Make the VSI*L API use something other than FILE *

VSIFOpenL() does not really return a system file pointer that can work with fwrite, etc, but it is typed as if it does. It should likely be restructured to return a VSIFileH or something similar.

This would make it easier to avoid mixing VSI*L, VSI* and stdio function calls.

Fix OSRSpatialReference::importFromESRI to match other importFrom* methods

Use 64 bit integers in GDAL RasterIO() methods in order to be able to request huge areas

The most limiting factor being the size of the nBandOffset argument. For example a 50000x50000x3 dataset cannot be RasterIO()'ed with band interleaving

Add char papszOptions (ahem, I meant const char* const* ) in some API so that they can later be extended easily

GDALOpen(), GDALRasterIO(), ...