Foundation and Mapserver MAP file manag e tool

[Doyon, Jean-Francois]

Bart,

I totally agree and would support such an initiative.

+1 from me.

J.F.

-----Original Message-----
From: UMN MapServer Users List [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On
Behalf Of Bart van den Eijnden
Sent: December 14, 2005 1:22 PM
To: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-USERS] Foundation and Mapserver MAP file manag e
tool

Seeing the amount of reactions, maybe it would still be an idea to form an
interest group for this? One of the things I'd hate to see happen (and what
is happening already) is all these initiatives being explored parallel,
whereas IMHO we should be combining forces on this as a community, since it
is a significant effort which also needs careful thought.

Could space be arranged on the plone site for instance for an interest group
to communicate? What do others think?

Best regards,
Bart

Frank Warmerdam wrote:

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


-- 
+------------------------+
| Bart van den Eijnden   |
| OSGIS, Open Source GIS |
| http://www.osgis.nl    |
+------------------------+