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(), ...

Generally, code review for stricter type would be beneficial, where possible.

User changes (command line tools)

There are some things that can be hard when starting on gdal and are frequently on the mailing list. Here is a starter list, if those types of changes are being considered.

• Standardize command names. Some are gdal_command others are gdalcommand
• Running gdalinfo --formats should list the formats is some meaningful order. On linux I can | grep 'format name' or sort or various other things to make it useful. On Windows, I copy the result into notepad and then search (although more recently I installed gnuwin32). Sort of nice that a report on supported formats is so numerous as to be a problem.
• Coordinate order of [-projwin ulx uly lrx lry] makes sense if you think of it as a picture with 0,0 starting in the upper left. Many geospatial people have been trained to think of the 'proper' coordinate order differently. There is unlikely to be much agreement on this item so it may be best left alone.

Considerations

• These aren't that hard to learn
• This will inconvenience long time user who will chronically do it the original way on their first try
• This will break a lot of written and running scripts that will need to be changed

Related Tickets

Tickets related to other similar issues raised in the past:

• #289 - OGRPoint::get*() members should be const
• #1629 - Replace all occurrences of std::string with CPLString
• #1743 - Const correctness in cpl_http module
• #1752 - Make new method in OGREnvelope following const-correctness
• #3127 - Use char const instead of char for input strings with pointer reset
• #3153 - Define OGRErr as enumerated type