By the way, I crafted AX_LIB_LIBKML macro for Autoconf. This macros checks for headers and libraries of specified version (or newer) of Google libkml library and defines compilation and linking flags.

I submitted the macro to GNU Autoconf Archive. It is the new incarnation of well-known autoconf-archive.cryp.to. Peter Simons announced not long time ago that

The archive has moved to Savannah: http://www.nongnu.org/autoconf-archive/. Version 2009-04-26 was the last to be released at autoconf-archive.cryp.to.

Happy detecting libkml!

A: The lesson is I ought to get things right the first time.
B: The issue with const method is that if you want to add lazy loading later, it can cause problems
C: GDAL is rather painful to use with const correct code, unfortunately :(
B: The solution is obvious: don’t write const correct code

Who’s right then, A or B?

I recall another motto from #gdal channel that sounds like “when unsure, do nothing” which has the following rationale:

especially when I realize afterwards that I’ve f**cked things because I neglected to follow the motto

Remembering these recommendations, it’s pretty clear why the const-mess in GDAL has happened. I’d conclude paraphrasing the motto this way:

I’ve f**cked things because I neglected to make a decision.

Now, poor GDAL beginner deadpickle, trying to find out (it’s me the evil) why compiler complains about his not-that-bad-written code, wandered to find and ask C gurus @ comp.lang.c and got the problem explained by Malcolm who wrote:

The problem is that, when C was first developed, there was no const keyword. So strings literal, which are constant, had to be non-const for backwards compatibility. This means that lots of programmers get lazy and omit the const, even from functions which don’t modify their string arguments. (There are also some subtle problems with const which means that this isn’t always a case of pure laziness). So a sort of solution is to discard the const qualifiers. However this is perpetuating the problem in your own code.

The motto stays in contradiction to a well-known best practice of const correct sooner than later. It’s way easier and cheaper to remove const-correctness once it turns out it does not express properly the actual design and contract than to apply it to existing codebase. Sometimes, the latter is even not possible making things f**cked up twice, in existing code base and in client’s code.

The main motivation is that it simplifies development of experiments in case one needs version control or complete disconnection from SVN trunk for some period. Thanks to git-svn, it is possible to push changes back to the trunk.

I outlined the process of maintaining GDAL trunk using Git in the Wiki article Using Git To Maintain GDAL Workflow.

The synchronization is not a time consuming process at all but even that I hope to make it automatic process in near future. First, I have to ship my little personal server to a remote data centre and I’m hoping to do it next week. Lucky bastard going to bask in the warm sun of Portugal :-)

This is the first major new release since the 1.6.0 release approximately one year ago

This new version brings quite a nice collection of new drivers for raster and vector data formats:

• New Raster Drivers: BAG, EPSILON, Northwood/VerticalMapper, R, Rasterlite, SAGA GIS Binary, SRP (USRP/ASRP), EarthWatch .TIL, WKT Raster
• GDAL PCIDSK driver using the new PCIDSK SDK by default
• New Vector drivers : DXF, GeoRSS, GTM, PCIDSK and VFK
• New utilities: gdaldem, gdalbuildvrt now compiled by default
• Add support for Python 3.X. Compatibility with Python 2.X preserved
• Remove old-generation Python bindings
• Significantly improved raster drivers: GeoRaster, GeoTIFF, HFA, JPEG2000 JasPer, JPEG2000 Kakadu, NITF
• Significantly improved vector drivers: CSV, KML, SQLite/SpataiLite, VRT

We use GDAL to read the files, and were opening them via GDALOpenShared, so that GDAL only opened the file once and used reference counting to manage the lifetime of the GDALDataset object. Unfortunately (for us) GDAL is not thread safe. This isn’t a criticism, the fault is entirely ours for using it in this way.

Criticism or not, the reality is that we (software developers) have already jumped to an era of parallelism (count number of physical or logical CPUs in your computer) where thread-safety becomes a minimum requirement as basic as avoiding buffer overruns.

Welcome Frank!

I can not even imagine effectiveness of exploitation of such a power by issuing little gdalwarp command. GDAL, libLAS, are we ready to squeeze out this CUDA’ny juice?

Co za CUDA! Yes, indeed!

#17 – CMake build configuration for GeoTIFF

It also includes FindGeoTIFF module for CMake users that need to determine availability of libgeotiff in their projects. Tests and improvements are welcome.

Other related patches are available as tickets #1347 and #2032.