KML output format?

[Steve Lime]

Even with a custom driver it would be desireable to have it accessible
to process 
features via a draw or query function. The GML writer could be extended
that way 
too and registered as an output format.

Steve

>>> Daniel Morissette <dmorissette at MAPGEARS.COM> 1/4/2007 12:50:58 PM
>>>
Steve Lime wrote:
> I was thinking of something like this in a more general sense, that
is
> being able to
> return a set of features from a query (even selection by bbox is
really
> just a form
> of a query) through an OGR driver. That way you could support
creating
> KML, Shapefiles
> or whatever OGR supports via MapScript, the CGI, WMS or WFS.
> 
> I don't think concentrating on just WMS, or just KML makes good
sense.
> 

I thought about an OGR driver too, that would be very useful in several

situations but I had come back to the direct KML output format option 
since that seemed simpler to implement.

Unfortunately for the KML case using OGR to generate the output would 
not allow us to easily apply styles (colors, symbols) to the shapes. We

would probably need to generate OGR style strings in MapServer to pass

to the driver and extend the OGR-KML driver to support style strings (I

assume it doesn't at the moment). There is also the overhead of having

OGR write the output to disk and then having MapServer read and return

the contents of the output. Also what to do with formats that generate

multiple files (e.g. shapefiles, TAB datasets, etc.)? Should MapServer

zip them up before returning them? And if yes how does MapServer know 
exactly which files to include in the ZIP for each OGR output format? 
Actually, how is this handled at the moment with GDAL output formats?

An OGR output driver is definitely feasible and means more reusability,

but that's also more involved than a direct KML output format 
implementation, that's why that was not my preferred option initially.

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/