Hi. I think that the filter shouldn't be limited as 'PropertyName' because
I've used it at a client side operation which needn't have type definitions
with FeatureStore. As an example, using the filter in a 'Rule' of SLD that
operate between geometry objects.
Sample code:
Filter filter = factory.
Fair enough, you guys win :).
Jody Garnett wrote:
> Justin Deoliveira wrote:
>> Hmm, fair enough, if it is limiting it is limiting... but do you have
>> an example of where it is too limiting? The problem i am running up
>> against right now is when a "empty" property name is supplied as part
Justin Deoliveira wrote:
> Hmm, fair enough, if it is limiting it is limiting... but do you have
> an example of where it is too limiting? The problem i am running up
> against right now is when a "empty" property name is supplied as part
> of binary spatial op.
We had a choice between:
- Expre
SLD and Filter both allow specification of geometry property to use.
I suspect defaultGeometry is a convenience for lazy configuration, but
also allows re-usable SLDs I guess.
The semantics are vague - I'd just choose the first geometry that
matches the available symboliser, for SLD and perhaps
Hmm, fair enough, if it is limiting it is limiting... but do you have an
example of where it is too limiting? The problem i am running up against
right now is when a "empty" property name is supplied as part of
binary spatial op.
Now does this mean that we should get the "default geometry", o
Hi Justin,
I worked through this a couple months ago - and came to a different
conclusion I did not think we could ask people to be limited by the
specification in this manner. So I place Expression on both sides of the
Operator and placed the limitations on FilterFactory, and took them off
