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

[Tamas Szekeres]

Steve,

As far as I can see, your preference is to implement the clustering within
the same layer instead of referring to another layer, right?
(With regards to the parameters there's not too much difference in the
concept with having processing options vs. built in parameters.)

With this end in view, I foresee 2 main problems which is not quite trivial
in this approach.

1. How the FeatureCount parameter will be used for labelling the clustered
features?
2. How can we make the clustered features selectable (queryable). / this is
not a strong requirement of mine at this phase /


With regards to the implementation how about invoking a custom LayerOpen in
msDrawVectorLayer, something like?:

if (needtocluster)   // based of the existence of the cluster parameters
   msClusterLayerOpen(layer);  // this would override the vtable methods:
LayerGetItems/LayerInitIteminfo/LayerWhichShapes/LayerNextShape
else
   mslayerOpen(layer);

// the remaining code would be the same in effect (not modified)

msLayerWhichItems(layer);  // LayerGetItems/LayerInitIteminfo would be aware
of the FeatureCount parameter.
msLayerWhichShapes(layer, rect)  // build up the cluster database here, call
WhichItems/LayerWhichShapes/LayerNextShape for the underlying connection
type
while(msLayerNextShape(layer, shape) == MS_SUCCESS)   // shapes would be
served from the cluster database
{
     msDrawShape(shape);  // normal drawing process
}
msLayerClose(layer); // restore the original vtable



Best regards,

Tamas




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

> Sorry, I mean clustering shouldn’t be a new connection type, rather a block
> or optionally a set of processing directives, so:
>
>
>
> LAYER
>
>    NAME mypoints
>
>    TYPE POINT
>
>    # whatever data and/or connection params
>
>
>
>   CLUSTERS # or processing directives
>
>
>
>   END
>
>    # class and style info
>
>
>
> END
>
>
>
> The decision to use a block or processing directives would depend on the
> complexity of configuration. If clustering could
>
> potentially support lots of tuning then I’d favor an explicit configuration
> block.
>
>
>
> I think both pieces of functionality outlined are potentially useful. I’d
> recommend limiting the scope of the RFC to clustering
>
> to start with… There is some limited (and non-configurable) support for not
> labeling over point features already present in
>
> the label cache code so I see more limited utility in the layer combination
> portion of the RFC.
>
>
>
> Steve
>
>
>
> *From:* mapserver-dev-bounces at lists.osgeo.org [mailto:
> mapserver-dev-bounces at lists.osgeo.org] *On Behalf Of *Tamas Szekeres
> *Sent:* Tuesday, February 15, 2011 11:38 AM
> *To:* Lime, Steve D (DNR)
> *Cc:* mapserver-dev at lists.osgeo.org
> *Subject:* Re: [mapserver-dev] MS RFC 68: Support for combining features
> from multiple layers (Call for discussion)
>
>
>
>
>
> 2011/2/15 Lime, Steve D (DNR) <Steve.Lime at state.mn.us>
>
>
>
> I see value in both but kinda think they should be handled with separate
> RFCs since you don’t need one for the
>
> other and neither problem is trivial.
>
>
> Steve,
>
> I can accept to create separate RFCs (however I require them both in my
> project to succeed ;-)
>
>
>
> At least on the clustering side I don’t think that should be handled as a
> connection type. Rather I’d favor a new
>
> CLUSTER block where you’d set the various tolerance and scale values. That
> way you could add clustering to a
>
> point layer without much effort. I think it needs to be that simple.
>
>
>
>
> I don't see the difference with regards to the data processing. For the
> setting of the parameters via a CLUSTER block instead of some PROCESSING
> option doesn't seem to differ significantly. But if you want to include this
> algorithm somewhere into the MapServer core that would be another case.
>
> Best regards,
>
> Tamas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20110216/9301d575/attachment.html