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

[Tamas Szekeres]

Hi Steve,

Please find my comments inline below.


2011/2/16 Lime, Steve D (DNR) <Steve.Lime at state.mn.us>

> Actually the clustering could be extended to multiple layers using the
> second part of your RFC. You’d just embed the clustering block/params
>
> in a layer that references other layers (however that would work). That’s
> kinda why I thought the RFCs should be separate.
>
>

I agree with the statements above, absolutely.



>
>
> The feature count parameter would be a challenge regardless of
> implementation.  I need to think about this a bit. I was thinking that if a
> layer
>
> is to be clustered then:
>
>
>
> -          msLayerGetItems() would tag on a this new item in addition to
> whatever the layer defines
>
> -           the clustering operation would populate it
>
>
>
> Being able to extend a layers default item set and then populating it at
> the shape level is a need we have not only in this case. The 3D buildings
>
> idea thrown out on mapserver-users also would use this. We should consider
> an general approach to that topic.
>
>
>
> Again, let me think just a touch on this and reply back. Ideally we should
> only have to override the vtable function for msLayerNextShape(). I’m
>
> thinking:
>
>
>
> -          msLayerOpen() is unchanged
>
> -          msLayerGetItems() is smart enough to add the new item for
> feature count
>
> -          msClusterLayer() is a new function, it uses the stock
> msLayerNextShape() function to read shapes and build clusters, the feature
> count is maintained here.
>
> -          msLayerNextShape() is overridden to access the cluster cache
>
> -          msLayerWhichShapes() is unchanged
>
>
>

I would be in favour of writing the code (in mapcluster.c) in such way which
could provide the clustering in the builtin approach (you mention) and it
could eventially be a driver (ie a builtin or a plugin) as well. This would
leave the decision up to the user whether to support the query or just to
use this for rendering purposes. In this case using a custom version of
msClusterLayerOpen (being called from msDrawLayer) would be quite
straightforward to implement. msClusterLayerOpen could do any vtable
adjustments as required for the driver.



> This would then require almost no change to existing code… You could use
> the inline feature list already present in a layerObj to store the clustered
>
> Shapes. Of course then you couldn’t cluster inline shapes but perhaps
> that’s not a big deal (wouldn’t think it would be).
>
>
>

I'm a bit reluctant to use the inline feature list for now. Since the
clustered features are in place, there's no need to populate a new list with
the features. In addition, the inline features are written in the mapfile as
well which is a fairly unwanted effect.



> For querying, hmmm… Let me think on that too…
>
>
>

In this case the user would use the separate layer with this new
connectiontype, where the clustered features would be available for the
query as well.

Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20110216/279c448e/attachment-0001.html