[seek-dev] Re: implementing garp in ptolemy
Ricardo Scachetti Pereira
ricardo at cria.org.br
Mon Nov 10 13:22:16 PST 2003
Chad, Deana and all,
GARP is currently implemented as a C++ API
(Application Programming Interface) that can be put
together easily to implement any of those
analytical steps that are present on the GARP
pipelines we produced.
The GARP API is very modular and the main modules
match almost precisely the various analytical steps
described in each GARP pipeline.
Still, we didn't specify exactly what each GARP
analytical step should do. I think that this was
one point that Chad was complaining about in his
previous messages, wasn't it (not enough detail in
the pipeline specs)?
Once each analytical step is spec'ed out, one
need to code it using GARP API calls in C++ (each
would be at most 4 lines long!!). Then a Java class
would wrap that C++ class. Or alternatively, the
analytical step could be implemented in a Java
class directly which, in turn would call the right
methods in the GARP API.
That is how I see it. But I know nearly nothing
about wrapping C++ code in a Java class.
Again, I am pretty sure that the underlying code
won't add any additional constraints.
All that said, I suggest we implement each GARP
analytical step separately.
The only tricky part (from my perspective) will
be to feed GARP with data in the right formats. For
example, the environmental layers should all match
each other exactly (same extent and cell size)
which usually requires a resample operation prior
to modeling. Also, each cell value on those layers
have to be normalized to fit a bit (1 to 254)
before it can be processed by the algorithm. The
GARP API has methods that do that normalization
reading the (resampled data) from layers in ESRI
ASCII Raster Grid format.
We can talk about those details on a conference
call later this week, can't we?
Regards,
Ricardo
> Chad,
>
> These questions were discussed meticulously in
the breakout group at
> Santa Barbara (see...you should have picked the
other group :-)
>
> The conclusion was that there are pieces within
GARP that it would be
> nice to reuse, specifically, the sampling piece
that splits the input
> samples into two groups (testing and training),
which is currently shown
> on the pipeline as a separate piece.. However,
Dave thinks it might be
> alot of work to change the code to make that work
(but suggested Ricardo
> might think differently). If the GARP code can
be relatively easily
> rewritten to break out the steps that are in the
pipeline, then we
> should do that, otherwise we should lump it all
together as one step
> (which would make a much simpler pipeline).
>
> Shawn has a revised species distribution pipeline
that you should make
> sure you have.
>
> Deana
>
>
> Ricardo Scachetti Pereira wrote:
>
> >Hi, Chad and all,
> >
> >I can provide all the details about GARP that
you
> >need.
> >I'm in a middle of a household move, but a phone
> >call on Wednesday afternoon or Thursday would be
> >good for me.
> >I'll be in Brazil which is now 6 hours ahead of
> >California Time.
> >Let me know whether that works for you.
> >
> >Regards,
> >
> >Ricardo
> >
> >
> >
> >>Hi All,
> >>
> >>I've been looking at trying to get GARP working
> >>
> >>
> >in ptolemy a bit, and I
> >
> >
> >>have a few questions. First of all, is the
> >>
> >>
> >modularity that is described
> >
> >
> >>in the PPT files the modularity that you would
> >>
> >>
> >want in a ptolemy model?
> >
> >
> >> for example, is the "data calculation" step
in
> >>
> >>
> >the "GARP Native
> >
> >
> >>Species Pipeline" something that you would want
> >>
> >>
> >to reuse in other
> >
> >
> >>pipelines? When I talked to Dave when we were
> >>
> >>
> >here in SB, I got the
> >
> >
> >>impression that he thought GARP should just be
> >>
> >>
> >one atomic actor (is that
> >
> >
> >>really what you think Dave?) If these
components
> >>
> >>
> >are never going to be
> >
> >
> >>reused for any other pipeline, then they should
> >>
> >>
> >probably just be folded
> >
> >
> >>into one generic GARP actor.
> >>
> >>I'd like get together, either physically or
> >>
> >>
> >virtually, with someone that
> >
> >
> >>can explain to me the exact steps that it takes
> >>
> >>
> >to go from the training
> >
> >
> >>data and layers to output. The specifications
of
> >>
> >>
> >the modules within the
> >
> >
> >>PPT documents are a bit vague. For instance, I
> >>
> >>
> >have no idea what data
> >
> >
> >>calculation does. A mid-level pseudo-code
> >>
> >>
> >implementation of GARP might
> >
> >
> >>be a good idea, as it would help me get my head
> >>
> >>
> >around this thing a bit
> >
> >
> >>more.
> >>
> >>Could any of you have a phone call next week?
> >>
> >>
> >maybe wednesday since
> >
> >
> >>tuesday is a holiday?
> >>
> >>chad
> >>--
> >>-----------------------
> >>Chad Berkley
> >>National Center for
> >>Ecological Analysis
> >>and Synthesis (NCEAS)
> >>berkley at nceas.ucsb.edu
> >>-----------------------
> >>
> >>
> >>
> >>
> >
> >
> >
>
> --
> ********
>
> Deana D. Pennington, PhD
> Long-term Ecological Research Network Office
>
> UNM Biology Department
> MSC03 2020
> 1 University of New Mexico
> Albuquerque, NM 87131-0001
>
> 505-272-7288 (office)
> 505 272-7080 (fax)
>
>
> _______________________________________________
> seek-dev mailing list
> seek-dev at ecoinformatics.org
>
http://www.ecoinformatics.org/mailman/listinfo/seek-
dev
>
>
--
Ricardo Scachetti Pereira
Gerente de Pesquisa
Engenheiro de Computação
Centro de Referência em Informação Ambiental / CRIA
More information about the Seek-dev
mailing list