[mapserver-dev] Expanding the MapServer Project

[thomas bonfort]

I do not find it a hindrance that tinyOWS will not support all OGR
datasources for the same reasons that have already been exposed by
others, i.e. that there is in practice very little usage in allowing a
flat-file to be edited concurrently through webservices.
It would be great if the other main spatial-db were also supported,
but that can be done in a second phase (i.e. probably when someone
wants to fund it).

regards,
thomas

On Fri, Mar 25, 2011 at 14:06, Jeff McKenna
<jmckenna at gatewaygeomatics.com> wrote:
> Before we move forward with this I'd like to hear the comments from all of
> the PSC regarding TinyOWS and its database support (as far as I know it
> still only supports PostGIS connections).   Is there a plan for TinyOWS to
> leverage OGR to connect to supported databases?  For example, the ZOO
> project uses OGR to connect to any OGR-supported database for MapServer
> WFS-T connections (if you don't believe me, check it out yourself:
> http://zoo-project.org/site/ZooWebSite/Demo/WFS-T)
>
> If MapServer adopts TinyOWS, am I correct to assume that OGR would be
> leveraged for WFS-T connections?
>
> -jeff
>
>
>
> On 11-03-24 1:47 PM, Lime, Steve D (DNR) wrote:
>>
>> Hi All: Wanted to drop folks a note about a topic that came up over
>> beers in Montreal. It has to do with expanding the core functionality
>> the “project” can deliver by bring a few select external projects in
>> under the MapServer umbrella. The two we were thinking about initially
>> are mod_geocache (for tiling support) and TinyOWS (for basic WFS-T).
>> Why? Well, beyond the technical connections to MapServer there are
>> several reasons.
>>
>> For MapServer users this would provide a more complete set of
>> functionality on the server-side than is currently available. Instead of
>> sending folks to an tilecache or whatever for tiling, and GeoServer for
>> WFS-T we could provide much of that functionality as part of the core.
>> That’s not to say that folks couldn’t or wouldn’t want to use the
>> external solutions but in many cases we could deliver a complete solution.
>>
>> For these external projects moving into MapServer provides a home. Both
>> of the projects mentioned are relatively small and MapServer would help
>> establish a user base for them and hopefully increase their level of
>> adoption. I think it could also attract new developers, at the very
>> least those with commit rights for MapServer. This will also promote (or
>> perhaps even force) tighter integration with MapServer core. An initial
>> idea is pulling mapfile handling out into a libmapfile that could be
>> used and maintained cooperatively.
>>
>> Bringing projects into MapServer is not a trivial activity and would
>> take some time. We’re thinking it would involve tasks such as:
>>
>> - Vetting source and licensing of incoming projects (e.g. akin to OSGEO
>> incubation)
>>
>> - Source, testing and build environment restructuring
>>
>> - Integration/migration of svn and trac (or the like) environments
>>
>> - Integration/migration of websites and documentation
>>
>> Finally, the MapServer PSC would become the governing organization for
>> these new pieces. As a result, it would make sense to add the project
>> leads for each project to the PSC (Thomas Bonfort (mod_geocache) is
>> already a member).
>>
>> This is the first significant project restructuring for MapServer, but I
>> think it makes sense and positions MapServer as more than just a map
>> maker. Thoughts?
>>
>> Steve
>>
>> (Note: I shared this privately with the MapServer PSC to gauge interest
>> and was encouraged to bring it to the –dev list…)
>>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>