Fully support this! I'm also looking for a DTD/schema that can
produce valid Map files.
MapServer may have to be modified in some parts to make sure it is
consistent throughout when running map services based on files
created by the schema.
Also OGC specific parts have to be included in such schema to make
sure we can quickly generate valid map files with OGC WMS/WCS and WFS
support.
I would like to use such such schema to create XSL transformations of
metadata (ISO19115) stored in GeoNetwork opensource to generate map
files for data producing OGC services (even on the fly).
I would also use it to do XSL transformations of AXL documents I
export from ArcMap using the MXD2AXL I developed to create map files
straight out of ArcMap.
Ciao,
Jeroen
On 15 Dec 2005, at 00:01, Bob Basques wrote:
Steve,
Ok, now we're talking, XML!! Yeah, I even have a body here I can
put to work on something like this with some direction from the
rest of the community.
While our install has a specific need for this type of MAP file
description, I would prefer to put the effort into something that
the whole community would use and not build it specifically for our
install, which is what I had planned (very soon).
I've been thinking about this for a couple of weeks actually, and I
think most capabilities discussed so far can be handled just as
Steve describes, by building upon the existing MapServer config tools.
My (our) focus is on making the admin of a layer as simple as
possible for a dataset owner. A Web interface into management of
individual layers complete with previews of how the layer looks
would be the perfect solution we would be looking for (and were
planning on building) our own version of this tool, we are already
administrating layers seperately, but have no tool as of yet for
the individual users to admin their respective layers with respect
to styling and symbology.
Yes, we let the individual dataset owners handle the configuration
of their own dataset. The Biggest reason this is a good solution
for us, is that we treat each layer as a seperate service call to
the MapServer and use DHTML to display each layer in a stacked
format (tranparent BG, etc). This configuration prevents any one
data owner's mis-configuration from bringing down the whole system,
only their layer (or service) is broken.
I mention all of this to give folks a clear idea of what
specifically we're after with regards to User config capabilities.
It may not be the same thing that others are looking for.
As a side note, I've begun exploring placing our custom DHTML Map
View client out into the OpenSource Community as well. Not sure
yet if we should serve it up on our own for awhile or try something
within the new foundation model. Either way we're just about ready
to go ahead with this work within the next couple of months. I
would prefer to see some direction from the makers and shakers here
on the list though.
bobb
Steve Lime wrote:
Great discussion!
I don't think you'd really have to add that much to the underlying
feature
store access to get a lot of benefit. Biggest hole is probably in =
attribute types.
MapServer doesn't care about the underlying type so it doesn't ask
for it. =
That
would really be nice to have with something like WFS schema
production.
If all raster goes though GDAL can we simply wrap access to
underlying =
GDAL
metadata functions?
J.F. You can get at the underlying item names. Through MapScript
opening
a layer gets the list and you can use getItem to retrieve them. We
haven't =
taken
the time to expose that list in a language convient way. With the
CGI the =
[items]
tag gets you a delimited list for any datasource being queried.
MapServer needs to stay true to what it is good at and a
management tool =
should
strive to do the same.
I've wondered if we could simply work off of an XML schema
describing an =
XML
representation of a map file (use XSLT to transform to a production =
mapfile) and
use relatively simple Java MapScript for sample map/component
production =
and
data discovery.
Steve
