gvSIG bugs #3806

Spatial join geoprocess results are not correct (points and polygons)

Added by Mario Carrera over 8 years ago. Updated almost 7 years ago.

Status:Closed% Done:

0%

Priority:HighSpent time:-
Assignee:Francisco Díaz Carsí
Category:Geoprocess
Target version:2.4.0-2829 (rev. org.gvsig.desktop-2.0.195)
Severity:Major Add-on version:
gvSIG version:2.2.0 Add-on build:
gvSIG build:2313 Add-on resolve version:
Operative System: Add-on resolve build:
Keywords: Proyecto:
Has patch: Hito:
Add-on name:Unknown

Description

The results are not correct when using Spatial Join gvSIG geoprocess by nearest point.

I attach two layers:
- cuencas_vert_MAGV.shp (polygons)
- Entrada (points)

We select this configuration:
- Input layer: cuencas_vert_MAGV.shp
- Overlay layer: Entrada.shp
- "Use the nearest" option

A lot of polygons are exported, not only the nearest one to every point.

Nota:
A la hora de probar este tique, no tener en cuenta esta descripción, sino los comentarios 12 y 13.

spatial-join.zip (9.84 MB) Mario Carrera, 10/07/2015 11:43 AM

gvSIG.log (401 KB) Francisco Díaz Carsí, 07/01/2017 12:33 PM

Capas.zip (224 KB) Álvaro Anguix, 07/03/2017 08:29 AM

Error_Spatial.png (62.8 KB) Álvaro Anguix, 07/03/2017 08:30 AM

gvSIG.log (403 KB) Álvaro Anguix, 07/03/2017 08:30 AM

1827

Related issues

Related to Application: gvSIG desktop - gvSIG bugs #3013: Error con la herramienta spatialjoin Closed 11/19/2014
Related to Application: gvSIG desktop - gvSIG bugs #3838: Random layers generated from the toolbox are not loaded i... Closed 10/28/2015
Related to Application: gvSIG desktop - gvSIG bugs #3566: enlace espacial no utiliza selección / spacialjoint does ... New 06/02/2015
Related to Application: gvSIG desktop - gvSIG bugs #3118: Name descriptor duplicated with gvSIG "Spatial Join" Invalid 01/19/2015

Associated revisions

Revision 43356
Added by Francisco Díaz Carsí almost 7 years ago

refs #3806 Sustituído el casting a Long de la oid por Number para poder obtener el valor de tipo long y pasarlo al método getFeatureProviderByIndex.

Revision 43371
Added by Francisco Díaz Carsí almost 7 years ago

refs #3806 Fixed Spatial Join Algorithm

Revision 960
Added by Francisco Díaz Carsí almost 7 years ago

refs #3806 Fixed Spatial Join Algorithm

Revision 961
Added by Francisco Díaz Carsí almost 7 years ago

refs #3806 Deleted obsolete spatial index creation.

History

#1 Updated by Mario Carrera over 8 years ago

#2 Updated by Álvaro Anguix over 8 years ago

  • Category set to Geoprocess

#3 Updated by Álvaro Anguix over 8 years ago

Con gvSIG 2.3 da una capa vacía.

#4 Updated by Álvaro Anguix over 8 years ago

  • Severity changed from Minor to Major
  • Target version set to 98
  • Priority changed from Normal to High
  • Assignee set to Daniel Martinez

#5 Updated by Álvaro Anguix over 8 years ago

  • Assignee deleted (Daniel Martinez)

#6 Updated by Álvaro Anguix over 8 years ago

  • Related to gvSIG bugs #3838: Random layers generated from the toolbox are not loaded in the view added

#7 Updated by Joaquín del Cerro Murciano over 8 years ago

  • Target version deleted (98)

#8 Updated by Álvaro Anguix almost 7 years ago

  • Related to gvSIG bugs #3566: enlace espacial no utiliza selección / spacialjoint does not use selecction added

#9 Updated by Álvaro Anguix almost 7 years ago

  • Related to gvSIG bugs #3118: Name descriptor duplicated with gvSIG "Spatial Join" added

#10 Updated by Álvaro Anguix almost 7 years ago

  • Target version set to 2.4.0-2850-final (rev. org.gvsig.desktop-2.0.220)

#11 Updated by Francisco Díaz Carsí almost 7 years ago

En principio no puedo reproducir el error, porque salta un error antes.
Es un error de casting cogiendo el feature provider por referencia.

Adjunto log.

Una vez arreglado este error que subo relacionándolo con este tique, voy a ver si se puede solucionar el tema propio de éste.

#12 Updated by Francisco Díaz Carsí almost 7 years ago

  • Status changed from New to Awaiting response

A ver, repasando lo que hace el algoritmo y lo que se pretende que haga el algoritmo de la descripción de este tique, creo que nos estamos equivocando.

Tenemos dos capas, una de polígonos y otra de de puntos.
Seleccionamos la capa de polígonos como capa de entrada.
Selecionamos la capa de puntos como capa de "revestimiento".
Y marcamos el checkbox "Usar el más cercano".

Entonces, según la ayuda del propio algotimo, "Asigna a un elemento de la capa origen los atributos del elemento más próximo de la capa enlazada".
¿Qué entiendo que quiere decir esto?
Que el algoritmo debería devolver TODOS o los SELECCIONADOS de la capa de polígonos, añadiéndole los atributos de los elementos más cercanos de la capa de puntos.
Hasta ahí considero que el algoritmo, si falla, no es precisamente por devolver demasiados elementos de la capa de polígonos, si no por no delvolverlos todos (o su selección).
Si, en este momento no los devuelve todos, es por todas las restricciones que le hemos ido poniendo a la salida de este algoritmo capa vez que revisitábamos este tique (u otros relacionados).

Si queremos un comportamiento distinto al que he descrito, habría que darle toda la vuelta al algoritmo.

A la espera de tomar una decisión al respecto, marco este tique como "Awaiting response".

#13 Updated by Álvaro Anguix almost 7 years ago

Perdón...el error que da es al contrario (revisando el texto de Mario).
La capa de entrada es la de puntos, imagina por ejemplo que son "delitos"
La capa de revestimiento es de polígonos, imagina por ejemplo que son "barrios". En su tabla de atributos tiene una columna con el nombre del barrio
Queremos hacer un enlace espacial para saber el número de delitos por barrio, es decir, queremos que a la capa de puntos se le añada el campo con el nombre del barrio.
Esto, al hacerlo, da error.

Subo 2 capas con el ejemplo que he puesto y el log. y la imagen de aviso de error.
Aunque igual no tiene nada que ver, con el geoproceso de enlace espacial de Sextante sí lo hace, pero el resultado que da es erróneo.

#14 Updated by Francisco Díaz Carsí almost 7 years ago

  • Target version changed from 2.4.0-2850-final (rev. org.gvsig.desktop-2.0.220) to 2.4.0-2829 (rev. org.gvsig.desktop-2.0.195)
  • Assignee set to Francisco Díaz Carsí
  • Status changed from Awaiting response to Fixed
  • Description updated (diff)

#15 Updated by Álvaro Anguix almost 7 years ago

  • Status changed from Fixed to Closed

Also available in: Atom PDF