johann Sorel wrote: > Hello, > > I'm exploring the process implementation made in th unsupported package. > > First : > I have a build error on this: > import > com.sun.org.apache.bcel.internal.verifier.structurals.UninitializedObjectType; > using the -U in maven doesn't solve the problem. > > Second : > this process implementation doesnt fit to what has been decided in the > proposal. > cf : http://docs.codehaus.org/display/GEOTOOLS/Process+proposal > > - The actual implementation I see is assuming a process is made for spatial > operations. (and so has defined crs,metadatas and others in the parameters) > Process is not only for spatial operation. > Nope have a look; the *type* is the class expected for the parameter; I can make a buffer example to show you this done for a Double parameter if you like. As for FEATURE_TYPE, CRS, LENGTH, etc they are keys used to look up stuff the metadata map. So if the parameter was a Feature we would expect it to be an instance of the provided FeatureType. The CRS is used to hold a CoordinateReferenceSystem object (so we can figure out the number of axis, and configure the WKTReader / WKTWriter used to enter in a geometry etc...).
So for a double we should probable have a MIN and a MAX key right? I was all set to have a single metadata object; but Justin's feedback was to use a map. We are trying out the idea by making a user interface out of it now. I would not expect this API to be stable for another month (you will have input as you run into new requirements, the wps project will have input as well - just yesterday we found that it allowed a list of values etc...). > - there is a major difference in the ProcessFactory > this implementation use : > public Process create(); > and > public Map<String,Object> process(Map<String,Object> input, ProgressListener > monitor); > > And the proposal said : public Process create(Map<String, Object> parameters) > and public Map<String,Object> process(ProgressListener monitor); > Understood; we tried it one way/ and now we are trying it the other way? what do you like? Tradeoffs for process( monitor ) method is: Pros: it is a class you create, and use *once* as such the Process writer can use class fields; and generally have a good time. I am not sure what would happen if you called process a second time? Some implementations would modify their parameters in place as they produced a result for example ... Cons: that the interface for Process does not have any inputs; as such you cannot use a process object on its own in normal java code - something I find to be a pain. Tradeoffs for process( input, monitor ) method is: Pros: the inputs are right there and only last for the duration of the method call; you can reuse the class and run process many time (or many times at once from different threads) Cons: if the method is stateless then there is no reason to separate out a factory for this one; may as well just collapse the (ProcessFactory and Process) them into a single interface. Having one less class may be worthwhile. > Or perhaps there is a new wiki page somewhere that explains those changes? > We are hoping for your feedback on the code; and sample user interface we are building. I am doing something else today; but I believe gdavis will be on IRC as he hacks. Jody ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
