RFC 33: Removing msLayerWhichItems()...

[Tamas Szekeres]

Steve,

More comments/questions added:

2007/7/10, Steve Lime <Steve.Lime at dnr.state.mn.us>:
>
> > 1. It seems we would let the drivers set the items array implicitly
> > upon the LayerOpen call. It would require to change the current
> > behaviour of all of the existing drivers.
>
> Yes, but this may be a small change since the function msLayerGetItems
> already exists for each layer.
>

Does it mean you would get rid of LayerGetItems, LayerInitItemInfo,
LayerFreeItemInfo, LayerCreateItems from the vtable since these
functions will be called internally by the drivers and useless for the
external parts of the project.

>
> > 6. Not sure about the inline layers, it does not implement GetItems
> > currently so msLayerWhichItems might not be eliminated entirely.
>
> Inline layers don't have items. This change might actually allow for them. We could
> allow inline layers to define the items array in the mapfile and via mapscript.
>

Currently we can also use AddShape  for adding the shapes to the
inline layers from the mapscript interface. Those shapes can have
items (or at least the interface allows to have) and we might want to
provide the rendering capabilities regarding those items as well. I
think it's probably working (by using the whichItems concept) right
now, I haven't tested it though.

> > Wouldn't it be more feasible to keep msLayerWhichItems which would be
> > responsible to call msLayerGetItems to set up the items array by the
> > drivers, and set the itemindex values as it stands now. In this regard only one
> > function would be altered.
>
> There are other benefits for setting item index values during processing, primarily
> surrounding changing attribute bindings or expressions. It sucks to have to make
> sure you call a method (e.g. prepareMap) that populates item indexes before
> doing something.
>

I continue to think that those values should only be altered when the
underlying parameters change that is: When the items array of the
layer or the ***item strings are modified.


> > I'm not sure about the final goal (removing double-pass query) either.
> > According to the previous posts we would keep the shapeObj-s inside
> > the resultcacheMemberObj-s but we would not want to keep the
> > compatibility with the existing scripts (which use GetShape call to
> > retrieve the members).
> > Instead we would want to introduce a new function to retrieve the
> > shapes from the resultcache.
>
> I don't know that you'd need a new function. The shapeObj would be
> there alongside the shapeindex and tileindex values. That's another
> RFC though... ;-)
>

It would require a new property or method in the mapscript interface
and the users should modify their scripts to use this member instead
of using layerObj.GetShape when retrieving the shapes from the result
cache.


<OFF-TOPIC>

> > In addition we address caching only the results of a query and it will
> > eventually involve 2 passes (one for the query and one for the further
> > rendering by drawQuery for example)
>
> I don't know that you can get away from looping through result sets
> multiple times unless queries were tightly integrated into msLayerWhichShapes
> and msLayerNextShape. I have thought about doing just that. That is,
> you move the filtering found in the msQueryBy...() functions out to the
> drivers. Problem is that complicates the drivers and potentially causes
> performance problems with simple drawing. Plus there are features like
> class filtering and templating that don't work in that scenario. So I think
> it's best to leave the query functions as is. There are always opportunities
> to move more processing off to the more capable backends within the
> query functions.
>

Looping through the result set is not a problem since the features are
retained in the memory with this concept. However in a typical
scenario the same set of the shapes might be retrieved twice from the
driver. For example querybyattributes iterates through all of the
shapes when doing the query and later on, the shapes are retrieved
once again when the layer is rendered (by using drawQuery for
example). The concept provides to cache only the query result set but
not all of the features in a given extent. Recall that RFC22a would
provide both of these options depending on the user configuration (how
the layers are linked to each other).

However I cannot argue with the concept of restricting mapserver for
the purpose of rendering maps on the web. In this regard a low memory
usage operational model might be the most sufficient.

But when we are thinking of mapserver from a broader look and would
want to make it appropriate for the long running (eg. desktop)
processes as well, then the more memory usage in exchange for the
increased responsiveness can be tolerated so caching more of the
shapes would be a feasible option.

</OFF-TOPIC>

Best regards,

Tamas