gvSIG bugs #2849

Several SEXTANTE geoprocesses don't work fine due to the GEOMETRY field

Added by Antonio Falciano over 9 years ago. Updated over 9 years ago.

Status:Closed% Done:

100%

Priority:HighSpent time:-
Assignee:Francisco Díaz Carsí
Category:Geoprocess
Target version:2.1.0-2254-testing
Severity:Critical Add-on version:
gvSIG version:2.1.0 Add-on build:
gvSIG build: Add-on resolve version:
Operative System: Add-on resolve build:
Keywords:geometry, geoprocess, sextante Proyecto:
Has patch:Yes Hito:
Add-on name:Unknown

Description

Several SEXTANTE geoprocesses, such as those based on the overlay concept or that manage the fields in the attribute table, don't work fine as they did in the past due to the GEOMETRY field introduced in gvSIG 2.1.0.
Inspecting the code, I see that gvSIG geoprocesses use a new AbstractSextanteGeoProcess that extends the native abstract class GeoAlgorithm to skip the GEOMETRY field, among the other things. Instead, the SEXTANTE geoprocesses continue to use the old GeoAlgorithm class.

Because updating all the SEXTANTE geoalgorithms would be a huge work and, above all, would break definitively the continuity with the official SEXTANTE project, a suitable solution could be to skip the GEOMETRY field at an higher level. Why the GEOMETRY field was introduced? Is it possible to use it only where it's necessary?

This is a severe issue, because it affects not only the geoalgorithms themselves, but all the existing works based on them (e.g. SEXTANTE models or scripts). So if an organization or a GIS professional uses such models or scripts and wants to continue to use them in the future, gvSIG 2.1.0 should ensure the full compatibility, otherwise it/he will be obliged to continue to use an older version of gvSIG (where is the innovation?) or port their work elsewhere... Furthermore, I'd avoid to break the links and the continuity with the official SEXTANTE project, because if someone develops a new SEXTANTE geoalgorithm, all its different implementations could benefit from this! ;)

skip_geometry_field_etc.patch Magnifier (6.25 KB) Antonio Falciano, 10/19/2014 02:33 PM

Related issues

Related to Application: gvSIG desktop - gvSIG bugs #2800: Geoprocesos ignoran la selección Closed 09/02/2014
Related to Application: gvSIG desktop - gvSIG bugs #2528: Poligonar líneas da error Closed 05/19/2014
Related to Application: gvSIG desktop - gvSIG bugs #2582: SEXTANTE Merge geoprocess returns always an empty layer Closed 06/19/2014
Related to Application: gvSIG desktop - gvSIG bugs #2851: RuntimeException: Name descriptor duplicated executing SE... Closed 10/03/2014

Associated revisions

Revision 98
Added by Francisco Díaz Carsí over 9 years ago

refs #2849 Fixed an i18n string in IntersectionAlgorithm.

Revision 99
Added by Francisco Díaz Carsí over 9 years ago

refs #2849 Adjusted the default value management in VectorAddFieldAlgorithm

History

#1 Updated by Antonio Falciano over 9 years ago

Here's a partial list of SEXTANTE vector geoprocesses that don't work due to this issue and the exception that usually occurs (see the sextante.log):
  • "Merge", "In-polygon spatial join", "Polygonize", "Add field", "Rename field", "Delete field" --> java.lang.ArrayIndexOutOfBoundsException
  • "Union" --> java.lang.RuntimeException: Name descriptor GEOMETRY duplicated. (File not found) --> see also #2851

#2 Updated by Álvaro Anguix over 9 years ago

#3 Updated by Álvaro Anguix over 9 years ago

#4 Updated by Antonio Falciano over 9 years ago

Related to #2582 and #2851.

#5 Updated by Álvaro Anguix over 9 years ago

  • Related to gvSIG bugs #2582: SEXTANTE Merge geoprocess returns always an empty layer added

#6 Updated by Álvaro Anguix over 9 years ago

  • Related to gvSIG bugs #2851: RuntimeException: Name descriptor duplicated executing SEXTANTE vector geoprocesses added

#7 Updated by Álvaro Anguix over 9 years ago

  • Target version set to 2.1.0-2259-rc3

#8 Updated by Álvaro Anguix over 9 years ago

  • Assignee set to Francisco Díaz Carsí

#9 Updated by Álvaro Anguix over 9 years ago

  • Status changed from New to Invalid

Parece que los errores mencionados no están relacionados con lo que se comenta y el arreglo/s parece que es/son otro/s.
En principio pasamos a invalid este ticket y vamos solucionando los tickets de geoprocesos mencionados.

#10 Updated by Antonio Falciano over 9 years ago

Álvaro Anguix wrote:

Parece que los errores mencionados no están relacionados con lo que se comenta y el arreglo/s parece que es/son otro/s.
En principio pasamos a invalid este ticket y vamos solucionando los tickets de geoprocesos mencionados.

No problem, Alvaro. The important thing is to fix them one by one.
Although, this one is very self-explicative:
"Union" --> java.lang.RuntimeException: Name descriptor GEOMETRY duplicated. (File not found) --> see also #2851

#11 Updated by Joaquín del Cerro Murciano over 9 years ago

  • Target version changed from 2.1.0-2259-rc3 to 2.1.0-2251-testing

#12 Updated by Joaquín del Cerro Murciano over 9 years ago

  • Status changed from Invalid to In progress

Al final lo que hemos hecho es que los geoprocesos de sextante solo generan tablas con un unico campo de salida que se llama GEOMTRY.

#13 Updated by Francisco Díaz Carsí over 9 years ago

  • % Done changed from 0 to 100
  • Target version changed from 2.1.0-2251-testing to 2.1.0-2259-rc3
  • Status changed from In progress to Fixed

gvsig-geoprocess:r570

Se ha arreglado para que cuando el geoproceso crea la capa temporal no tenga en cuenta las columnas de tipo GEOMETRY de las capas de origen y cree él una única columna de este tipo.

#14 Updated by Joaquín del Cerro Murciano over 9 years ago

  • Target version changed from 2.1.0-2259-rc3 to 2.1.0-2251-testing

#15 Updated by Álvaro Anguix over 9 years ago

  • Status changed from Fixed to Closed

#16 Updated by Antonio Falciano over 9 years ago

  • Status changed from Closed to Invalid

Hi Alvaro,
I think that it's better to set it as Invalid (as you did yesterday) and to open & fix tickets about single geoprocesses, because it's not closed at all: if we consider #2849#note-1, only Polygonize works fine at the moment.
For instance, if you try to use the "Delete field" tool, it reads the GEOMETRY field yet.
IMHO, this is the starting point:

Antonio Falciano wrote:

Inspecting the code, I see that gvSIG geoprocesses use a new AbstractSextanteGeoProcess that extends the native abstract class GeoAlgorithm to skip the GEOMETRY field, among the other things. Instead, the SEXTANTE geoprocesses continue to use the old GeoAlgorithm class.

#17 Updated by Antonio Falciano over 9 years ago

Has patch: Yes

Finally I'm very near to the solution. The SEXTANTE and gvSIG geoprocesses follow two different approaches, so they have their specific dataObjects. This is the reason why gvsig-geoprocess:r570 doesn't fix SEXTANTE geoprocesses (because it's only relative to the gvSIG ones and maybe can break some of them). The right place where we can try to skip the GEOMETRY field is the AbstractVectorLayer class of SEXTANTE (gvsig-toolbox project). I attach a patch that:
  • skips the GEOMETRY field from getFieldNames, getFieldIndexByName and getFieldTypes methods;
  • skips the GEOMETRY field from count in MergeAlgorithm;
  • adjusts the default value management in VectorAddFieldAlgorithm;
  • fixes an i18n string in IntersectionAlgorithm.

Result: the most part of SEXTANTE basic vector geoprocesses is fully working (no evident trace of GEOMETRY field, no errors), with the exceptions of Union and Merge, that have the same issue (Value null not allowed for the attribute...) due to DefaultFeature management in DAL.

#18 Updated by Álvaro Anguix over 9 years ago

  • Has patch set to Yes

#19 Updated by Francisco Díaz Carsí over 9 years ago

  • Status changed from New to Fixed

#20 Updated by Joaquín del Cerro Murciano over 9 years ago

  • Target version changed from 2.1.0-2259-rc3 to 2.1.0-2254-testing

#21 Updated by Antonio Falciano over 9 years ago

  • Target version changed from 2.1.0-2254-testing to 2.1.0-2259-rc3
  • Status changed from Fixed to New

Same issue of RC2 in build 2254. It seems that the org.gvsig.geoprocess add-on build version is 2087 (the same of RC2) instead of 2090.

#22 Updated by Álvaro Anguix over 9 years ago

  • Status changed from New to Fixed

Hi Antonio, the bug is fixed but we don't test in build 2254. I change to fixed.

#23 Updated by Joaquín del Cerro Murciano over 9 years ago

  • Target version changed from 2.1.0-2259-rc3 to 2.1.0-2254-testing

#24 Updated by Antonio Falciano over 9 years ago

  • Status changed from Fixed to Closed

Hi Francisco, thank you for the fix. It seems to work fine in the most cases. Only "Add field" gives me soma problem. In detail, a java.lang.NumberFormatException: empty String occurs, but this depends by the geoalgorithm itself (my fault).
Finally, I close the ticket. Nice job!

Also available in: Atom PDF