Just checked - on trunk it uses FeatureCollection. public void runFeatureTests(String dsID, FeatureCollection collection, ValidationResults results);
ValidationResults operates as a visitor in a manner similar to TestResults in JUnit. have fun, Jody > 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 > ------------------------------------------------------------------------- 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
