Status of RFC-22?

[Steve Lime]

Sounds like there is still interest then, although somewhat metered by
other
project work. I certainly can understand and appreciate that. Seems to
me
that various adapters would require their own RFC as they become
necessary.
Starting with GEOS processing would make sense since you already have
a
real instance of that functionality.

I'm not sure I follow issue #1 but could see an extra copy being made
for
the cache being necessary since you want to cache the shape in raw
form.

Regarding your issue #2, I assume you're refering to the call to
msLayerWhichItems.
The reason that function even exists is the SDE interface. When I first
added
that driver the SDE APIs wanted a list of columns to retrieve so I
figured that
perhaps there was a benefit to retrieving only those actually
necessary. I'm
not sure if it's worth that effort or not. It would certainly simplify
things to
loose that capability (although certain error conditions, such as
misspellings
in expressions would be harder to detect). It probably would not be
difficult
to replace that call with the more general msLayerGetItems. The
expression
handling would need tweaking to maintain a list of items used, although
that
could be done the first time an expression is parsed. For shapefiles
the we
grab all the items regardless. Other folks that maintain a driver might
have
comments about how grabbing the whole feature might improve/hurt 
performance.

Let me know how I can help move this forward.

Steve

>>> Tamas Szekeres <szekerest at GMAIL.COM> 1/8/2007 5:50:51 PM >>>
Frankly say, this effort seems to require larger amount of work than
I've originally expected and a lot of things to be considered yet.
In the recent days I've focused mostly on the more trivial assingments
(like improving the GDAL C# interface) and certainly on the funded
projects as well.
Because of these reasons the progress of this work was deferred a bit.
But also - as I've noticed before in many times - it is useful to get
paused before taking the next big step....

With regards to this proposal I'm not considering to alter the
concepts described in RFC-22, as these changes would provide the
framework to implement the aforementioned
features in a standardized fashion. What I've promised is to write an
additional RFC that will show up how to utilize the benefits of RFC-22
to implement a layer feature caching adapter.

Certainly there are more trivial use-cases, where maintaining internal
state of the adapter is not really needed. Therefore - as the first
adaptation of this concept - last year I've made
an inhouse sample adapter that applies GEOS functions (like ConvexHull
or  Buffer) on the features coming from the provider. However some
further considerations should also be made how to utilize a flexible
way to parametrize the operations on a real implementation.

My primary aim was to implement a feature caching provider to increase
the rendering and query performance of the layers by retaining the
features have been retrieved by a preceding fetch. By this enhancement
mapserver would be suitable to provide a rendering engine for many of
the desktop GIS applications. Truth to say these applications are
suffering from the fact that mapserver would refetch all of the
features to be rendered or queried every time.
Another benefit was to decrease the threading issues might be caused
by the providers by isolating the rendering and the data retrieval.

Here are some issues that came around when starting to deal with this
implementation,

1. The retrieved feature is owned by the client of the adapter, so an
extra copy of the shape should be executed despite of the fact, that
the shape is retained in the cache.
That will slightly decrease the caching performance.
2. The current implementation retrieves the shape values as it needed.
But now, I should retrieve all of the values for getting the shape
ready for a subsequent GetShape operation.
3. To provide a way to compare the performance results, a mapscript
sample application (with much of features like pan, zoom, query by
various ways) being capable to maintain the state
of the map object should be implemented.


Steve,

Despite of your support I possibly have, I still feel myself alone
with this, and some other problems (like the problems related to
RFC-15) so it's not so easy to get across these conceps by having
enough motivation to provide a ready-to-use solution. It would be
easier if I can bind these issues to a particular running project like
earlier when this idea has presented itself.
But because of the substantial willingness, I'm keen to continue the
effort, so don't take umbrage at the procrastination of this work.


Best Regards,

Tamas



2007/1/8, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> Now that the holidays are over I'm sure everyone is playing catch-up.
I
> wanted to follow up on RFC-22. Several
> other things I'm interested in (GEOS processing adapters, query
> caching) are tied to this idea.
>
> Steve
>