[Gvsig_usuarios] Abrir proyectos versión anterior (1.12)

[Alvaro Anguix]

Hola,

El 16/09/15 a las 19:49, Luis Luna escribió:
> Hola Álvaro.
>
> La verdad no conozco la estructura del programa. 
> Lo que me cuesta trabajo entender, que teniendo un objeto XML DOM,
> seguramente cargado en el, todo el proyecto, sea tan difícil recorrer este
> árbol e ir asignando a la nueva estructura el objeto nuevo correspondiente o
> en un momento dado, no cargarlo, solo guardarlo en un fichero con la
> estructura de la versión 2.
> Ya le digo desconozco la estructura interna, pero esa línea roja la tenían
> que haber puesto en la versión 0, como lo hacen otros programas.
Esto tiene mucho que ver con la evolución del software, que parte de un
software que impulsa una administración para una necesidad propia, que
libera y que evoluciona con el tiempo, tanto a nivel técnico como
organizativo y de gestión.
En cualquier caso, como he comentado anteriormente, hasta el momento
ninguna organización ha mostrado interés en financiar ese desarrollo.

Saludos,
Alvaro

> Saludos Luis.
>
>
>
> -----Mensaje original-----
> De: gvsig_usuarios-bounces en listserv.gva.es
> [mailto:gvsig_usuarios-bounces en listserv.gva.es] En nombre de Alvaro Anguix
> Enviado el: miércoles, 16 de septiembre de 2015 14:58
> Para: gvsig_usuarios en listserv.gva.es
> Asunto: Re: [Gvsig_usuarios] Abrir proyectos versión anterior (1.12)
>
> Hola Luis,
>
> El 16/09/15 a las 15:25, Luis Luna escribió:
>> Saludos.
>> He estado mirando por el indice del foro y no encuentro entradas a 
>> este tema, supongo que debe haber alguna.
>> Tenemos hecho un gran numero de proyectos en gvSIG1.12, el problema 
>> esta en que tenemos que cambiar de maquinas y de SO.
>> Funcionan muy bien en Windows XP y nos pasan a Ubuntu.
>> Ya con las maquinas nuevas, queríamos también avanzar en gvSIG y pasar 
>> a la versión 2.
>> Como ya sabréis no se importan proyectos hechos en la 1.12 a la 2. 
>> Cosa que no entiendo muy bien, ya que los ficheros gvp son ficheros en 
>> formato XML, formato que se usa para pasar información de una 
>> plataforma a otra.
> No es un tema de XML.
> La principal diferencia entre gvSIG 1.x y gvSIG 2.x es un trabajo de
> rearquitectura interna, que entre otras cosas cambia el modelo de datos.
> Cambios que van en la línea de facilitar el mantenimiento de la aplicación,
> permitir mayor estabilidad, menos coste de desarrollo, etc.
> Entre las distintas implicaciones del cambio de arquitectura, estaba la
> incompatibilidad de proyectos. Esto es algo poco deseable, pero para avanzar
> en gvSIG era necesario.
>
> Mi recomendación, según el caso que comentas, es trabajar con gvSIG 1.12
> viejos proyectos e ir realizando los nuevos en las última versión (gvSIG
> 2.2). Y en la medida de lo posible ir migrando esos proyectos a la nueva
> versión.
>> ¿A esto no se le dará solución? , ¿Tan difícil es hacer una utilidad 
>> que los convierta(de gvl a gvsproj)?,
> Los recursos propios este último año se decidió dedicarlos principalmente a
> tareas de estabilización, migración de funcionalidad y corrección de bugs.
> El hacer una herramienta de importación de proyectos puede ser costosa, sí,
> al menos para importar todo o la mayor parte de un proyecto (esto implica
> importación no sólo de rutas, sino de leyendas, etiquetados, configuración
> de propiedades de capas, propiedades de documentos, mapas, etc.). Salvando
> las distancias, es como si se pidiera un importador de proyectos entre dos
> SIG distintos y es que en cierto modo, gvSIG 2.x es un SIG distinto de gvSIG
> 1.x.
>
> Por otro lado, al menos que nosotros sepamos, ninguna organización ha visto
> interés en financiar e impulsar ese desarrollo (o en desarrollarlo).
>>  cuando saquen la versión 3 ¿También
>> se inventaran otro tipo de fichero, para los proyectos?
> No se trata de inventar nombres de ficheros como capricho.
> La incompatibilidad entre versiones es algo que incluso tenemos como "línea
> roja" en gvSIG 2.x (en gvSIG 1.x hay muchas extensiones que van en una
> versión y dejan de ir en otra). En gvSIG 2.x debería estar muy justificada
> una incompatibilidad, de cualquier tipo, entre versiones.
> Somos conscientes de que hay muchos usuarios, muchas organizaciones que usan
> gvSIG, y un cambio de este tipo puede tener un alto impacto.
> Si no hubiera sido totalmente necesario, no se hubiera hecho.
> Ese cambio se hizo por una razón tan justificada como la que comentaba.
> Hacer los cambios necesarios a nivel interno-arquitectura para solventar los
> problemas de estabilidad y mantenimiento de gvSIG y que coartaban la
> evolución futura del proyecto. La evolución de gvSIG en el último año, en
> gran parte es debida a esta nueva arquitectura.
>
> Saludos,
> Alvaro Anguix
> Asociación gvSIG
>
>> Saludos.
>> _______________________________________________
>> gvSIG_usuarios mailing list
>> gvSIG_usuarios en listserv.gva.es
>>
>> Para ver histórico de mensajes, editar sus preferencias de usuario o darse
> de baja en esta lista, acuda a la siguiente dirección:
>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_usuarios
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en listserv.gva.es
>
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse
> de baja en esta lista, acuda a la siguiente dirección:
>
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_usuarios
>
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en listserv.gva.es
>
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse de baja en esta lista, acuda a la siguiente dirección:
>
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_usuarios