Hi Andrea; just to let you know there have been some request on the user
list about making the method names consistent. If you can consider the
following requests I would like your feedback.
- FeatureType.getAttribute(): AttributeDescriptor
- Feature.getAttribute(): Attribute
The duplication of method names results in hard to understand code. Here
is the suggested improvement:
- FeatureType.getAttributeDescriptor(): AttributeDescriptor
- Feature.getAttribute(): Attribute
Now it may be a case of - too late. I will understand if that is the case.
Remaining comments inline.
Andrea Aime wrote:
> Hi,
>
> I'm trying to continue Justin's work on simple features backed
> by arrays of Objects and I'm having issues with validation,
> it seems to me I've found a design flaw with restrictions.
>
Cool. As I recall restrictions are captures as a Filter.
> Restrictions in the new feature model are created by
> using Filter objects attached to the attribute type definition,
> the filter is applied to the value and
> it has to decide whether it's valid or not.
>
> With the standard Feature implementation the "value" is in
> fact an Attribute, meaning not really just the value, but
> also its name and whatnot. Given a filter such as
> "len(myStrAtt) < 3" to be used as a restriction, the evaluation
> over the "value" goes fine because we have a PropertyAccessor
> that is able to evaluate myStrAtt against a Property, which
> Attribute is a subclass.
>
> Enter the "real" simple feature. There is no Attribute around,
> we only have the AttributeDescriptor on one side, and the
> actual value on the other. Trying to apply the above filter
> on the value fails. Trying to wrap the value into a
> Attribute built just for the sake of validation works,
> but seems "wrong". Given the AttributeType and the value
> the validation should have all it needs, no?
>
I think the problem is this; filters make use of the assumption that a
propetyName expression can be used to obtain the value. In the case of a
"naked" Object we have no valid name representing "this".
So two suggestions:
- use the property name "this"; or use the property name "value" and
proceed with life.
> The problem seems to be logical to me thought. The validation is
> expressed at the level of AttributeType, a level where the
> attribute name is not even known (the actual attribute name is
> in the descriptor). As such, the filter that sets up a restriction
> should not try to use the attribute name at all, but use
> a generic way to say "the value", whatever is the value passed
> to the filter for evaluation.
>
We are in agreement.
You will notice we have a similar problem in determining the "default"
geometry; we ended up using empty string ie ff.property("") as a special
case.
The expression resulted in:
ff.contains( ff.property(""), ff.literal( polygon) );
The idea was that "" represented an xpath pointing at the feature;
This boils down eventually to a call to:
expression.evaulate( feature, Geometry.class );
In effect we are asking for the feature; evaulated into a Geometry - a
good definition of a default Geometry as anything.
Still it may be better to review the xpath notation; perhaps something
like ff.property(".") is more explicit?
> The fact that the validation works with the current simple
> features is purely incidental, because AttributeType and
> AttributeDescriptor share the same name, but that's not
> true in general. Yet, a filter specified of a restriction
> of the type should be logically using the name of the type,
> and not the name of the descriptor (whilst the Attribute name
> is the one of the descriptor).
>
Thanks Andrea you have indeed found a flaw; but not one that we totally
need to fix until Gabriel has the complex datastore stuff working again.
> Is there any way to setup an expression that returns the "feature" itself,
> that is, one that always does satisfy:
> expr.evaluate(a) -> a
>
Right now we use ff.property(""); but I suspect if we look at xpath that
ff.property(".") will actually be correct.
> If we had that kind of expression, let's call it <theValue>, then
> the attribute validation above could be expessed as:
> "len(<theValue>) < 3"
> and that could work in all cases.
> It seems to me that the opengis model does not have such a thing,
> which would imply the validation on GeoAPI is ill defined?
>
> Opinions?
>
Right on Andrea; I remember this (along with the method names) as
something we were going to revisit after we had some hands on
experience. So do we feel experienced now?
Jody
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
