[Gvsig_usuarios] algunas preguntas

Jue Mar 29 17:51:35 CEST 2007

Buf, es demasiado brutal....
¿Puedes pasarme las capas a mi correo personal (azabala en gmail.com) para que
haga la prueba, a ver si soy capaz de encontrar la causa?
El fichero de 300 Kb no habrá problema..el de 24 Mb igual descompuesto con
programas como el hacha o el propio winzip....

Saludos.

El día 29/03/07, "Emilio Gómez Fdez." <egofer en terra.es> escribió:
>
>  Hola Álvaro,
>
> Me has dejado intrigado y he vuelto a repetir el geoproceso con las mismas
> capas, esta vez asegurándome que gvSIG crease el índice espacial para ambas
> y revisando que existiesen los archivos *.qix. En gvSIG el recortado ha
> tardado 59 minutos y al repetir la prueba en ArcMap cual ha sido mi sorpresa
> que lo ha hecho en menos de 2 minutos. Recordaba que la diferencia había
> sido significativa, pero no pensaba que tanto.
>
> Un saludo,
>
> Emilio Gómez
>
>
> alvaro zabala escribió:
>
> ¿Creaste índices espaciales con gvSIG?
>
> Tiene toda la pinta de que el motivo de semejante retardo sea ese.
> Ten en cuenta que puesto que el formato de índice espacial de los ficheros
> SHP NO ES ABIERTO, gvSIG no puede
> aprovechar los índices espaciales que te hayas creado con ArcMap (shn) y
> necesita los suyos propios.
> Si te vas al menú "propiedades" del toc de una capa vectorial, y marcas la
> opción "crear índice espacial" se crearán unos ficheros con extensión .qix.
>
> Eso debe hacer que el proceso intersección tarde por lo menos la mitad
> (piensa que para ver las intersecciones de un polígono, ya no será necesario
> recorrer secuencialmente todos los polígonos de la otra capa, solo los que
> devuelva el índice espacial).
>
> Aún así, mientras que para la realización de cálculos topológicos básicos
> gvSIG se apoye en JTS, seguirá padeciendo las deficiencias de éste:
> http://lists.jump-project.org/pipermail/jts-devel/2007-March/001919.html y
> disfrutando de sus ventajas!
>
> JTS por diseño no sigue un modelo topológico (como el que pueda seguir
> grass, muy similar al formato de cobertura de arc/info), y esto penaliza
> ciertas operaciones como el cálculo reiterado de intersecciones de polígonos
> de dos capas.
>
> Un saludo.
>
>
>
>
>
>
>
>
> Emilio Gómez Fdez. escribió:
>
> Hola,
>
> Perdonar que me entrometa. Yo en lo que si he encontrado diferencias
> sustanciables de tiempo entre ArcGIS 9.1 y gvSIG a favor del primero ha
> sido en el geoproceso de recortar. A partir de una capa de polígonos con una
> superficie de 5.321 km2 (300 KB y seis campos) recorté otra con 114.200polígonos (24 MB y tres campos por registro) correspondientes a
> edificaciones para extraer únicamente las que se encontraban dentro de
> aquella. ArcGis 9.1 tardaba en recortar la capa unos 15-20 min aprox. si
> mal no recuerdo, mientras que gvSIG  se acercaba a la hora.
>
> Un saludo,
>
> Emilio Gómez Fernández
>
> José Antonio Canalejo Alonso escribió:
>
> Hola Alvaro,
> gracias por tu respuesta tan bien documentada. Aunque
> como tu dices, las comparaciones son odiosas, yo tengo
> la misma impresion (JUMP no he probado, pero si con
> ArcGIS 9.1 y ArcView3.2) sobre los rendimientos.
> Mis pruebas han sido por ejemplo un clip con:
> - shape de referencia "a cortar": geometria muy
> irregular (800000 ha), 126 MB y 93500 registros con
> dos campos en la tabla.
> - shape máscara de corte: geometría muy irregular (80
> ha), 2MB y 318 registros con 12 campos.
> Gracias por tu respuesta,
> José Antonio Canalejo
>
> --- alvaro zabala <alvaro.zabala en juntadeandalucia.es><alvaro.zabala en juntadeandalucia.es>
> escribió:
>
>
>
> Jose Antonio, el tamaño puede ser muy subjetivo
> ¿podrías dar mas datos sobre las capas empleadas? (nº de registros, tamaño
>
> en Mb de los ficheros, nº de puntos de las entidades geográficas,
> etc.)
>
> Yo he hecho varias comparativas con ArcMap 8.3 y
> otros programas libres (JUMP, etc.) y básicamente se puede apreciar:
>
> -un mejor rendimiento de gvSIG en el cálculo de
> buffers, al emplear una optimización especial. Este mejor rendimiento se
> aprecia cuanto MAYOR SEA LA DISTANCIA DE buffer (por ejemplo, buffers de
> 20 Km en una capa de municipios..., buffers por debajo de 100 no son
> perceptibles)
>
> -por lo general, un mejor rendimiento de ArcMap (en
> torno al 15%) en la realización de operaciones de overlay (unión,
> diferencia, intersección), debido a que ArcMap en última instancia
> construye
> estructuras de almacenamiento topológico, mientras que gvSIG se
> apoya en JTS, que sigue el modelo SFS de OGC (es decir, no sigue un modelo
>
> de datos topológico).
>
> -un mejor rendimiento de gvSIG frente a JUMP, etc.
> especialmente visible conforme aumenta el tamaño de los datos de entrada
> (gvSIG escala, OpenJUMP por ejemplo  a partir de determinados datos
> de entrada lanza errores del tipo OutOfMemory)
>
> En general, el geoprocessing de gvSIG muestra
> rendimientos satisfactorios (si comparamos el tiempo de vida de
> ambos productos) pero la ejecución de geoprocesos que en gvSIG toman mucho
>
> tiempo en ArcMap no han tomado mucho menos (estamos hablando del mismo
> orden de magnitud, por ejemplo, uniones que en gvSIG tardaron 10
> minutos en ArcMap tardaron 8 minutos y medio, otra operación costosa es el
>
> cálculo de topología de líneas, la construcción de capas de polígonos a
> partir de capas de líneas, etc.). De todos modos, comparar todavía es
> odioso (si tenemos en cuenta el tiempo de vida de ambos productos, y la
> experiencia sobre determinados campos)
>
> Otro aspecto a tener en cuenta es el ratio nº de
> puntos por entidad geométrica (feature). Quiero decir:  capas de
> polígonos con pocos registros puede tomar tanto o más tiempo que las
> operaciones sobre capas con muchos registros si en el primer caso los
> polígonos tienen muchos vértices (ejemplo: provincias con miles de puntos
> por polígono frente a parcelas catastrales con cientos o decenas).
>
> Saludos
>
>
>
> José Antonio Canalejo Alonso escribió:
>
>
> Hola,
> he realizado algunos test de Geoprocesing con
>
>
> datos de
>
>
> gran tamaño y me han funcionado bien, aunque han
> requerido su tiempo,... Me gustaría conocer
>
>
> vuestras
>
>
> experiencias con ello y si hay limitaciones al
> respecto?  Con respecto a tablas,
> Está previsto poder exportarlas a otros formatos
> (text,dbf,..) o a un banco de datos?
> Esta previsto ofrecer la posibilidad de exportar
>
>
> un
>
>
> shape que tenga tablas asociadas de forma que
>
>
> quede la
>
>
> union permanente?
> Gracias por vuestra colaboración y hasta pronto!!
> José Antonio Canalejo
>
>
>
>
> ______________________________________________ LLama Gratis a cualquier PC
> del Mundo. Llamadas a fijos y móviles desde 1 céntimo por
>
>
> minuto.
>
> http://es.voice.yahoo.com
>
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en runas.cap.gva.es
>
>
>
>  http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>
>
>
>
> --
> Alvaro Zabala Ordóñez
> Servicio de Informática de
> la Dirección General para la Función Pública
> Tlf externo: 955009347
> Tlf interno: 309347
> correo: alvaro.zabala en juntadeandalucia.es
>
>
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en runas.cap.gva.es
>
>
>
> http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>
>
>
>
>
>
> ______________________________________________ LLama Gratis a cualquier PC
> del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto.
> http://es.voice.yahoo.com
>
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>
>
>
>
>
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>
>

-- 
Alvaro Zabala Ordóñez
Tlf: 657235082
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://runas.cap.gva.es/pipermail/gvsig_usuarios/attachments/20070329/cafb91fa/attachment-0001.htm