[mapserver-dev] spatial restriction for queries / ms-rfc-22a

Martin Kofahl M.Kofahl at gmx.net
Fri Oct 9 06:57:49 EDT 2009


Hi Tamas,
this is a very interesting rfc. I'm still reading through your patches in order to follow the examples as I haven't heard of vtables yet. Can you please clarify some things for me?

- Any filterings are probably done in mapfilter.c, currently for MS_SHAPE_POINT/LINE/POLYGON. Does this has to be extended for all other types including raster? 

- There's a mail on the list saying that performance is quite slow. Have you done any measurements?

- There's no vote on this rfc. Does it make sense to work on it, so how are the chances that your concept will go into the development version.

- Can you give an abstract of work which is to be done?

Thank you!
Martin

-------- Original-Nachricht --------
> Datum: Sun, 4 Oct 2009 20:48:08 +0200
> Von: Tamas Szekeres <szekerest at gmail.com>
> An: Martin Kofahl <m.kofahl at gmx.net>
> CC: mapserver-dev at lists.osgeo.org
> Betreff: Re: [mapserver-dev] spatial restriction for queries

> 2009/10/3 Martin Kofahl <m.kofahl at gmx.net>
> 
> > What is your (and other MapServer devs') opinion about a having a
> spatial
> > access control system inside MapServer?
> >
> >
> Martin,
> 
> I admit I haven't studied all aspects of this proposal, but it looks like
> as
> it would be an example of an "extension layer" addressed by one of my
> previous RFCs,
> http://mapserver.org/development/rfc/ms-rfc-22a.html
> 
> (Note: The title of this RFC doesn't completely reflect the proposed
> concept, the feature cache would only be just one simple usage example of
> that. I should probably rename this RFC to something like: "Support to
> implement extension layers").
> 
> In this case the the layer would be defined in a cascaded fashion in the
> map
> file. The outer layer would be able override the vtable functions of the
> inner layer, therefore a subset of the features could also be hidden
> according to a custom logic when displaying the whole layer. I this
> regard,
> it wouldn't be required to define 2 sibling layers (which is quite
> annoying
> here), the outer layer would contain the select shape, and the vtable
> functions could eventually implement reading the env variables as
> required.
> 
> In case if this common infrastructure would exist in MapServer, then you'd
> only require to write your custom layer data provider (ie. the vtable
> functions of a new layer type) which could eventially be a plugin
> (independent from the mapserver codebase).
> 
> By all means, my preference here would be to establish a common
> infrastucture where various special requirements could easily be
> implemented
> without affecting the core funtionality too much. Your intents seems to be
> just a simple use case of the need to extend/override the functionality of
> the existing layer data sources which should be handled in a common way.
> 
> At that time when this proposal have been created (along with working
> patches, see the corresponding ticket) I couldn't gather any community
> support to make it realized in the development version. At this time I'm
> not
> too keen to spend more efforts on this, however I would personally support
> any effort to implement a concept which could be extensible such way.
> 
> 
> Best regards,
> 
> Tamas


More information about the mapserver-dev mailing list