I've got some good news. I think I can make use of the validation framework in some of my geomerty and spatial relationship validation work.
I've also got some bad news. I'm running into the FeatureModel problem again. :] I think there are two approaches I could take: [1] I can convert all of my JUMP Features to GeoTools Features and then work with the existing interfaces and classes in the GeoTools validation code. [2] We can do some tweaking of the GeoTools validation code to add support for validation of just JTS geometries and the spatial relationships, and avoid Feature objects all together. (For example, I would need to introduce a GeometryValidation interface and SpatialRelationshipValidation interface as sub-interfaces of Validation. I would also need to add a runGeometryTests method and a runSpatialRelationships test to the ValidationProcessor class.) I suppose it doesn't really matter which approach I use. Both will be a little bit of work. (I've either got to do the conversion between Feature models or do the refactoring on the GeoTools side.) Do you guys favor one approach over the other? If I use the first approach OpenJUMP can take advantage of the Feature Validation code that is in GeoTools, which would be great. If I take the second approach other projects that don't use the GeoTools Feature Model would be able to take advantage of the geometry and spatial relationship validation code. I also see that the ValidationProcessor accesses the Features to validate through a FeatureReader. The Javadoc for the runFeatureTests method says that the method "uses a FeatureReader now instead of a FeatureCollection." I can see the point of this if you wanted to, for instance, validate features on import from a file or a database. But in my use case I intend on validating Features that are already contained in a Layer in OpenJUMP. Is there an alternative way to pass a collection of Features to the ValidationProcessor for validation? Can you create a FeatureReader from a FeatureCollection? It seems like the ValidationProcessor would be more useful if it contained a method that accepted a raw collection of Features instead of a higher-level object like FeatureReader. These are just some thoughts. I don't know how all of this code interacts, and I don't want to offend the designer/programmer. I thought it might be helpful to share the perspective of someone who would like to use and/or extend this code from a third-party program like OpenJUMP. At any rate, I think this is a good opportunity for collaboration. It is also an opportunity that I am interested in because of my current work for the OSGeo Journal. Should I get in touch with this module maintainer for answers to my questions? Thanks. The Sunburned Surveyor P.S. - Why do we use the term "validation" in some places and "tests" in others? For example, we use the method name runFeatureTests instead of something like runFeatureValidations or validateFeatures. ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
