Foundation and Mapserver MAP file manag e tool

[Jeroen Ticheler]

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