Hi all,
Time for round2 with geoapi. Based on andreas initial feedback and the
thread that resulted I have taken a crack at simplifying the model. Here
is a summary of what I have done.
* JavaDocs
JavaDocs are now to the point, and no longer a brain dump from Jody :).
They should be much more approachable from the normal java programmer
point of view, and less in terms of Rob A (sorry Rob ;) ). Many of them
are complete with code examples, and anologies to the xml world (which
helped andrea see the point of Attribute, and AttributeDescriptor).
* Attribute methods pushed up to Property
All the "meat" is now on the Property interface. This makes it more much
more possible to write code against Property directly, and not have to
worry about if its actually an Attribute or an Association.
For this reason, there is not longer a real need for the "view" methods.
When I say "view method" what i mean is:
Collection<Attribute> attributes();
Collection<Association> associations();
* Added useful methods to ComplexFeature
Before, the only access to the properties of a ComplexFeautre were through:
Collection getProperties();
Collection getProperties( Name );
Collection getProperties( String );
This is a pain, because more often then not you know that you have only
a single property. And always having to deal with a collection is
pointless. So the following methods have been added:
Property getProperty( Name );
Proprety getProperty( String );
The javadocs on these methods clearly state that the first property
matching the name is returned... and if you are unsure what the
multiplicity is you should use getProperties(*).
* CRS only available on GeometryType
Before a CRS was available from the following:
Feature.getCRS();
FeatureType.getCRS();
GEometryAttribute.getCRS();
GEometryType.getCRS();
That has been changed so that it is only available on GeometryType and
FeatureType. The javadoc for FeatureType.getCRS() clearly states that
the crs is derived from the default GeometryType. I found this useful to
get out of writing code like this (like i have so many times):
CRS crs = ...
if ( featureType.getDefaultGeomtry() != null ) {
crs = featureType.getDefaultGeometry().getCRS();
}
* Killed FeatureCollection
OK I did not kill it... but I killed it from the factories. Basically
FeatureCollection in geoapi should be ignored.
* Java Bean Conventions
All methods follow java bean naming conventions
* UserData
Instead of rolling our own interface which looks like a half baked
map... I just added the following methods:
Map Property.getUserData();
Map PropertyDescriptor.getUserData();
Map PropertyType.getUserData();
* SimpleFeature
I changed the following methods:
Object getValue(Name)
Object getValue(String)
Object getValue(int)
to:
Object getAttribute(Name)
Object getAttribute(String)
Object getAttribute(int)
(and the corresponding setter methods).
Also changed:
Object getDefaultGeometryValue()
to:
Object getDefaultGeometry();
Now things get a bit interesting here. Note that these methods return
the attribute value, and not the attribute itself. This might be a bit
confusing in terms of naming conventions, but it has a few key advantages:
1. The SimpleFeature interface now looks pretty much exactly like the
geotools Feature interface
2. It is useful in terms of IDE auto completion in that all the methods
that are most useful show up first in the list.
Talking with Jody on this one we are a bit torn. It would be great to
have more feedback on this one.
And that is it. Let me know what you all think. Let the second round of
review begin.
-Justin
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
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
