Foundation and Mapserver MAP file manag e tool

[Doyon, Jean-Francois]

Allow me to elaborate :)

Some examples of things I ran into:

- How to support different versions of mapserver, and mapfiles:  Try to
create the concept of "schemas" for mapfiles, and turn mapfiles into
DOM-like structured instances, and dynamically loading the right mapscript
version, and so on ... This makes another case for XML mapfiles, or at least
a more rigid structure for the existing syntax.

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

This is where I stopped :)

I think the general approach to mapserver development should be first and
foremost a "library" ... Around which various things (Like the CGI, or
PHP/Python module) are implemented.  This forces a more abstract and
consistent API, easier to re-use.  Also seperates it from being "web-bound",
allowing use in other environements, namely, in this case, desktop apps.

I know there's efforts going on re: a pluggable input driver framework,
which I think is fantastic ... I think mapserver needs more efforts like
this towards modularity.

Having looked at Eclipse's Plug-In framework for this exact purpose, I can
assure you, much of these same issues would come up there too ... Operating
strictly on MapFiles as text can be done easily enough (In Python, I have an
ElementTree driver for them for example! Which I should really share at some
point :P), but once you bring in MapScript and Map Rendering and true user
interactivity, that's a whole other ball game.

My .02$
J.F.

-----Original Message-----
From: Sean Gillies [mailto:sgillies at frii.com] 
Sent: December 14, 2005 11:41 AM
To: Doyon, Jean-Francois
Cc: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Re: Foundation and Mapserver MAP file manag e tool

J.F.,

I don't think a MapServer workbench (since "Studio" is taken) would
necessarily need to be any more OO than MapServer itself. All you need to
start is to allow people to visualize and save style, class, and layer
mapfile fragments, and then mix fragments together into a single mapfile for
export. IIRC, there is even some very preliminary support in MapServer for
instantiating objects from mapfile fragments.

cheers,
Sean

On Dec 14, 2005, at 9:13 AM, Doyon, Jean-Francois wrote:

> I agree for the need for such a tool ... We've been dying for one 
> here.  I also don't think it should be web based, but something that 
> geographers/cartographers could easily use, so a desktop application, 
> a la "Workbench"/ArcMap/etc ...
>
> I actually started writing one using Python/wxPython!  But quickly ran 
> into issues with some of the design of MapServer, and problems 
> integrating it into a desktop app (vs. the web).  If anyone is 
> curious, I could share my experiences in this department.
>
> I've since discovered and learned to love Eclipse though, so there's 
> definite potential there!  That'd imply a well supported Java 
> MapScript though ... Is it mature? (And even then, as I suggested, 
> some changes to mapserver would be necessary, bringing a C program 
> into a purre OO world presents interesting challenges ...).
>
> Such a project could eventually find itself in the foundation, but 
> yes, it's inception should be community driven.
>
> J.F.

---
Sean Gillies
sgillies at frii dot com
http://zcologia.com/news