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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
