Hi Andrea, I'm not looking to modify the new classes or their names. I just want to cull old classes that have been superseded by the new code. So for vectorizing, I'd get rid of the old process and factory classes and adapt the unit tests for the newer, neater PolygonExtractionProcess.
Regarding the process.raster.gs package, I wondered whether this was just a temp porting thing or whether it was a GeoServer requirement. If the former then perhaps we can just have them in process.raster since the existing VectorToRasterXXX classes all that's there and they are destined to be replaced. My more general questions were me trying to understand where you and Jody are heading with the raster processes and how they do, or perhaps don't, relate to coverage operations. I don't have any plan or ideas about it myself - just want to understand it for my own use and to be able to explain it to others on the user list and in the docs. Michael On 22 September 2011 16:39, Andrea Aime <[email protected]> wrote: > On Thu, Sep 22, 2011 at 7:04 AM, Michael Bedward > <[email protected]> wrote: >> Hi Jody, Andrea, >> >> I'm looking at the raster processes in relation to a couple this issue: >> >> http://jira.codehaus.org/browse/GEOT-3855 >> >> which then inspired this one: >> >> http://jira.codehaus.org/browse/GEOT-3857 >> >> I'd like to check if either of you have any problems with GEOT-3857 >> going ahead ? >> >> More generally, I wonder if there is any need to have a separate >> process.raster.gs package ? > > These were the processes donated back by GeoServer. > We can change the package but I need the processes to maintain > their name, e.g., gs:PolygonExtraction, when they are published > by GeoServer WPS > > I'd also want other WPS merrily picking up our processes to show > in their users face that the processes come from GeoServer, since > apparently we are the only ones fool enough to donate back our > work in a place where everybody else can use it. > I will eventually have to forget about this, but when I see other > WPS using the processes I've developed for GeoServer, knowing > that they never contributed back squat, I really feel robbed. > >> Another question, the process.raster.gs classes don't have a static >> process method. Is this a design decision ? I haven't caught up with >> the new API yet but perhaps it removes the need for static helper >> methods for direct use - is that the case ? > > For direct use you don't indeed need to go through the process API > at all, just instantiate the process and call the execute method. > But I don't know why Jody made a factory class for vector processes, > but not for raster ones, I was actually wondering myself too. > > Cheers > Andrea > > -- > ------------------------------------------------------- > Ing. Andrea Aime > GeoSolutions S.A.S. > Tech lead > > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584 962313 > fax: +39 0584 962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.youtube.com/user/GeoSolutionsIT > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ------------------------------------------------------- > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
