[Gvsig_english] gvSIG 2.0 and sextante?

[Cèsar Ordiñana]

El 04/06/13 18:52, Victor Olaya escribió:
> Let me reword my phrase:
>
> It is sad that you decided to create your own API just because (as
> Alvaro said), you didn't want anything created by the gvSIG
> association to not be GPL. So instead, of contributing to  SEXTANTE,
> you wrote your own geoprocessing API and wrote your new geprocesses
> for your API instead of directly for SEXTANTE.
>
> So, in the end, the reason why we do not have those geoprocesses in
> the official SEXTANTE bindings is a matter of licenses, because, if
> you were happy with the SEXTANTE license, I suppose you would have
> contributed those new algorithms to SEXTANTE (as far as I understand,
> the gvSIG project had no other reason for forking SEXTANTE than the
> license issue, right?). There is already an app-specific package with
> algorithms such as those ones, that only run on gvSIG and are not
> generic, so that wouldn't be a problem
>
> Ideally, the changes you made for the new geoprocessing framework in
> 2.0 should be on SEXTANTE, having new bindings for 2.0 (and maybe
> other changes that could benefit other applications), but the lack of
> understanding between both projects lead to this. And that lack of
> understanding was caused by a license issue...
>
> I am not saying it is a bad thing, but that's how it all happened....

I agree with the lack of understanding, which is sad but that's how it is.

But the gvSIG geoprocesses use many gvSIG 2.0 APIs, like the data access 
ones, that wouldn't have changed regardless of the license matter. And 
being gvSIG-only geoprocesses, I don't understand why they have to be 
contributed to sextante and can't remain in gvsig.

Anyway, this discussion is based on guessing about what would have 
happened if things were different, so who knows...

Regards.

2013/6/4 Cèsar Ordiñana <cordinyana at gvsig.com>:
>> El 04/06/13 15:30, Victor Olaya escribió:
>>> "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."
>>>
>>> I agree that this is a good thing, and it is sad that this development
>>> was not incorporated to SEXTANTE just for a matter of licenses...
>>>
>>> Cheers
>>> Victor
>> Sorry but this is not true. Those geoprocesses use the gvSIG 2.0 APIs
>> and wouldn't run on sextante alone, regardless of the license.
>>
>> Regards.
>>

-- 
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (http://www.disid.com)