KML output

Steve Lime Steve.Lime at DNR.STATE.MN.US
Wed Oct 3 01:24:44 EDT 2007

I know Assefa was planning an RFC to discuss. I'm particularly interested
in how KML output can be utilized in a variety of areas (WMS,WFS,CGI and
MapScript). KML is a different beast than GML in the sense that it uses styles
so it's appropriate as a regular map output format but also as a query presentation
format. For example, I could see defining:

  NAME kml
  MIMETYPE "application/xml-kml" # or whatever this should be

and then being able to do a:




QUERYFORMAT (probably should be QUERYTYPE for consistency) now allows you 
to change the mime-type sent by the CGI before a template is processes. This allows
the creation of pure XML, JSON or whatever templates. It would be easy to change
it to check the output format hash (it is a hash right?) to see if the value references
a pre-defined format (kml, gml, image or whatever) and calls the appropriate query
writer (e.g. msGMLWriteQuery). If not present as an output format it assumes it's a
mime-type and writes that (I'm sure there's a security hole in there somewhere so maybe
we always define an outputformat, but allow a special one for templated presentation).

  NAME kml
  MIMETYPE "application/kml" # or whatever this should be

Anyway, I could do away with a bunch of stupid query modes (e.g. NQUERYMAP). It's
just a query with an image output format.

Anyway, that drifts a bit off topic but I the KML output as forcing these other changes.
I can write up a seperate RFC for that, but I'd like to see KML output support both draw
and query output.


>>> Paul Spencer <pspencer at> 10/01/07 4:20 PM >>>
Not as much as I would have liked.  The library will support reading  
and writing but from what I gathered, he felt that writing was  
trivial enough that if we already supported writing GML then we  
should just use that.  The problem with waiting for libKML is that  
they have no scheduled release date nor any preliminary materials  
that could let us guess what it's capabilities are.

We will go ahead with an implementation for Bart.  If it turns out  
that libKML provides substantial benefits for writing KML then we  
will have to revisit it in the future.



On 1-Oct-07, at 4:04 PM, Steve Lime wrote:

> Paul spent time with those folks so you might ask him. My  
> understanding was that the library
> didn't offer as much for authoring KML as it did for reading it.  
> That needs to be confirmed. If
> so then using libxml2 or even the GML approach would be fine.
> Steve
>>>> On 10/1/2007 at 2:45 PM, in message <47014E3C. 
>>>> 3080404 at>,
> Yewondwossen Assefa <assefa at DMSOLUTIONS.CA> wrote:
>> Steve Lime wrote:
>>> The libkml library is imminent so anything regarding KML should  
>>> wait until
>> that happens. The Google
>>> folks will be holding a BOF on it tomorrow.
>>   Steve,
>>   Were you able to get more info on the libkml ?
>> Thanks
>>> Steve
>>>>>> Yewondwossen Assefa <assefa at DMSOLUTIONS.CA> 09/24/07 12:35 PM >>>
>>> Bart van den Eijnden wrote:
>>>> Wrt the KML output, Assefa is currently working on this on a  
>>>> contract to
>>>> the Geo-Information and ICT Department of the Ministry of  
>>>> Transport,
>>>> Public Works and Water Management.
>>>> Thomas, do you know the timeframe for the Google C++ library for  
>>>> KML?
>>>> Assefa, is there gonna be an RFC for this?
>>> I will prepare an RFC in the coming weeks. It will be based on the
>>> following doc ( )  
>>> and I
>>> will try fill/update things that are missing and we can go from  
>>> there.
>>> Later,
>>>> Best regards,
>>>> Bart

|Paul Spencer                          pspencer at    |
|Chief Technology Officer                                         |
|DM Solutions Group Inc       |

More information about the mapserver-dev mailing list