Jody wrote: "Hey we fell off the development list again - that is not cool."
My bad. I keep forgetting to hit the "reply to all" button.
Jody wrote: "Call it a FeatureCollection then. I seem to recall Jump having a
FeatureType - indeed I reviewed it as a candidate for GeoTools."
JUMP has FeatureSchemas, which are something like a FeatureType. The
problem is they aren't easily identified. We are still having some
pretty acitve discussion on this issue on the JPP Developer mailing
list. I won't bore you with it.
I don't think it really matters in this case anyways. I just need to
pass the ValidationProcessor a FeatureType. I will create this
GeoTools FeatureType object during the JUMP Feature -> GeoTools
Feature conversion process. (I think I can use the FeatureSchema of
the FeatureCollection as the basis for the GeoTools FeatureType
object.)
Jody wrote: "Do you have a good (modern?) page describing the OpenJump
feature model?"
That's a negative. I think you GeoTools folk are a lot better about
documentation than we are at the JPP. It is pretty simple though. A
Layer wraps a FeatureCollection, which contains Features and has a
FeatureSchema. That's pretty much all there is to it.
Jody wrote: "You can then populate the featureCollection given a bunch
of raw JTS
geometry from JUMP"
I don't think I need to get to this low of a level. Let me just iron
out the JUMP Feature -> GeoTools Feature conversion and then we can
take advantage of a lot more GeoTools work in OpenJUMP. (Coding a
converter will be a pain in the rear end, but worth it. I might as
well get it done now.) If we go this route I can just pass the
ValidationProcessor a GeoTools FeatureType and GeoTools
FeatureCollection. This means GeoTools and UDig will be able to use
all of the validation test I write as well.
Jody wrote: "Understood; that xml file thing is optional right? It is
just turned
into a data structure - which you can create
in code. This is how the uDig and GeoServer applications do things. They
save file out for persistence, but
at some point there is a ui."
I understand that the XML file is only needed for persistence. I think
it is great to have persistent validation tests. This means that, in
theory, you could send both a Layer and a set of quality assurance
tests between supporting programs. For example, you can send me the
Shapefile you created in UDig and I will be able to read it into
OpenJUMP and validate the data with the tests you send me in XML. (I
think it could work this way in theory at least.)
We'll have to talk some more. I'm going to focus on the Feature
converter for the next couple of weeks.
The Sunburned Surveyor
On 6/19/07, Jody Garnett <[EMAIL PROTECTED]> wrote:
> Hey we fell off the development list again - that is not cool.
>
> Sunburned Surveyor wrote:
> > This might be a little bit of a problem. OpenJUMP doesn't specify
> > FeatureTypes.
> Call it a FeatureCollection then. I seem to recall Jump having a
> FeatureType - indeed I reviewed it as a candidate for GeoTools.
> > I'll have to figure out how to work this into the conversion between
> > FeatureModels.
> Do you have a good (modern?) page describing the OpenJump feature model?
> > I think I can just use the Layer name in OpenJUMP as the FeatureType. I
> > need to talk to the other OpenJUMP developers about this. Nothing
> > prevents Layers with the same
> > name at the current time, so this could cause me some trouble. Let me
> > check on this issue
> > and I will get back to you.
> No worries; the xml file just needs to known "which layer" to test. It
> is not so important for the
> feature by feature tests. But when you are trying to enforce constraints
> between a couple of
> layers it becomes more critical.
>
> Other options (other than name) to use the filename, or URI the file,
> URI of the web service etc.. We tried using URL with mixed success.
> > I don't know if all of this is really necessary in my case. I was
> > thinking the user would specify the two layers, and hence Feature
> > collections, to be used when creating the validation.
> Understood. Let me present a rough outline of how we could do this right
> now .... just wrapping up the content "wrap this up" for the validation
> module (as it stands now). Going into hack mode here ...warning danger.
>
> And the type of the Feature Collection would be:
> - FeatureType A = DataUtilities.createType( "a", "geom:Geometry" )
> - FeatureType B DataUtilities.createType( "b", "geom:Geometry" )
>
> You can create a couple of FeatureCollections:
> - FeatureCollection featuresA = FeatureCollections.newCollection();
> - FeatureCollection featuresB = FeatureCollections.newCollection();
>
> You can then populate the featureCollection given a bunch of raw JTS
> geometry from JUMP:
> int id=0;
> for( Geometry geom : geometryList ){
> Feature aFeature = A.createFeature( "a"+(id++), new Object[]{
> geom } );
> featuersA.add( aFeature );
> }
>
> Wrap them up in FeatureSources (so we can query against them):
> - FeatureSource sourceA = DataUtilities.source( featuresA );
> - FeatureSource sourceB = DataUtilities.source( featuresB );
>
> And then put them in a map (the key is called a "typeRef" in the
> documentation):
> Map map = new HashMap();
> map.put( "internal:::a", sourceA );
> map.put( "internal:::b", sourceB );
>
> ValidationResults results = new DefaultFeatureResults();
> validationProcessor.runIntegrityTests( null, map, null, results );
>
> if( results.error.isEmpty() ){
> System.out.println( "good!" );
> else {
> System.out.println( "bad!" );
> }
>
> So I was mistaken - I thought a "Registry" was needed here but
> apparently it has been reduced to a Map.
>
> If you look at ValidationProcessTest you can see another way to do
> things quickly using a MemoryDataStore - in case DataUtilities.source(
> featureCollection ) is too crazy.
> > I had even started working on ideas for the user diaolog in Netbeans
> > Matisse. I
> > had envisioned a GUI that allowed the user to select 2 separate Layers
> > from a drop down lists, and then select and the type of validation
> > and configure it.
> Understood; that xml file thing is optional right? It is just turned
> into a data structure - which you can create
> in code. This is how the uDig and GeoServer applications do things. They
> save file out for persistence, but
> at some point there is a ui.
> > In our example the user would select the "Hazardous Waste Sites" layer
> > in the first list, "Elemetery Schools" in the second list, and would
> > select "Point must not be within distance of point." as the validation
> > test. The test would be constructed with the layers selected by the
> > user.
> Cool - the above code outline should give your the glue code to run the
> thing.
> > In this case I don't think we need to use Repository or FeatureSource.
> > We could use a spatial query to narrow the number of geometries to be
> > searched. Is that what you are talking about?
> FeatureSource is how we make the spatial query available to the
> ValidationProcessor. In the code outline you can see a Map of
> FeatureSource being constructed; some of the validation tests will
> construct and make spatial queries on their own etc...
>
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
