Jody Garnett ha scritto:
> 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
Yes, I like the proposed solution better. I believe the original method
names were shortened to save space.
Anyways, that's a GeoAPI change. I'm favourable, but not very keen to
work on it as you may already know.
> 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;
Yeah, noticed it... quite frankly, it sounds hacky because it's
not very "intuitive", the same expression could be very legitimately
used to represent the current path. Or, if you look at it from the
xpath angle, simply an invalid expression.
> 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?
Oh yes, this one I like, xpath consistent, familiar to anyone that has
any familiarity with a file system too. Actually it seems the correct
way to do even from an OGC point of view.
...
> 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.
Eh, not exactly. While working on performance I noticed that all the
"len(att) < N" restrictions that the shapefile datastore creates
were not evaluated at all because the builders created the restriction
using the type name, when the type name was still not set, resulting in:
"len(null) < N" (which coincidentally was always true).
I'm actually thinking of adding a simple validation in the simple
feature builder that makes sure the restrictions are not using attribute
expressions when the attribute type is a Feature itself.
That should at least be good temporarily to spot all the datastores
that are building faulty filters.
> 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?
Well, frankly I haven't worked much on gt2 trunk so I don't feel
very "experienced", but I have some time to fix this stuff now.
Tomorrow may be too late.
Cheers
Andrea
-------------------------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
