Status of RFC-22?

[Tamas Szekeres]

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
>