[gdal-dev] Regarding libkml driver

[Sebastiaan Couwenberg]

On 12-08-15 00:55, Wolf Bergenheim wrote:
> On 11 August 2015 at 18:56, Sebastiaan Couwenberg wrote:
>> On 11-08-15 18:37, Kurt Schwehr wrote:
>>> Wolf and I have joined in working on libkml.  We will be getting more
>>> transitioned from the old code.google.com site to
>>> https://github.com/google/libkml, will be pushing some general
>>> maintanence
>>> patches and will be getting the pull request processed.  We look forward
>>> to
>>> collaborating on future development of libkml.
>>
>> The renewed interest in libkml from Google sounds promising.
>
> Glad to hear it!

I've also commented on the Project status GitHub issue:
https://github.com/google/libkml/issues/4

As I wrote in an earlier comment:

"
 I'd love to see all GIS developers rally around the new preferred
 repository to collaboratively maintain libkml, breathing new life into
 this useful library because there are no good alternatives.
"

The community involvement in libkml development is essential in my
opinion to prevent the project from dying again when the Google
engineers loose interest or otherwise move on.

What are your thoughts about that?

Maybe it would make sense to form libkml into an OSGeo project?

>> What are your views on merging the work in the libkml/libkml fork back
>> into google/libkml?
>>
>>
> I'd like to merge back as much of the work that has gone into libkml/libkml
> to google/libkml. Especially externalizing libraries.

That's great, very much what we need.

>> The switch to CMake and removal of the third party dependencies in favor
>> of linking to system provided libraries solve the issues that required
>> patches in the libkml Debian package in the past. I'd like to see these
>> changes merged back into google/libkml to not loose these gains.
>
> These sound very interesting, and I'll look at them more closely, but on
> the surface it looks good.
> 
>> Most importantly the final 1.3.0 libkml release is long overdue, it has
>> been required for GDAL for many years now but many distributions still
>> ship libkml 1.2 (Fedora removed libkml even because it was abandoned
>> upstream). What do you think needs to be done to get the 1.3.0 release out?
>
> Hmm. I think that we should first get to the point where we can merge the
> libkml/libkml stuff back to google/libkml before we push out a new release,
> in order to avoid confusion and mess.

We definitely need to sort out how to continue libkml development, what
to do with the forks (Kitware has many changes in their fork too that
should be considered).

> Also we might want to call it libkml 2.0.0 so we don't really need to worry
> about backwards compatibility.

The libkml 1.3.0-rc0 release from libkml/libkml already includes a
SONAME bump to account for the minizip changes.

Bumping the version to 2.0.0 makes sense if more drastic changes are
included, otherwise it seems better to follow the 1.2 release with 1.3.0.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1