Mapscript could use a ShapeCollection class to increase efficiency of drawing, projecting

[sgillies@…]

A common use case for swig mapscript is reading of data from some format
or storage unsupported by mapserver, projecting, and drawing the data as a map
layer.  There's a fair amount of extra overhead when drawing shape by shape
using the mapscript shapeObj.draw method.  I recently checked in some timing
benchmarks under python/tests/timing that have helped me understand how much
more costly it is to draw shape-by-shape.

We could benefit from a ShapeCollection class that would let mapscript users 
manipulate and draw any number of shapes as an ensemble.  The SWIG wrapper code
would be executed once for the ensemble rather than for each shape, and the
overhead could be greatly reduced.

In the drawing case, I see no reason why drawing a collection of N shapes can't
be made just as fast as calling layer.draw for a shapefile layer of the same
N shapes.  Perhaps even faster in some cases.

[dmorissette]

Can't you do that by adding inline features to a layer? I never used inline
features, but I thought that's what the $layer->addFeature() was for.

[sgillies@…]

You're right that my use case, as written, is well covered by inline layer
features.  Querying works as well for inline layers?

For other reasons I'd like to avoid using the inline features.  I'm thinking of
applications where a collection of shapes might be used in several different
contexts, and it would be a bother to trap them inside a layerObj.  Furthermore,
I'd like to have the option of reimplementing the shape collection in a way 
that's more high performance than layer inline features.

What about the possibility of attaching the shape collection, if needed, to
a layer through a layerinfo connector?

[sdlime]

That's sort of what inline features are for. You can add a pile of features to 
a layer and then draw with map or layer draw method. I suppose we could turn 
that process inside out a bit and expose the feature list structures as an 
object and set a draw method there too (same args as shapeObj->draw...).

Steve

[sgillies@…]

Steve, Daniel, thanks for the feedback.

For now, I think that I will go the route of making our existing feature list
a first class object.  My time frame for working on this is through the 
end of September.

[sgillies@…]

No longer needed.  Closed.