[Gdal-dev] KML Write-only driver for OGR

[Christopher Condit]

Some of the style information that KML handles:
1) Define a perspective for a feature (the application shall view this
feature from elevation z, angle theta, lat y, lon x, etc.)
2) Define arbitrary icons for point features
3) Define links for icons (http or local)
4) Define drawing styles for features:
	* A label's color, and scale
	* A line's color, and width
	* A polygon's fill, color, and opacity

I'm sure there are more, but that's a general sampling.
-Chris

-----Original Message-----
From: gdal-dev-bounces at lists.maptools.org
[mailto:gdal-dev-bounces at lists.maptools.org] On Behalf Of Daniel
Morissette
Sent: Thursday, May 25, 2006 7:54 AM
To: gdal-dev
Subject: Re: [Gdal-dev] KML Write-only driver for OGR

Christopher Condit wrote:
> It's certainly possible to add read support for KML.  The XML
> construction is very similar to GML (at least for geometries).  The
only
> problem is that I'm not clear how to handle feature attributes, as KML
> stores this type of thing in the "Description" element.  This content
> model for this element is arbitrary text (which can also be HTML).  We
> can:
> 0) Accept write only support for now
> 1) Define some convention for OGR <-> KML feature attributes that gets
> stored in this description element
> 2) Allow only two attributes on read: name and description (populating
> with content from these XML elements)
> 3) Other suggestions?
> 

I think I'd go with #2 since my understanding is that there is no 
guarantee on the way the attributes would be encoded in the Description 
element, so we cannot implement any robust parsing of attributes inside 
the KML reader. If users of the KML driver need access to the attributes

from a well-known source then they can always implement a script to 
parse the attribute values themselves.


> Also, we'll lose formatting information from the KML - but I don't see
> any way around that...
> 

I haven't looked at KML myself, but what type of formatting information 
does it include? Could we store that in a style string?


Frank Warmerdam wrote:
> 
> So, I'll start things out with a +1 in support of this new driver.
> 

+1 from me.

> PS. I don't foresee needing a written RFC for non-disruptive changes
> such
> as adding a new driver.
> 

Can I ask for at least a bug to document the addition of the driver, its

features and its limitations at the time of initial implementation?

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev