[gdal-dev] KMZ Support in OGR?

[Brian Hamlin]

On Mar 29, 2008, at 5:43 AM, Simon Perkins wrote:

> Brian Hamlin wrote:
>> On Mar 28, 2008, at 10:06 AM, Simon Perkins wrote:
>>
>>>  Thanks - that would seem like a good way to go in the future, 
>>> though I don't have time to work on it myself...
>>
>> that may be a common story !
>>
>> the relatively light weight discussion of this that I have heard so 
>> far basically comes to a conclusion that since OGR writes out a 
>> pretty simple KML, its not worth doing the work of bringing in the 
>> new libkml to do that.
>>
>> Its worth noting that the Simple Features Library (that OGR is based 
>> on) only goes so far in mapping to KML.
>>
>> as for kmz, thats trivial.. just pipe the output to a zip program, y?
>
> Well, it would be nice to have something that was integrated into OGR,
> without having to mess around with external programs.
>
> I think rewriting the KML driver to use the google library would be a
> great idea. The current KML driver has a number of limitations - for
> instance, it doesn't support reading of multi-geometries (though I 
> think
> it will write them).
>
>
Well, this thread sort of strikes a nerve for me.. I started 
volunteering on this project 6 months ago primarily to understand and 
contribute to KML support. Now that 1.5 has gone final and a better KML 
driver is stock with GDAL/OGR, the libkml 0.1 is available.

Through a combination of time constraints, learning curve and project 
technical challenges, the reality is that the KML support is what it is 
so far, including my own (well-intentioned) efforts.

<flame>You say you think it would be a great idea to add a new library 
in place of most of the driver that is there, but dont have time and/or 
ability to make a wiki page about that as a proposed project?</flame>

Simple Features has to map to <=> from KML to work with OGR. To do it 
at the level of reliability that is expected with OGR is not trivial. 
Understanding the new libkml enough to use it well is not trivial, 
either.

See what I mean?

I am suggesting the very same thing as you in the long run btw - and 
had to have the discussion about tradeoffs in the real world.

LibKML will:

* be guaranteed to write out KML that meets the spec, now and in the 
future
* will get regular bug fixes
* be a standard API - though its far from there yet
* may have reasonable approaches to many of the more interesting KML 
features

but
* libkml reading KML isnt a free ticket to using and understanding the 
result of that read
* mapping Simple Features back and forth is still work to be done
* the lib is immature.. just not full-featured yet, so its services are 
very limited

I think KML is strategically important in the field. Other people might 
mock that a bit.. As they say, informed people may disagree.

My impression is that GDAL/OGR is a top-notch OSS project, with the 
highest caliber of contributers, in a very specialized field, and that 
it has all kinds of momentum with a big, active set of core committers 
and very strong users. On the other hand, with so many places to work 
on, there are only so many engineering hours to go around.

Who knows, maybe someone out there will fund the effort and hire to do 
this? Maybe someone ought to try to make that happen? What if there was 
a new driver, that was libkml from the start, borrowing heavily from 
the existing driver? How much effort would that be? Who would benefit 
most?

all for now
   -Brian


>>>
--
Brian Hamlin
ISDE5 Steering Committee
Planetwork.net
(415) 717-4462 (c)