<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.2800.1505" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Comic Sans MS">
<DIV>John,</DIV>
<DIV>&nbsp;</DIV>
<DIV>You're starting to think about two different applications of XML.&nbsp; I was interested in setting up the XML to reflect the typical MapFile contents and use the XML for the Map generation out of MapServer.&nbsp; KML is a output format option, that would be output by MapServer, (possibly using this new XML MapServer control) to format the KML output.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I would still tend to keep the configurations as file based as well, the DB approach just aloows for much more flexibilty for those hardcore programmers, and the MapFiles, don't input into a DB very easily.</DIV>
<DIV>&nbsp;</DIV>
<DIV>bobb</DIV>
<DIV><BR><BR>&gt;&gt;&gt; John Callahan &lt;diodata@udel.edu&gt; wrote:<BR></DIV>
<DIV style="PADDING-LEFT: 7px; MARGIN: 0px 0px 0px 15px; BORDER-LEFT: #050505 1px solid; BACKGROUND-COLOR: #f3f3f3">Is it possible to allow MapServer to use KML, or a variation thereof?&nbsp;&nbsp; <BR>I really don't what would be entailed.&nbsp; For example, KML can store <BR>coordinates for displaying vectors, which would be pointless in our <BR>context.&nbsp; Can KML point to shapefiles or tables for vectors like it can <BR>point to TIFs for rasters?&nbsp; If so, it seems like the infrastructure <BR>(styling, external editing packages, viewers, conversion tools, wide <BR>adoption) is already there to build on.&nbsp; Can we pull pieces from KML to <BR>make it easier for people to adopt without learning a new structure?<BR><BR>+1 on keeping the configuration maps as file based.&nbsp; Databases are great <BR>for many reasons but add an entirely new level of complexity (and points <BR>of failure) for any application.<BR><BR>- John<BR><BR>****************************************<BR>John Callahan<BR>Geospatial Application Developer<BR><BR>Delaware Geological Survey<BR>University of Delaware<BR>227 Academy St, Newark DE 19716-7501<BR>Tel: (302) 831-3584&nbsp; <BR><BR>Email: john.callahan@udel.edu<BR><A href="http://www.dgs.udel.edu/">http://www.dgs.udel.edu</A><BR>****************************************<BR><BR><BR><BR>Barend Kobben wrote:<BR>&gt; Hi Bob,<BR>&gt;<BR>&gt; YES, by all means do move to XML. I think this would be a very important<BR>&gt; step forward (and my first guess is it would be not too complicated, but you<BR>&gt; never know...). <BR>&gt;<BR>&gt; I do see how some might be attracted to having an DB storage too, but I<BR>&gt; would urge you to always have that as an alternative, not as instead-of:<BR>&gt; keep the main configuration mechanism (XML-)file based! In many use cases<BR>&gt; there's no need for a DB and that would mean you'd have tho have a DB plus<BR>&gt; all its hassle, only for the configuration part. Also the current file-base<BR>&gt; config is ideal in situations were many people need to work on the one MS,<BR>&gt; such as in our educational setup, where we have many students working on<BR>&gt; their own config files in their private dirs, and they don't need to touch<BR>&gt; the 'main' MS setup on the server.<BR>&gt;<BR>&gt; Actually, what are your reasons for preferring an SQL sdolution over the<BR>&gt; file based one...?<BR>&gt;<BR>&gt;<BR>&gt;&nbsp;&nbsp; <BR></DIV></BODY></HTML>