Hi all,
I've reviewed Justin work, Jody featureland document, and this
is my take on them. Warning, long email, thought most of what
I'm going to say is not earth shattering.
About the javadocs
--------------------------------------------------------------
First off, Justin, nicely done, the Property/Attribute/... javadoc is a
pleasure to read, short clear and to the point, now and most things make
sense right away. The PropertyType/AttributeType/... still seems
to be wacky thought.
Ok, from top to bottom, some comments on the amended interfaces.
* PropertyType.getRestrictions(): List<Filter>.
Does this list include the parent restrictions? Would be nice so.
Given that we have and filters, couldn't this method be just
PropertyType.getRestrictions(): Filter?
Pro: easier to test if the value is a good one
Cons: no way to tell which filter failed (to make this useful
we would have to make sure Filter toString() returns a good
representation of it, something we already have in our
implementations if I'm correct.
* AssociationType javadoc.
We should have the notion of simple association in the javadoc
as well... I mean, a business partner association is not
aggregation and I may not be interested in making the spatial
or temporal side of it explicit.
Javadoc still uses first person ("I am treating the domain
of the association type...").
AssociationType.getRestrictions() is simply repeated, no
extra info on it compared to the base class, same goes
for isAbstract().
If both Association and Attribute can be identified, can't
we move that bit of metadata on PropertyType?
* AttributeType javadoc... ugly.
* ComplexType
In the javadoc, the bar property descriptor should report
nillable == false.
* SimpleFeatureType
"attributes are non qualified". Hum, what do we do with
GML Feature attributes like gml:name?
"the multiplicity of attributes is always assumed to be
1, ie, getMinOccurs() == 1 and getMaxOccurs() == 1."
What, no nullable attributes anymore? We can't even
represent a flat database table this way?
* PropertyDescriptor.
Nullable or Nillable? I don't care, but let's use just one.
A google search returns 220.000 nillable, 633.000 nullable.
Nillable seems to come from xml schema, nullable is
used in c# apparently.
* AssociationDescriptor.
"attribtues"
* OperationType
"exciting" should not have a place in javadocs... I guess
this one still needs to be rewritten?
* Association
Why not replace getRelated/setRelated with
getValue(): Attribute, setValue(Attribute)?
Would be more consistent with the rest of the API.
* Attribute
Since ComplexAttribute isA Attribute, saying that we use
it to model simple data types is incorrect. You should say
that simple data types should be held inside an Attribute
instance, and that for complex attribute there are
specific subclasses (note the change of direction in the
implication, simple value -> attribute, but attribute
does not imply simple value).
* Feature
getID() is basically unchaged from Attribute, maybe we
should remove it. But we should state that a Feature
is always identified somewhere, right?
About this thread
--------------------------------------------------------------
Wasn't FeatureCollection supposed to be removed from factories?
SimpleFeatureFactory.createSimpleFeatureCollection(...)
is still there.
One question about order. XML gives us an ordered representation
of the properties. Does this mean that our implementation will
use List internally to preserve that order when parsing data?
About the Feature.getDefaultGeometry(), I prefer this alternative
compared to getDefaultGeometryProperty() but... there is a big but!
In 2.4.x we deprecated getDefaultGeometry() and replaced with
getPrimaryGeometry(). Now we go back?
Do whatever you please, but please, don't ask library users to
change that method name two times!! (same goes for SimpleFeatureType).
About Query, if we keep String to use xpath, how do we discriminate
between attributes in different namespaces? I haven't checked
xpath to see if there is a way to do so (most probably there is?).
About the destiny of FeatureCollection, I agree with ISO,
let it be a data access tool, and forget about them being features.
About Jody featureland and wiki code examples
--------------------------------------------------------------
* Success table:
provide operations so we can smoothly integrate with Coverage? Hmm...
you mean, thinking about coverage as an n-dimensional function?
* builder examples in the wiki.
FeatureType does not have a CRS
(it's a derived attribute, as stated by the javadoc), but the
geometry attribute should instead.
I fail to see the need to explicitly cast in 2.6. Can't we just
deprecate geotools features and eventually remove them from the
API instead?
Ok, that's all folks :)
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
