Foundation and Mapserver MAP file manag e tool

[Doyon, Jean-Francois]

Steve

Re: getItem() ... Oh yeah, look at that, must've missed it.  That and
numitems should do what I need it to.

OK, so maybe not the best example, but my point remains valid :)

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

I started on something like this actually :) I created a schema parser that
turns an XML schema into something the app internally understands and allows
for further MapFile parsing.  In retrospect I would use ElementTree, but the
idea is good.

My ultimate dream would be to somehow create a mapfile parser that turns the
text mapfile internally into a fully compliant W3C DOM tree, allowing all
related tools to be used.

There are problems with granularity however.  The COLOR is a good example.
It's hard to describe the 3 values as RED, GREEN and BLUE when the structure
of the document isn't there, they're just space separated values.

I understand the arugments for and against XML mapfiles, so this reinforces
my "modularity" argument: a modular configuration interface that supports
BOTH mapfiles and xml files (and anything else one writes a "driver" for)
would be ideal.

At the very least, MapServer may benefit from reviewing some of the basic
foundations of mapfile structure to rigidify it some? (In writing my MapFile
parser, the fact "END" exists causes a surprising amount of problems, vs
something like CLASS_END for example)

J.F.

-----Original Message-----
From: UMN MapServer Users List [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On
Behalf Of Steve Lime
Sent: December 14, 2005 3:44 PM
To: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-USERS] Foundation and Mapserver MAP file manag e
tool

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

>>> Frank Warmerdam <warmerdam at POBOX.COM> 12/14/05 11:23 AM >>>
On 12/14/05, Doyon, Jean-Francois <Jean-Francois.Doyon at ccrs.nrcan.gc.ca>
wrote:
> Allow me to elaborate :)
>
> Some examples of things I ran into:
...
> - For the OO thing:  MapServer does not abstract a lot of it's 
> dependencies into consistent interfaces.  So someone who writes code 
> around mapscript needs to do a lot of a various conditional checking 
> and adapt around many possibilities.  Case in point:  Last I checked, 
> I couldn't get a list of attribute names for a given data source from 
> MapServer proper.  I need to know it's a shapefile, use a third party 
> DBF module, and do the work manually.  If the data source is postgis, 
> I need a whole different set of code and exceptions, and so on ... 
> Knowing MapServer itself is already compiled against all these things, 
> I start seriously feeling like I'm re-inventing the wheel, and adding 
> more and more dependencies ... Which is not long-term sustainable.

J.F.

I completely agree.  MapServer only demands enough from the various feature
store types to implement map rendering and simple query support.  On the
raster side things are
even more primitive.   If we want something "studio-like"
for MapServer, we really ought to start by improving the core infrastructure
to provide a better view into the underlying data sources.

Alternatively, we might see this as a reason not to go down the "approved
studio-like application" road since doing so would require quite a bit of
internal re-engineering.

At the risk of raising a hornets nest, I think MapServer Enterprise provides
much more sophisticated (though complicated) views into
the underlying datasources, and other map objects.   While I haven't
tried, I think this makes it much easier to build general purpose
front ends to it.   My personal inclination is to keep MapServer
relatively simple, even if this somewhat hobbles fronts ends like MapLab.

Best regards,
--
---------------------------------------+--------------------------------
---------------------------------------+------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent