Re: [Geoapi-devel] [Geotools-devel] Plan For The GeoTools Feature Model

[Jody G. <jga...@re...>]

Thanks for your email; I am CCing the GeoAPI list as a lot of your 
questions are actually answered by GeoAPI release and review policy

Sunburned Surveyor wrote:
> I appreciate the responses provided by Jody and Rob to my earlier post 
> about the relationship between GeoTools and GeoAPI. I want to respond 
> to some of their comments in another thread.
>
> Before I do that I'd like to put forth a suggested plan for the 
> GeoTools Feature Model. I have a personal goal of integrating the 
> GeoTools Feature Model into an experimental branch of OpenJUMP's code 
> base over the course of the next year or two. I think great benefits 
> would come if UDig would be able to share a Feature Model with 
> OpenJUMP, a Feature Model drawn from the GeoTools library. An 
> immediate benefit of this would be UDig's ability to tap into my 
> FeatureCache, and the FeatureCache classes that will write features 
> and feature geometries to a binary format. (I know you guys use 
> indexed ESRI Shapefiles for this purpose currently, but the 
> FeatureCache would allow us to support things that are not currently 
> included in the Shapefile spec.)
>
> Before I can make the investment in time we are talking about here I 
> would like to see if we can get the GeoTools team to come to a 
> consensus on where the GeoTools Feature Model will be in 6 months, 12 
> months, even 24 months. Jody's comments seem to indicate that we'd 
> like to update the GeoTools FeatureModel to match the interfaces in 
> GeoAPI. I'm willing to work on the following, under the supervision of 
> a GeoTools developer, if a plan for the Feature Model can be agreed upon:
>
> [1] Creation of a GeoTools SimpleFeature class 
> (org.opengis.feature.simple.SimpleFeature) that implements the GeoAPI 
> Feature interface.
That exists:
> [2] Refactoring and modification of the Shapefile I/O code in GeoTools 
> to read/write the new SimpleFeature class.
This happens in two parts:

With the goal of having Shapefile I/O code in GeoTools read/write the 
new SimpleFeature interface (not class)
1. Release GeoTools 2.4
2. Make org.geotools.feature.Feature extend 
org.opengis.feature.simple.SimpleFeature

Basically we want to follow a deprecate cycle for one release so people 
can still have their import org.geotools.feature.Feature statements and 
have their code compile.

With the goal of letting you use your own implementation of Feature and 
FeatureType.
1. Isolation of all FeatureType and Feature creation in the shapefile 
module and transition to FeatureBuilder and FeatureTypeBuilder
2. Release of GeoTools 2.4
3. FeatureBuilder changed to delegate to a SimpleFeatureFactory instance 
that creates org.geotools.feature.DefaultFeature
4. FeatureTypeBuilder changed to delegate to SimpleFeatureTypeFactory 
that creates org.geotools.feature.DefaultFeatureType

The "story" can happen a little bit later but it is the point of using 
interfaces and factories. In the case of Features (and Geometry) there 
is a large benefit to matching implementation to need.

History: The reason why SimpleFeature is worthwhile is twofold; a 
DataStore that accepts a SimpleFeatureFactory is telling the user 
something important about the data format. The fact that attribute order 
is consistent and fixed lets us do a couple of things really well:
a) it lets us provide helper methods such as getAttribute( int ) and 
getAttribute( String ) without fear of conflict
b) it lets us support an internal format that is much smaller then a 
java.util.Map

Without these as known assumptions the "feature model" is the "raw" 
concept championed by the ISO standards police. Very general, and very 
useful for the kind of interoperability work these standards are 
designed to enable. But frankly it is hard to approach.

Andrea said it best (sorry I do not have an exact quote aaime) when he 
made the connection that a shapefile header was every bit as (and 
probably more) authoritative as some XML schema dreamed up by a government.

The good news is both ideas complement each other - although we will 
need to communicate with each other even when faced with needs different 
from our own.
> [3] Updated API documentation for the Shapefile I/O code with a basic 
> tutorial that explains how to use the GeoTools classes to obtain 
> GeoAPI compatible Feature objects from a Shapefile.
We will update the documentation - your communities feedback would be 
greatly appreciated.

If you look at the two parts above you will see that we do not plan any 
data access api changes - the returned Features will simply implement 
the org.opengis.feature.simple.SimpleFeature interface.
> I'd think we really need to see some sort of document or policy that 
> indicates under what circumstances the GeoTools Feature Model 
> interfaces would change. (I'm not talking about the implementations, 
> I'm talking about the interfaces. If we can keep the interfaces stable 
> users of GeoTools can avoid the direct use of GeoTools implementations 
> whenever possible, and we won't be breaking third-party applications 
> all the time.) 
The only way GeoAPI currently changes is when a new specification is 
brought out; or in rare cases when a mistake was made and not caught by 
the review process. GeoAPI is in a tough spot since it only ships 
interfaces (so adding an method and deprecating a mistake will break 
implementations - but not client code).

It would be preferable to issue new interfaces for each major revision 
of a specification (GML2, GML3) and make any corrections in place as a 
specification is corrected (GML3 .. GML3.1). This has not been a big 
deal so far since most specification mistakes were so obvious we did not 
do them in GeoAPI, or they consisted of clarification of purpose - which 
results in a change of javadocs.

The best protection is to follow a specification that we trust as both 
good and stable - hense ISO Feature model rather then OGC GML3.
> I'd really like to see a policy under which the Feature Model 
> interfaces don't change unless necessary for compatiblity with an OGC 
> approved update to the GeoAPI Feature Model. Remember, you can create 
> all the custom behavior you'd like with implementations of the Feature 
> Model interfaces, we just need to solidify the Feature Model interfaces.
Understood. Intrefaces only change if a mistake has been made (either 
the working group will catch us out and correct us before an official 
geoapi release is made, or a mistake will is found in a specification we 
are implementing).
> I have already started work on my FeatureCache interface. I will 
> continue to work on it, but I will save the Shapefile I/O code for 
> last. Hopefully we can get some type of plan and/or policy for the 
> GeoTools Feature Model in place soon. That will allow me to get to 
> work on the improvements for the GeoTools Feature Model, and will give 
> me the chance to incorporate it into the FeatureCahce.
Please talk to Chris Holmes and Gabriel both of which have some Feature 
Model related work on the books.
> I realize that I approach this from the position of an outsider, so I 
> ask for your forgiveness if my statements betray a lack of 
> understanding about the GeoTools code base or process. Perhaps you can 
> find the value in my post when you consider that I probably share the 
> perspective of other teams that would be interested in using and 
> contributing to GeoTools if some changes that encourage stability 
> could be put into place.
Landon you actually approach this as an insider - to Java GIS 
development. I am sure everyone involved joins me in welcoming you to 
the GeoTools development environment - and we look forward to both this 
current collaboration and the trouble we can cause with you in the future.

Cheers,
Jody