MS RFC 22a: Feature cache for long running processes and query processing (C

[Tamas Szekeres]

2007/6/12, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> I'll bite off smaller chunks for more discussion. Comments inline...
>
> >> How would do you see configuration of a capability like that? For example, a typical buffer operation would have a distance, perhaps units and maybe a corner tolerance.
> >
> > Any provider specific information would go into the metadata section
> > of that layer. So in this case we could use the following definition
> > example:
>
> We also have the PROCESSING section that I wonder if might be more appropriate than METADATA. Frank uses it as a mechanism to define raster processing parameters and already has access routines available. Would be nice to be consistent regarding configuration as new processors become available.

Generally I have no problem with this. However it's more performant to
retrieve the values from the hashtable rather than from a string
array.

>
> > LAYER
> >     CONNECTIONTYPE BUFFEROPERATION
> >     METADATA
> >         "distance"  "23"
> >         "units"   "meters"
> >          ....
> >      END
> >      LAYER
> >          CONNECTION "any other layer"
> >      END
> >  END
> >
> >  I would also allow to specify the operation parameters as feature items, like
> >  METADATA
> >      "distance"  "[distanceitem]"
> >  END
>
> >  The most trivial implementation of this buffer provider is to allow
> >  only the nested layer specification and propagate every vtable
> >  functions to the inner layer. The operation should be applied on the
> >  features retrieved by the NextShape and GetShape calls respectively.
>
> So this could be used in a non-caching environment without issue then?
>

Yes, absolutely

Tamas