gvSIG bugs #2232
Lentitud al editar archivos CAD (dgn, dxf,...)
| Status: | Closed | % Done: | 0% | |
|---|---|---|---|---|
| Priority: | High | Spent time: | - | |
| Assignee: |  Juan Lucas Domínguez | |||
| Category: | Vector editing | |||
| Target version: | 2.1.0-2218-testing | |||
| Severity: | Add-on version: | |||
| gvSIG version: | 2.1.0 | Add-on build: | ||
| gvSIG build: | 2216 | Add-on resolve version: | ||
| Operative System: | Linux | Add-on resolve build: | ||
| Keywords: | Proyecto: | |||
| Has patch: | No | Hito: | ||
| Add-on name: | Unknown |
Description
Reportado por Yeli en la lista de usuarios:
*
He estado usando distanta capas, poligonos, puntos, lines y exportados desde microStation como dxf, o abriendo directamente los archivos *.dgn, shape generado de versiones anteriores de gvSIG.
Tengo una capa de Hidrografia de Toda Venezuela, y una carta a escala 25000 de curvas de nivel, y ambas estan presentando el mismo problema, al cargarlas en la vista, lo hace perfecto, el problema esta cuando las pongo editables, la capa de Hidrografia, se tarda 22 minutos en mostrarse en la vista, gvSIG queda completamente "out", puedo mover el curso del mouse, alrededor de la vista, pero no puedo seleccionar ningun icono, una vez que se activa el programa, al intentar seleccionar, algo, debo esperar 22 minutos de nuevo, para poder procesar la capa, queria usar los geoprocesos pero cada vez que selecciono algo debo esperar un monto. La carta de curvas de nivel pasa lo mismo, pero el tiempo en menos, 7 minutos mas o menos.
Probe con las versiones anteriores, y el tiempo de repuesta es casi que inmediato, menos de minuto.
No entiendo porque esta version me esta dando este problema, ya las desintale, pense que quizas instalandose, hubo alguna breve interrupcion del internet y faltaba algo, pero sige dando el mismo problema.
Tengo un procesador AMD A8-3870 APU with Radeom(tm) HD graphic 3.00 GHz, 16GB Ram y mi sistema operativo es de 32 bits.
*
He comprobado con un DGN y un DXF, y efectivamente ocurre que se hace inviable editar estos formatos.
Adjunto un DGN con el que he probado.
Associated revisions
Corrige un problema que habia al intentar convertir una geometria vacia resultado de la interseccion de otras de jts a gvSIG.
El problema se da tambien en otros metodos a parte del intersects de Geometry y habria que repasarlos.
refs #2232
History
#1
Updated by Álvaro Anguix over 10 years ago
El dgn pesa más de lo que admite. JLucas, si lo necesitas te lo mando por otro medio.
#2
Updated by Álvaro Anguix over 10 years ago
Más información reportada por Yeli sobre este bug en:
http://listserv.gva.es/pipermail/gvsig_usuarios/2014-January/027120.html
#3
Updated by Joaquín del Cerro Murciano over 10 years ago
Hola Alvaro.
Le he echado un vistazo a esto y tiene mas tela de la que parece.
La primera impresion que ha ha dado es que a mi me funcionaba perfectamente.
Cargaba el DXF [1] que usamos para pruebas sin ningun problema, lo ponia en
edicion y iba todo bien en un tiempo mas que razonable.
Iba a contestar que no lo podia reproducir que necesitaba algo mas de informacion
cuando se me ha ocurrido echar un vistazo a mi configuracion de los snappers de
edicion. No tenia ninguno activado.
Asi a lo bruto, se me a ocurrido activarlos todos y al entrar en edicion y
pasar la flecha sobre la vista, cosa que la primera vez no me he dado ni
cuenta cuando lo he hecho, se ha quedado todo frito, y de vez en cuando
me salian unos mensajes de error por la consola.
Me he puesto a seguir las trazas que sacaban y he encontrado un error en
la funcion que calcula la interseccion de geometrias que provoca que saque
muchos errores por la consola, lo que hace en si mismo que todo vaya lento
al estremo que no se puede hacer nada.
He arreglado el error y tras eso ya ha empezado a responder, muy lento, pero
iba respondiendo.
Si antes de entrar en edicion hago zoom a una zona pequeña, sin muchas geomtrias
la cosa parece funcionar mejor. No se si es cuestion de algun snap en concreto,
el hecho de tener muchos activos, o trabajar con una capa de 44.000 geometrias e
intetar calcular el snap a ella estando todas visibles.
Probablemente haya que repasar con cuidado el funcionamiento de los snapers.
Limitando el numero de geometrias sobre las que trabajan y viendo de lanzarlo
a un hilo de ejecucion aparte para que el calculo del snap y su visualizacion no
impidan trabajar con gvSIG si su calculo se vuelve muy pesado.
He probado a dejar activo solo un snapper, punto mas cercano, ajustado a pixel,
punto central o punto tangente, e incluso dos o tres de estos a la vez y la cosa
mas o menos funciona.
Habria que probar a ver si tiene que ver con alguno en concreto.
[1]http://downloads.gvsig.org/download/geodata/vector/DXF/LaRioja3_IDERIOJA_DXF.zip
Un saludo
Joaquin
#4
Updated by Álvaro Anguix over 10 years ago
Estando donde indica Joaquín el problema, quizá entonces la solución puede ir en relación a un determinado zoom, ya que por ejemplo con un zoom todo y muchas geometrías, a nivel funcional, tampoco tiene sentido.
#5
Updated by Álvaro Anguix over 10 years ago
He subido un DGN del IGN con múltiples geometrías en:
https://mega.co.nz/#!8p5y1Y5A!f3y3CQg7WFS9btfwSxXXiCX8DAio5WXEndLgUP0IkiM
#6
Updated by Álvaro Anguix over 10 years ago
En la 1.x he comprobado que funciona de manera bastante ágil, por si por ahí podéis encontrar la forma de solucionar el ticket.
#7
Updated by Álvaro Anguix over 10 years ago
He estado haciendo pruebas en la línea de lo comentado por Joaquín.
Por defecto gvSIG tiene en el 2217 2 snaps activados: punto más cercano, vértice e intersección.
Al poner en edición el DGN adjuntado tarda minutos en refrescar.
Una vez consigo entrar en las propiedades de edición/snapping he ido desactivando y activando, intentando ver donde estaba el problema.
Con cualquier combinación de snaps parece que funciona bien y bastante rápido, salvo cuando está activo el de "Intersección".
Con este activo es cuando he detectado los problemas de lentitud.
#8
Updated by Juan Lucas Domínguez over 10 years ago
- Status changed from New to Fixed
El snapper de intersección no creo que estuviera bien. Se ignoraba el punto en el que está el ratón y se ponía a hacer intersecciones de todas con todas las geometrías de la cache ¿?
No tengo claro cómo debería funcionar ese snapper. Desde luego, lo que se estaba intentando hacer no es viable "al vuelo".
Por ahora, simplemente lo he quitado y el comportamiento que veo tras el cambio de Joaquín parece razonable.
=========
Removed intersection point snapper which was not properly implemented.
#9
Updated by Álvaro Anguix over 10 years ago
Sobre el funcionamiento del snapper intersección, a nivel de usuario debería ser parecido a lo que hace AutoCAD. Dejo un enlace a un vídeo donde se ve en funcionamiento:
http://www.foroz.org/videotutoriales/autocad-35-object-snap-nodos-y-cuadrantes-video_be3321031.html
#10
Updated by Juan Lucas Domínguez over 10 years ago
- Status changed from Fixed to In progress
Se me ha ocurrido un modo de hacer algo que haga algo, luego lo miro
#11
Updated by Juan Lucas Domínguez over 10 years ago
- Status changed from In progress to Fixed
He restaurado el snapper de intersección pero limitado en el número de geometrías. Es decir, si se detectan muchas geometrías cerca del ratón, no se hace nada, por tanto el usuario empezará a poder usarlo cuando se acerque. El problema viene porque la operación intersección es muy pesada. Para mejorar esto, habría que cambiar el mecanismo de snapping, pero con lo que hay ahora creo que es una herramienta útil en la mayoría de casos.
===
Restored intersection point snapper but with a strong limitation in the number of geometries involved. Also, prevented snapping computations in map overview.
#12
Updated by Juan Lucas Domínguez over 10 years ago
Por cierto en gvSIG 1.12 este problema no está resuelto. El archivo Albacete.dgn también bloquea la GUI. Ahora en gvSIG 2.1.0 no se bloquea, pero como he dicho solo se "activa" cuando te acercas.
#13
Updated by Álvaro Anguix over 10 years ago
Ok, perfecto. Ya probamos el funcionamiento en el siguiente build, pero suena bien la solución.
#14
Updated by Álvaro Anguix over 10 years ago
- Status changed from Fixed to Closed
Lo cierro porque el comportamiento ha mejorado en la 2218.
Una cosa que me he dado cuenta, que quizá habría que revisar, es que cuando no estas empleando herramientas de edición o selección sigue identificando los puntos de snapping. No sé si esto ralentiza, pero en ese caso una forma sencilla sería acotar a que solo los identificara con las herramientas que los usan. Por ejemplo, cuando estás haciendo un zoom un desplazamiento no tiene ningún sentido que esté continuamente identificando los puntos de snapping por donde pasa el cursor.