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

[Steve Lime]

We'd have to retrieve parameters for each feature processed unfortunately. Too bad the PROCESSING block isn't
a hash itself...

Steve

>>> On 6/12/2007 at 1:46 PM, in message
<f3b73b7d0706121146s69a7ebf0la50bcfa011dfb642 at mail.gmail.com>, Tamas Szekeres
<szekerest at GMAIL.COM> wrote:
> 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