feedback on possible mapserver enhancements

Christopher Schmidt crschmidt at METACARTA.COM
Tue Feb 5 16:27:16 EST 2008


On Tue, Feb 05, 2008 at 02:30:12PM -0600, Steve Lime wrote:
> Maybe folks just want some FeatureServer-like functionality... (yes, I know that's already been written too)

If they just want FeatureServer-like functionality, it's likely that
they should be looking at something like-FeatureServer.

Is there a cost to installing FeatureServer? Yes. 
Is there a cost to developing Feature Updating Services in MapServer?
Absolutely.

I don't think we have a strong enough idea of what users actually want
from updating features in MapServer to understand whether the total cost
on users of installing FeatureServer is more or less expensive than the
total costs of modifying MapServer to do it.

I think that, based on my (admittedly limited) understanding of
MapServer's internals, developing Feature updating support is unlikely
to be a seamless integration. The reason for this is that MapServer
supports multiple different vector providers (as I understand it): there
is 'built in' support for Shapefiles and PostGIS, as well as support for
'external' vectors via OGR. I believe that MapServer does have an
internal representation of features -- but how do you take thosoe
features and update a PostGIS layer where the CONNECTION string is based
on a subselect? Can you really know that you have enough information to
update the datasource without it being specifically configured for
updates... and if the user has to learn a lot to configure MapServer to
do this updating, is that really lower cost than installing
FeatureServer (which really only requires Python)?

The cost of building something like FeatureServer in C is high -- this
is why it's written in Python in the first place. Reading in GML --
especially when people expect to be able to throw random crap at you --
is possibly hard, and ensuring that it fits a schema may be harder, etc.

FeatureServer has survived through this becasue:
 1. It's specialized. Since the entire framework is written with the
    challenges of the problem in mind, it's well-suited to the solving
    the problem: there is nothing like a subselect-query from
    FeatureServer, because that's not something you can update. 
 
 2. It's easy to hack to bits when something doesn't work: Python is way
    more hackable than C, so I've been able to hack it apart
    significantly in order to change support for just the PostGIS
    provider (for example).

 3. The abstraction barrier between datasources and output is well defined.
     Everything is super-seperated, and the end result is that
     DataSources have no knowledge of the formats that features are in.
     This is a problem for implementing WFS-T, for example, because
     information in WFS-T isn't passed along in the feature model of
     FeatureServer (because it's solving a different problem).

All these things allow FeatureServer to be much more quick to respond to
problems with specific setups -- and also lead to a situation where
MapServer is not (based on my understanding) in a suitable flexible
position to be able to implement the types of actions that are being
discussed.

I'm interested in understanding why FeatureServer is so much more
difficult than MapServer to get installed: It seems to me like it would
be easier to set up FeatureServer in almost any environment than
MapServer would be, but maybe I'm not understanding something. Perhaps
attacking that problem, if it exists, would reduce the feeling of a need
for FeatureServer-like access to MapServer. 

FeatureServer is about Serving Features. MapServer is about serving
*maps*, and anything that isn't about *serving maps* should perhaps be
considered strongly before too many people get in a rush to change the
situation. There's a lot of differences between something like
FeatureServer and MapServer which make the fundamental development cost
seriously different between the two libraries, and it seems to me that
perhaps there are other problems that it would make more sense to solve
in MapServer while addressing the need to make select/update/modify/delete
of features more easy seperately. 

Regards,
-- 
Christopher Schmidt
MetaCarta



More information about the mapserver-dev mailing list