Foundation and Mapserver MAP file manag e tool

[Bob Basques]

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
>
>  
>