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.

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.

Increase size of OGRField structure

Might be necessary to have sub-second precision for OFTDateTime. Has been postponed because of its impact on ABI. Related ticket : #2680

Fix object lifecycle management in Python bindings

Has always been a pain for newbees, and sometimes oldbees too. Current sitation is discussed in PythonGotchas page. Related ticket : #3592

Not strictly an API/ABI issue, but fixing some of the issues might require changes in user scripts.

Housekeeping issues

• install headers into PREFIX/include/gdal
• separate between private build-time headers (not to be installed) and public (for example cpl_config.h should not be installed)
• more consistent naming of files: sometimes it is gdalgrid.h and sometimes it is gdal_alg.h
• review the directory structure and make improvements for clarity

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. (note: they are returned in a meaningful order - the order they are tried - which is important to know sometimes)
• 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.
• gdalinfo displays the palette, which is boring (and generally unneeded). I would prefer that gdalinfo doesn't display it by default, and that a new -ct option replaces the -noct option.

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
• #2680 - OGR OFTDateTime needs more precision
• #3127 - Use char const instead of char for input strings with pointer reset
• #3153 - Define OGRErr as enumerated type
• #3818 - GDAL Command line tool naming consistency
• #3952 - Python bindings: allow chaining method calls while preserving C++ objects alive