<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Well, all very salient points. I particularly liked the link to Joel
Spolsky's article. Should be required reading for all programmers!<br>
<br>
But a couple of comments anyway...<br>
<br>
<blockquote
cite="mid:845AADAC1106E44996327D62097E4C6BFF0709@et.ad.sdsc.edu"
type="cite">
<pre wrap="">*) Google's libkml is not yet production ready
</pre>
</blockquote>
Fair enough - I haven't used it. But my hope would be that if Google is
going to be using this in Google Earth then it should get up to speed
pretty darn quickly. Of course, I'm not sure they've said that...<br>
<br>
<blockquote
cite="mid:845AADAC1106E44996327D62097E4C6BFF0709@et.ad.sdsc.edu"
type="cite">
<pre wrap="">*) Once the KML 2.2 spec is approved by OGC I expect it to be rather
stable, so I'm not sure that switching to libkml for an evolving
standard is really going to buy OGR much.
</pre>
</blockquote>
<br>
Another good point. To be honest my interest is more in seeing the few
flaws I've discovered fixed than anything else. If it's easier to fix
the current driver then that's probably the way to go.<br>
<br>
<blockquote
cite="mid:845AADAC1106E44996327D62097E4C6BFF0709@et.ad.sdsc.edu"
type="cite">
<pre wrap="">*) It would probably be trivial to add kmz support, but as Brian
suggested why not just pipe the file to a zip command?
</pre>
</blockquote>
<br>
Well, that's fine if you're just trying to lash something together
specifically for KML files on a linux system, but not so great if
you're developing, say, commercial windows software that has to deal
with lots of different formats. As I see it the whole point of an
abstraction layer like GDAL/OGR is that you shouldn't have to care
about the intricacies of particular data formats. So if your users are
going to be trying to load KMZ files (the Google Earth default format)
into your application, it would be much nicer if OGR could just do its
job and read those files without you having to special case things. No?<br>
<br>
<br>
Sy<br>
<br>
<br>
<blockquote
cite="mid:845AADAC1106E44996327D62097E4C6BFF0709@et.ad.sdsc.edu"
type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:gdal-dev-bounces@lists.osgeo.org">gdal-dev-bounces@lists.osgeo.org</a>
[<a class="moz-txt-link-freetext" href="mailto:gdal-dev-bounces@lists.osgeo.org">mailto:gdal-dev-bounces@lists.osgeo.org</a>] On Behalf Of Simon Perkins
Sent: Saturday, March 29, 2008 12:16
To: Brian Hamlin
Cc: <a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
Subject: Re: [gdal-dev] KMZ Support in OGR?
Brian Hamlin wrote:
</pre>
<blockquote type="cite">
<pre wrap=""><flame>You say you think it would be a great idea to add a new library
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">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>
</pre>
</blockquote>
<pre wrap=""><!---->
Well, that at least is one thing I have the time to fix... I've added an
enhanced KML driver using the Google library to the GDAL SoC ideas page.
Feel free to edit!
<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/gdal/wiki/SummerOfCode">http://trac.osgeo.org/gdal/wiki/SummerOfCode</a>
Cheers,
Simon
_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>