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

[Lime, Steve D (DNR)]

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.

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

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).

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

Steve

From: Tamas Szekeres [mailto:szekerest at gmail.com]
Sent: Wednesday, February 16, 2011 6:27 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)

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<mailto: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> [mailto: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<mailto: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<mailto: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/57a4d689/attachment-0001.html