[gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

[Even Rouault]

Hi Etienne,

Thanks for your ideas.

> Hi all,
> 
> I have a few suggestions for gdal 2.0, based on my personal experience in
> learning to use, enhance and maintain gdal/ogr code.
> 
> - replace cpl/csl/string/xml code with a mainstream, modern cross-platform
> toolkit such as QT, boost, etc.

QT is certainly a dependency we wouldn't want to draw. Too big for some 
embededded usage, and it would make GDAL to be practially bound by the LGPL.
I guess standard C++ libraries classes, or perhaps boost, should do the job 
for what you mention below.

> 
> While cpl/csl classes are robust and "do the job", they are not well
> documented and not very intuitive for a new gdal coder. This is from my
> personal experience, some may not agree.
> They are also not used outside gdal, as such do not benefit from
> enhancements as other toolkits.

Well, at least, MapServer uses a few CPL functions : CPL minixml, 
CPLMalloc/CPLFree, CPLReadDir, CPLFormFilename, CPLGetFilename, 
CSLInsertString, etc..

> The drawback is that some data/methods would not be easily available in c
> and other bindings. Also it might not be available for all platforms.
> Existing code would still be able to use cpl/csl code but be deprecated
> until a given release.
> 
> 
> - upgrade/migrate gdal support file (files in .csv format such as gcs.csv)
> reading to use containers (e.g. hash maps) instead of reading the relevant
> .csv files every time
> 
> Current reading of gdal support files is sub-optimal as any query for
> support data requires reading the relevant support file(s). It would be
> more efficient to read these once and cache into a container (such as hash
> map). This could be done using a cross-platform toolkit mentioned earlier.

Another option would be to use a .sqlite database with proper indices. SQLite 
would become a runtime requirement, but I don't think that would be a big 
problem.

> 
> 
> - modify metadata treatment to be able to store/retrieve data in formats
> other than strings (e.g. floats, doubles, boolean), and query the actual
> type of a given metadata item.
> 
> Currently there is no way to know if a given metadata item represents an
> integer, float, double (or string).
> 
> In the netcdf driver, I overcame this limitation in 2 ways:
> 1) parsing the value to test if it is an int, float or double (potentially
> error-prone)
> 2) add an extra metadata item to specify the type of the data represented
> (cumbersome and non-standard)
> 
> My suggestion would be to be able to store metadata value along with its
> data type (default string as previously). This would require some kind of
> container for internal representation (e.g. in qt: QMap<QString, QVariant>)
> and a way to represent this on file (as .aux.xml or otherwise in files that
> support metadata) such as gtiff. Values could be stored as strings to avoid
> big/little endian conversion problems. Data type could be stored in a
> (hidden) metadata domain, one item for each "real" metadata key.

Interesting idea.

Well, we need coders now ;-)

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html