Foundation and Mapserver MAP file manag e tool

[Steve Lime]

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