|Version 16 (modified by rouault, 20 months ago)|
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.
64bit dimensions might also be necessary for WMS global datasets with very high precision, where the number of pixels might exceed 2 billion in the base overview level.
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
Not strictly an API/ABI issue, but fixing some of the issues might require changes in user scripts.
More stricter OGR SQL syntax to distinguish literals from identifiers
Current OGR SQL syntax interprets as equivalent single-quoting and double-quoting. However there are situations where using carefully single-quoting or double-quoting is the only way to understand the intent of the user. The SQL standard (at least as implemented in sqlite and postgresql) being : 'a_literal' and "a_identifier" (identifier being column or table name). See http://www.sqlite.org/lang_keywords.html
Example : SELECT CONCAT('x',PRFEDEA) FROM poly is OK. But now imagine that the PRFEDEA field is in fact called DESC, which is a reserved SQL keyword, thus needing quoting. And here we realize that we can't distinguish between a literal and a field name (should we concat 'x' with 'DESC'-the-string of 'x' with 'DESC'-the-field ?), if we consider single and double quoting as equivalent...
Not strictly an API/ABI issue, but fixing this would break user scripts/code/practice if they don't follow the SQL standard and use indifferently single and double-quotes.
- 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 in 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.
- 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
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