gvSIG bugs #2582
SEXTANTE Merge geoprocess returns always an empty layer
Status: | Closed | % Done: | 0% | |
---|---|---|---|---|
Priority: | Normal | Spent time: | - | |
Assignee: | ||||
Category: | Geoprocess | |||
Target version: | 2.1.0-2254-testing | |||
Severity: | Minor | Add-on version: | ||
gvSIG version: | 2.1.0 | Add-on build: | ||
gvSIG build: | 2229 | Add-on resolve version: | ||
Operative System: | Add-on resolve build: | |||
Keywords: | merge | Proyecto: | ||
Has patch: | Hito: | |||
Add-on name: | Unknown |
Description
SEXTANTE Merge geoalgorithm returns always an empty layer, even if the input layers are defined in same CRS.
How to reproduce this bug:
1) Create a random vector layer made of one polygon (two times);
2) Execute the Merge geoalgorithm (Tools for vector layers).
See the sextante.log in attachment.
Related issues
History
#1
Updated by Antonio Falciano about 10 years ago
In the sextante.log there's a warning:
WARNING: Distintos_CRS
...so this issue could potentially affect other SEXTANTE geoprocesses.
#2
Updated by Antonio Falciano almost 10 years ago
- File sextante_merge_2247.log added
Something is changed in the meanwhile, so I attach another sextante.log. There's a java.lang.ArrayIndexOutOfBoundsException probably due to the GEOMETRY field available in both table definitions. See also #2849.
#3
Updated by Álvaro Anguix almost 10 years ago
- Related to gvSIG bugs #2849: Several SEXTANTE geoprocesses don't work fine due to the GEOMETRY field added
#4
Updated by Joaquín del Cerro Murciano almost 10 years ago
- Target version set to 2.1.0-2259-rc3
- Assignee set to Francisco Díaz Carsí
#5
Updated by Joaquín del Cerro Murciano almost 10 years ago
- Target version changed from 2.1.0-2259-rc3 to 2.1.0-2251-testing
- Status changed from New to Fixed
#6
Updated by Antonio Falciano almost 10 years ago
- Status changed from Fixed to New
- File gvSIG_merge.log added
I reopen the ticket, because the result of SEXTANTE Merge is an empty layer yet in build 2251. See gvSIG.log in attachment.
#7
Updated by Joaquín del Cerro Murciano almost 10 years ago
- Target version changed from 2.1.0-2251-testing to 2.1.0-2259-rc3
#8
Updated by Francisco Díaz Carsí almost 10 years ago
- Status changed from New to In progress
#9
Updated by Francisco Díaz Carsí almost 10 years ago
- Status changed from In progress to Fixed
#10
Updated by Joaquín del Cerro Murciano almost 10 years ago
- Target version changed from 2.1.0-2259-rc3 to 2.1.0-2254-testing
#11
Updated by Antonio Falciano almost 10 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.
#12
Updated by Álvaro Anguix almost 10 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.
#13
Updated by Joaquín del Cerro Murciano almost 10 years ago
- Target version changed from 2.1.0-2259-rc3 to 2.1.0-2254-testing
#14
Updated by Antonio Falciano almost 10 years ago
- Status changed from Fixed to Closed
The output layer is correctly generated now (thank you very much), however its attribute table contains an ID field with all zeros (it should be trivial to fix). I think that we can close this ticket and open another one about the attribute table issue.