[mapserver-dev] MS RFC 68: Support for combining features from multiple layers (Call for discussion)

[Stephen Woodbridge]

On 2/10/2011 6:04 PM, Tamas Szekeres wrote:
> Hi Frank,
>
> Thanks for the quick response, see my comments inline below:
>
>
>       1) I would be more comfortable if you didn't need to modify the
>     behavior
>         of the source layers.  Why not have the aggregate layer have a
>     list of
>         the source layers, insteading of marking source layers with the
>         target layer that will consume them?
>
>
> Technically I don't see too much difference between these 2 versions.
> However placing the reference at the source would make it easier to
> override the vtable of the source to delegate the control when accessing
> the features from the source layer. We should make sure that the feaure
> preprocessing will take place in the first access of WhichShapes from
> any of these layers. (Considering that the feature query is happening in
> reverse layer order as the drawing operations)
>
>       2) Are you planning to use the functions in maptree.c as a generic
>     quad
>         tree or are you hoping to take advantage of .qix files for shapefile
>         sources?
>
>
> I intend to use that in memory to speed up the query based on a
> rectangle area of interest during the clustering operation.
>
>       3) Are you planning to do clustering for dissimilar features from
>         different sources?  At the core I don't understand why the
>     clustering
>         needs to have multiple source layers.  It seems like combining
>         features from multiple layers and clustering features should be
>         distinct operations.
>
>
> Negotiating features from multiple layers is a part of the recent
> specification we rely on. In fact expect to create a new layer to serve
> the combined features with different symbology as the source features,
> labeled based on different (aggregate) attributes. In this regard
> there's no meaningful difference whether to use one layer or multiple
> layers as feature data sources since a new layer is required in any
> case. According to our specification I intend to support the point
> layers only.
> I don't really understand why combining and clustering would be
> different in our term.

This is more an abstract use case where separating the combining from 
the clustering might be useful.

Today, you can combine multiple files using a tileindex, but only if 
they have the same attributes, and description. In theory, it might be 
nice to be able to have multiple source layers that have similar 
attributes and to be able to combine them into a single layer using some 
compatible subset of the source column attributes so that the combined 
layer could be treated as a single layer with the benefits of LABEL 
MINDISTANCE nnn, or querying it to get a single closest object, etc.

So I think the idea of building modular filters and being about to chain 
them together might have some value. On the other hand, there maybe be 
some significant value in performance to combining and clustering in a 
single step, but you probably have a better idea based on how things are 
structured.

Regarding the whole RFC, I find it impressive and probably a little 
intimidating also. My first concern would be that I hope this does not 
impact performance in any significant way for people that are not using 
it. Beyond that, it seems well thought out, but there is a lot there and 
I think I need to read it again when my eyes are not glazing over :) 
I'll try to reread it in the morning.

Thank you for your effort in putting this together.

Best regards.
   -Steve

> Best regards,
>
> Tamas
>
>
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev