[Gvsig_english] gvSIG 2.0 and sextante?

Alvaro Anguix aanguix at gvsig.com
Tue Jun 4 12:46:39 CEST 2013


Hello Wolfgang,

Allow me to dedicate some lines to answer you to explain the current
situation and the planned one at the gvSIG Association in reference to
the geoprocessing manager in gvSIG.

The geoprocessing tools are a very important part of a GIS. Until the
1.x version gvSIG included two geoprocessing managers, one of them was
belonging to gvSIG and the other one was the Sextante library, together
with other geoproceses available for the user from several menus/buttons.

On one hand, in order to improve the usability that we started in gvSIG
2.0, we dealt with the option to have an unified geoprocessing manager,
where the user can find any geoprocess available in gvSIG. And our first
objective, from the point of view of the product, we had to include all
the geoprocessing tools of the gvSIG 1.x versions for the users. For
that, in gvSIG 2.0 you can find the geoprocessing tools from the "old"
gvSIG geoprocessing manager (clip, buffer, union...), the raster
geoprocesses of gvSIG, and the geoprocessing tools from the Sextante
library.

On the other hand, we had to solve the technical issues attending to a
main element for us, not only technical, and it's the issue that I think
it can explain the current situation better and where we want to go to.
The dependency of a library maintained almost in an individual mode is
always a risk, in its evolution we can see that the person who maintains
it currently is doing it voluntarily -not in its java version- and he
specified that he abandoned it. Also the maintenance of its java version
is transferred to a fork of gvSIG that has a dynamics very different to
our ones in reference to the software development, and that doesn't take
care of past requests as basic (in my opinion) as they change its name
and don't use the "gvSIG" word. Apart from the path followed by Sextante
as a project/s, some decisions were taken previously -by one or the
other part- that were making difficult the collaboration. For us some
important decision like the change of the license or the integration on
ArcGIS led us to take decisions for not spending in Sextante and that
any geoprocess that we develop on gvSIG was always licensed GPL.

At this way, the collaboration between gvSIG and Sextante has been more
complicated to carry out and the interpretations about how to develop an
open source project have taken different ways. All of them lawful and
respectable, of course. But this general outlook was analysed by us
attending mainly to the project that we want to build, more over the
product.

We return to the main factor to solve. With the objective to build a
professional software development model, it was non-viable to have a
dependency with the aforementioned conditions. Our goal is to solve this
dependency and to be independent to progress the gvSIG geoprocessing
manager attending to our needs as a project and, in conclusion, the
needs of our community. Our first step, returning to the beginning, is
that the users had the geoprocessing tools in gvSIG 2.0 from the beginning.

Best,
Alvaro

El 03/06/13 17:13, Wolfgang Qual escribió:
> Dear all,
> 
> does anybody know whether sextante will be included in gvSIG 2.0? 
> I am a bit worried since I read that sextante seems to concentrate on qgis
> now [1].
> Any comments are appreciated!
> 
> Best,
> Wolfgang
> 
> [1] http://www.sextantegis.com/java.html
> 
> 
> 
> --
> View this message in context: http://osgeo-org.1560.x6.nabble.com/gvSIG-2-0-and-sextante-tp5057501.html
> Sent from the gvSIG users mailing list archive at Nabble.com.
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> 
> To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url:
> 
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
> 



More information about the Gvsig_internacional mailing list