Leandro,

I believe we missed the deadline for submitting student applications,
which was April 7th.

This means we must either [1] start work on your project without
participation in the Google Summer of Code, or [2] wait until next
summer to participate.

I'm sorry that we were unable to get things put together in time to
participate this summer.

Please let me know if you have questions, and how you would like to
move forward.

Landon

On Tue, Apr 8, 2008 at 5:00 AM, Leandro Leal Parente
<[EMAIL PROTECTED]> wrote:
> Hi Laerte, Nilson and Manuel,
>
> At one week ago I contact Landon and Nacho by a list of discussion about
> Google Summer of Code and a list of discussion for OpenJUMP development
> team. Yesterday they accept my invite and starting now they are my mentors
> in Google Summer of Code.
>
> Landon is my official mentor. He is a official mentor for OSGeo and
> responsible for OpenJUMP ideas at Google Summer Of Code.
>
> Nacho is my unofficial mentor. He know much about SEXTANTE (Graphic Modeling
> extension for GvSIG) and he will present Victor Olaya (the main developer of
> SEXTANTE).
>
> They are help us in that project
>
> Landon and Nacho,
>
> Nilson, Manuel and Laerte are the responsible professors by LAPIG (Image
> Processing and GIS Lab). They help to created and translated that propose
> for Google Summer of Code. They are great minds by following this project.
>
> That is our team for Google Summer of Code 2008.
>
> Thanks to all,
> Leandro Leal
>
> 2008/4/8, Nacho Uve <[EMAIL PROTECTED]>:
> > Excellent and very ambitious propose... I think It would be a really
> useful tool for OpenJUMP.
> >
> > As unofficial mentor, I start my duties... :)
> >
> > 1.- I not sure, but I always see "OpenJUMP" (all together and JUMP with
> upcase characters) instead of "Open Jump". Just a little correction.
> >
> > 2.- Follow the SEXTANTE way, you must create a "gis algorithm developement
> platform" where everybody can implement new algorithms easily, and without
> problems about how get input parameters (values, etc.) or layers (vector,
> raster). Something like class
> com.vividsolutions.jump.workbench.ui.multidialog... but sextante solution is
> much better in my opinion. I saw people with no idea of programming adding
> new functionalities on sextante... something like that would be the first
> piece. So, all new processes/routines added for anyone could be used on the
> models.
> >
> > 3.- OpenJUMP is mainly a vector gis... So, maybe you must focus on
> routines to process vector data. It will be nice can chain processes as
> buffers, intersections, convex hull, etc... In my opinion, it should be the
> start point: vector routines.
> >
> > 4.- Take a look to SEXTENTE project... Reuse as much code as possible...
> Daily there are new commits on the code [1]. Also there are developement
> docuementation [2] (in spanish), but i think you can understand it...
> >
> > well... no more for today... :-)
> > Just say that it is a pleasure to be involved...
> >
> > Nacho.
> >
> > PS: Excuse me, becouse my english is awful... but I hope we can understand
> us...
> > PPS: Please, Landon feel free to correct me if I'm wrong or if you
> disagree in anything. ;)
> >
> >
> >
> > [1] SEXTANTE SOURCE CODE
> >
> > Latest source code can be downloaded from our SVN repository. More
> information at http://sextantegis.googlecode.com/[2]
> http://www.unex.es/eweb/sextantegis/ManualStdExtension.pdf
> >
> >
> >
> >
> >
> >
> >
> > 2008/4/8, Leandro Leal Parente <[EMAIL PROTECTED]>:
> >
> >
> >
> >
> > > Thats a propose I submit at Google Summer of Code
> > >
> > > Abstract:
> > >
> > > The overall goal of this proposal is the implementation of a graphical
> modeling tool for processing geographic data with the Open Jump, which
> doesn't offer such capability. This tool will be coded in Java, the Open
> Jump programming language, with the purpose of creating an intuitive
> graphical interface which will enable the development and use of routines
> for automated data processing. Such development / coding approach will allow
> any user to add new algorithms for a given data processing need.
> > >
> > > Detailed Description:
> > >
> > > 1) Introduction :
> > >
> > >       The proposed tool will enable the creation of graphical models for
> processing geographic data. With a robust graphical modeling and a wide list
> of routines, it will be possible for anyone using Open Jump to create
> different models for data processing. In fact, this tool will allow the
> construction and visualization of models in a more intuitive and easier
> manner. It will be possible to develop models graphically or through
> algorithms. For both approaches, the key steps will comprise a set of input
> parameters, interconnected routines, and output parameters. Once a model is
> created, it can be saved, so that it can be modified as needed or used
> again.
> > >
> > >
> > >
> > >       2) Input parameters:
> > >
> > >        The enter parameters can be fixed or variable. In case of fixed
> parameters, the whole processing model will be developed for only a given
> dataset defined during the modeling processing. So, if a different dataset
> is to be used, the model will have to be modified according to the enter
> parameter in need to be changed.  Alternatively, the enter parameters will
> be "parameterized" according to the input data, thus enabling the
> utilization of any geographic dataset. In particular, the enter parameters
> can be chosen from:
> > >
> > >           * Geographic data in raster or vector format;
> > >           * Strings, boolean and numeric values;
> > >           * Attribute tables;
> > >           * Coordinates;
> > >
> > >
> > >       3) Approaches:
> > >
> > >       The routines that will process the enter parameters will be
> developed specifically for the tool we are proposing. Nevertheless, it is
> our expectation that shortly, the own Open JUMP routines can be used for
> developing the models. The algorithms to be implemented include, among
> others:
> > >
> > >           * Vegetation Index (NDVI, EVI and others);
> > >           * Spatial statistical models (GWR, Mess, and others);
> > >           * Data conversion;
> > >           * Manipulation of raster and vector files;
> > >           * Tools for editing attribute tables;
> > >
> > >       These routines will be implemented in the same programming
> language as the one used for the tool itself. Therefore, it will be
> possible, as needed, the implementation, in Java as well, of the functions,
> which will be selected through the import option. Once inserted, the new
> routine will be visualized in the corresponding selection menu.
> > >
> > >       4) Output parameters:
> > >
> > >       The output parameters will also be fixed or variable. Thus, the
> user will be able to decide on a name and a destination for the files that
> will be created by a specific model.
> > >
> > >       5) Model construction:
> > >
> > >       The model will be developed through graphical modeling or via
> algorithm language. Both approaches will result in an xml file format that
> will be interpreted and executed by the proposed tool.
> > >
> > >       6) Creation of a thoroughly independent model:
> > >
> > >       Once the tool is completed, we can focus on the implementation of
> an additional routine that could export the models as independent,
> self-contained programs, which will be capable of performing a given task
> without requiring a GIS platform. Such "independent" program only would
> require a simple interface for determining the input and output parameters
> and the types of processing to be performed. This model will be exported in
> the java format. As the modeling tool will operate, to a certain extent,
> independently from the Open Jump, the "independent" programs can have the
> routines specifically created for our proposed tool. So, the models can be
> built and utilized based on a Java virtual machine.
> > >
> > >       7) Concluding remarks
> > >
> > >       If the graphical modeling tool we are herein proposing can be
> developed with all the mentioned resources, it will significantly contribute
> to the Open JUMP. In addition to all the advantages regarding graphical
> modeling, it would be possible to develop and import routines implemented in
> Java, as well as to export "independent" programs that would operate fully
> independent of the Open JUMP or any other GIS software.
> > >
> > > Federal University of Goiás - UFG
> > >
> > > Image Processing and GIS Lab – LAPIG
> > >
> >
> >
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to