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:
OUTPUTFORMAT
NAME kml
DRIVER 'KML'
MIMETYPE "application/xml-kml" # or whatever this should be
COMPRESSED true
END
and then being able to do a:
IMAGETYPE kml
or
QUERYFORMAT kml
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).
OUTPUTFORMAT
NAME kml
DRIVER 'TEMPLATE'
MIMETYPE "application/kml" # or whatever this should be
END
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.
Steve
>>> Paul Spencer <pspencer at dmsolutions.ca> 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.
Cheers
Paul
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 dmsolutions.ca>,
> 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 ( http://www2.dmsolutions.ca/tmp/maperver-kml.pdf )
>>> and I
>>> will try fill/update things that are missing and we can go from
>>> there.
>>>
>>> Later,
>>>
>>>> Best regards,
>>>> Bart
>>>
>>>
>>
+-----------------------------------------------------------------+
|Paul Spencer pspencer at dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
More information about the mapserver-dev
mailing list