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