<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Is it possible to allow MapServer to use KML, or a variation thereof?
I really don't what would be entailed. For example, KML can store
coordinates for displaying vectors, which would be pointless in our
context. Can KML point to shapefiles or tables for vectors like it can
point to TIFs for rasters? If so, it seems like the infrastructure
(styling, external editing packages, viewers, conversion tools, wide
adoption) is already there to build on. Can we pull pieces from KML to
make it easier for people to adopt without learning a new structure?
<br>
<br>
+1 on keeping the configuration maps as file based. Databases are
great for many reasons but add an entirely new level of complexity (and
points of failure) for any application.
<br>
<br>
- John
<pre class="moz-signature" cols="72">****************************************
John Callahan
Geospatial Application Developer
Delaware Geological Survey
University of Delaware
227 Academy St, Newark DE 19716-7501
Tel: (302) 831-3584
Email: <a class="moz-txt-link-abbreviated" href="mailto:john.callahan@udel.edu">john.callahan@udel.edu</a>
<a class="moz-txt-link-freetext" href="http://www.dgs.udel.edu">http://www.dgs.udel.edu</a>
****************************************</pre>
<br>
<br>
Barend Kobben wrote:
<blockquote cite="mid:C4754E22.31ED%25kobben@itc.nl" type="cite">
<pre wrap="">Hi Bob,
YES, by all means do move to XML. I think this would be a very important
step forward (and my first guess is it would be not too complicated, but you
never know...).
I do see how some might be attracted to having an DB storage too, but I
would urge you to always have that as an alternative, not as instead-of:
keep the main configuration mechanism (XML-)file based! In many use cases
there's no need for a DB and that would mean you'd have tho have a DB plus
all its hassle, only for the configuration part. Also the current file-base
config is ideal in situations were many people need to work on the one MS,
such as in our educational setup, where we have many students working on
their own config files in their private dirs, and they don't need to touch
the 'main' MS setup on the server.
Actually, what are your reasons for preferring an SQL sdolution over the
file based one...?
</pre>
</blockquote>
<br>
<br>
Bob Basques wrote:
<blockquote cite="mid:484E81EC.163B.00A8.0@ci.stpaul.mn.us" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.2800.1505" name="GENERATOR">
<div>All,</div>
<div> </div>
<div>We've been pondering some sort of alternative to the Mapfiles
for a few years now. A preferable approach would be something that
could be stored in a DB in some fashion for querying/assembly
processes. It seems on the surface like a DB schema could be developed
to handle the MapFile storage aspects.</div>
<div> </div>
<div>A first step would be in how to best approach moving into an XML
way of life for the MapFiles. Would it make any sense in the beginning
to just build a MapFile2XML convertor (I would imagine this would be
needed before anyone would sign up for XML) and once something like
this is a state close to production, the innards of MapServer would
then be made to parse the XML directly? </div>
<div> </div>
<div>Another approach might be to do something like MapFile2SQL
first, and then the MapFile2XML. This might save some time and seem
like it would make standardization easier, since it would need to be
inside of the DB fist.</div>
<div> </div>
<div>Has anyone tried putting together any requirements list along
these lines at all? Is it going to be something where we just need to
jump in and build something even if it might be a wrong approach to
begin with?</div>
<div> </div>
<div>This thread just got me thinking is all . . .you know how
dangerous that can be . . . :c)</div>
<div> </div>
<div>bobb</div>
<div> </div>
</blockquote>
<br>
</body>
</html>