> 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.
>
cool. There are lots of formal docs if you want them - talking about
what the files are and what operations were needed to be complete for
the first cut, comparison with GeoDatabase constraints and so on....
> I've also got some bad news. I'm running into the FeatureModel problem again.
> :]
>
Heh - if only we had that DataAccess API accepted :-) The contract is ....
interface DataAccess {
Collection getContent();
Collection getContent( Filter );
Collection getContent( Query );
}
Then we could make the validation module use this; and you would be able
to avoid the feature model :-(
> 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.
>
I tried this; there are some method name conflicts; but we could do a
wrapper.
> [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 kind of like that .... the GeometryValidation stuff could still be run
on a GeoTools feature; the framework
would just need to understand that it needs to do
Feature.getDefaultGeometry() .... good idea.
> 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?
>
Well I just listed a third option. The real trick is to do a query into
your collection of features (to figure out which ones
intersect and so on...).
> 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."
>
We can switch them over to a FeatureCollection as needed. Now that a few
of the JDBCDataStores have
really good FeatureCollection implementations it is starting to be
worthwhile.
> 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?
>
See above comment - we can make it take a FeatureCollection (I thought I
had done this already for trunk ... let me check).
DataUtiltiies.reader( collection ) will do the wrap job if you need it.
At the time the validation module was created we only
had FeatureReader :-D
> 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.
>
That is true - for things that only test one Feature at a time.
We can cover the case where features are tested against each other
another time.
> 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.
>
No worries; the goal is to get the code used first and foremost. In
general don't worry about
giving offense; we all just want to cut to the chase ... code examples
are good on this list.
> 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.
>
Sweet.
> Should I get in touch with this module maintainer for answers to my questions?
>
Brent Owens and myself are listed as module maintainers. Given this
module operates with two really strong interfaces:
- the xml files
- the Validation interface
There is no harm in reworking the internals.
Cheers,
Jody
> 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
