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?
+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.
- John
****************************************
John Callahan
Geospatial Application Developer
Delaware Geological Survey
University of Delaware
227 Academy St, Newark DE 19716-7501
Tel: (302) 831-3584
Email: [EMAIL PROTECTED]
http://www.dgs.udel.edu
****************************************
Barend Kobben wrote:
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...?
Bob Basques wrote:
All,
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.
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?
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.
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?
This thread just got me thinking is all . . .you know how dangerous
that can be . . . :c)
bobb
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
