Somehow we need to"register" the implementations with GeoTools (or otherwise teach geotools that the implementations exist).
We used to have one factory for each process; that got to be a pain - so I think you can have one factory that tells GeoTools about many many processes. Jody On Tue, Mar 16, 2010 at 4:33 PM, andrea antonello <andrea.antone...@gmail.com> wrote: > hah, I simply went one step deeper and found that AbstractProcess does > nothing if not just implementing the Process interface. > > So I have just one more question: if I implement the process > interface, is that enough to make the models usable within geotools? > > Andrea > > > On Tue, Mar 16, 2010 at 6:31 AM, andrea antonello > <andrea.antone...@gmail.com> wrote: >> [...] >>>> Following the new process implementation link [1], I have some >>>> comment, to which it would be great to have some back-comment. >>>> - the fact that I have to extend a class instead of implementing an >>>> interface is a bit strange to me >>> >>> You can change it over to an interface if you like. >> >> Yeah, that would be a good starting point. >> >>>> - the fact that i am forced to create a factory class and even pass it to >>>> my module constructor, also >>> >>> I think that was trying to not duplicate the description of input >>> parameters? Can you see any other reason for the factory to be needed? >>> I would prefer some kind of process info; that is avaialble from both >>> the factory and the process itself. >> >> The factory is ok for me, it usually helps a lot, but I don't see the >> point of forcing people to have one. >> >>>> the process api? With Sextante it went the way round, right? I guess >>>> they didn't adapt to the process api. >>> >>> What does Sextante do to describe input parameters and produced results? >> >> No idea about what and how sextante does. >> >>>> Any comments are welcome, in the meanwhile I will look out to find if >>>> the factory and process can be generated somehow from annotations. >>> >>> If we could annotate the parameters and results that would be perfect. >> >> That has also to be taken with care. >> >> I have quite some experience in migrating scientific models to >> frameworks and interfaces by now. What I know for sure it that to be >> maintainable, you have to take all the burden from the model writer, >> i.e. possibly he should be able to do no work at all. >> >> The OMS approach is to simply keep the model design but annotate the >> input and output parameters and also the method to be executed. That >> makes a model ok for linking for OMS, but doesn't change one thing in >> the nodel itself (ideally speaking). >> >> In my opinion the process api would be ok, if, to make my model >> geotools processing compatible, I just had to implement the an >> interface that asks me to implement the execute method: >> public Map<String, Object> execute( Map<String, Object> input, >> ProgressListener monitor ) >> >> It would then be easy for me to create a few lines of code that inside >> the method execute my model. >> >> The problem is that I will have no time at all to work on the geotools >> side of this, mainly because I would have to study the process api. >> But if it would be possible to change the AbstractProcess to an >> interface I would be willing to implement that for all the JGrass >> models that I am extracting to be a standalone library in order to be >> used by the geotools community. >> Not sure if you guys see it usefull, in the case a factory is not present. >> >> Micheal (refering to your last email), could you help me on the >> geotools side of life? >> >> Thanks for the discussion, I really want to implement the modules to >> be usefull under wps and whatever. >> >> Cheers, >> Andrea >> >> >>> >>> Jody >>> >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
