Hi Micheal:
I was going ask for a review; so I could update the tasks for taking this stuff
to supported. It appears as if this email thread is my review.
Andrea: I am going to push back some functionality from uDig (the rescope
"operation" will make an amazing process for geotools). I am trying to pull in
interest from geomajas and 52N in taking part; but I admit it is very hard to
motivate others to invest in the library. Perhaps with processes being so easy
to write we can get through to the developer communities and skip a level of
indirection.
--
Jody Garnett
On Thursday, 22 September 2011 at 6:20 PM, Michael Bedward wrote:
> 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 (http://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]
> (mailto:[email protected])> wrote:
> > On Thu, Sep 22, 2011 at 7:04 AM, Michael Bedward
> > <[email protected] (mailto:[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 (http://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 (http://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]
> (mailto:[email protected])
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
