[Gvsig_usuarios] algunas preguntas
alvaro zabala
alvaro.zabala en juntadeandalucia.es
Jue Mar 29 14:43:06 CEST 2007
¿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.200 polí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>
>> 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
>
--
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
Más información sobre la lista de distribución gvSIG_usuarios