Taller de novedades de gvSIG (vídeos)

Posted on 08/01/2016 by Alvaro

Disponibles los vídeos del taller de novedades de gvSIG Desktop de las pasadas Jornadas Internacionales de gvSIG.

Este taller está orientado tanto a mostrar las principales novedades de gvSIG Desktop desarrolladas durante el pasado año, como a introducir a nuevos usuarios en la aplicación mediante una serie de sencillos ejercicios prácticos.

La descripción y materiales necesarios del taller podéis encontrarlos en: https://blog.gvsig.org/2015/11/11/11gvsig-taller-de-novedades-gvsig/

Os dejamos con los vídeos que os permitirán seguir el taller paso a paso:

Parte 1

Parte 2

Parte 3

Posted in development, events, gvSIG Desktop, spanish | 2 Comments

Taller de scripting con gvSIG (Vídeos)

Posted on 07/01/2016 by Alvaro

Ya están disponibles los vídeos del taller de scripting con gvSIG que se impartió en las pasadas Jornadas Internacionales de gvSIG.

¡Se acabaron las excusas para no programar en gvSIG!

La información y material necesario para seguir el taller está disponible en: https://blog.gvsig.org/2015/11/10/11gvsig-taller-de-scripting-con-gvsig-2-2/

A continuación os dejamos con los 3 vídeos que comprenden el taller completo, de una duración aproximada de 2 horas y media.

Parte 1:

Parte 2:

Parte 3:

Y si queréis profundizar en el tema, recordaros que hay un curso on-line totalmente gratuito sobre programación en python en gvSIG: http://web.gvsig-training.com/index.php/es/quienes-somos-2/noticias-2/140-massive-online-open-course-de-introduccion-a-scripting-en-gvsig-2-1

Posted in development, events, gvSIG Desktop, scripting, spanish | 2 Comments

Resistance to Change

Posted on 29/12/2015 by mjlobato76

Each time that we want to undertake a new transformation project, it is usual to have among the factors, one too classic: “The Resistance to Change”; and yes, of course it has to be taken into account, but we would like to add some comments about when we are refering to transformation projects such as the migration to an opensource software, for instance, in a public institution.

It is often argued that officials or public servants are used to work with clear closed packages (Operating Systems, Office, etc.) and the resistance of workers to replace these proprietary products for free options, raises the complication of the process of liberation that allows us to move from the nonfree to the free, because we are not migrating the database from one version to another, we are freeing ourselves from the technological and economic units from the use of nonfree software.

And yes, that Resistance has to be considered, but with the idea of exploring the best way to approach it. Let´s see an example. The implementation of a process of technological release (migration to free software) has associated strategic motivations (Independence and Sovereignty Technology) and economic motivations. Regarding to the last ones, just comment that when we spend on purchasing licenses of nonfree products, in most cases we are not spending only the amount of the acquisition of the license, but we are also jeopardizing the budget for the coming years due to the payment of future maintenance. Maintenance certainly will depend on the commercial policy, which will be the one wanted for the owner of the technology.

Now, we look at the economic side. If an employee uses free products, such as operating systems and office products, it will have an associated cost savings in purchasing and maintaining licenses, so, why don´t we share the profits?? That is, for each license of software exclusive not used by the the employee to use a free product, half of the economic benefit could be for the institution and the other half to the public employee in the form of salary supplement, and the same for any another product that we want to release such as an operating system, GIS, etc.

Perhaps, the measure would be hard to implement with the employment law referring to salaries?Maybe, but not being a specialist, there are some alternatives. It just need to be imaginative and study them.

I remember when I started to work with GIS, many drafters carried on working in A0 working tables, and even administrative staff who used electronic typewriters to fill forms (by the way, one day my children asked what was a typewriter and if I had any to show it) .

Drawing tables, typewriters. I don´t remember that the board of directors had in mind the resistance to change in mind for the technological evolution, and I´m sure that the case was bigger than go from nonfree to free software; and the resistance to change can´t be a paralyszing excuse. It has to be addressed and to overcome it, to win over an ideologic inmobility whos is afraid of the progress. The Sovereignty is a question of all of us.

@GabrielCarrionR

Posted in english, opinion | Leave a comment

¿Dónde están los fuentes de gvSIG Desktop?

Posted on 23/12/2015 by Joaquin del Cerro

Hola a todos,
De nuevo con un pequeño articulo relacionado con el desarrollo con gvSIG Desktop.

En los últimos meses me han preguntado ya varias veces dónde están los fuentes de gvSIG.
La respuesta rápida sería :

http://devel.gvsig.org/svn/gvsig-desktop/

Pero en general esto no es suficiente.

La recomendación general que doy siempre es que no recompiléis gvSIG Desktop. No debería haceros falta para crear vuestros propios plugins.

Tendríais que trabajar contra unos binarios de gvSIG y desarrollar vuestros plugins sin tener que compilar todo gvSIG, cosa que es una tarea cuanto menos laboriosa. Para hacernos una idea, compilar todo gvSIG y crear una distribución viene a costar alrededor de diez horas si no aparece ningún problema. El proceso involucra compilar el núcleo de gvSIG junto con unos sesenta proyectos más que están repartidos en más de cuarenta repositorios distintos. Para al final acabar creando una distribución con el núcleo más todos los plugins que forman la distribución.

Esto, hace, que además de conocer sobre el dominio de vuestro problema, tengáis que tener los conocimientos suficientes para compilar y resolver los problemas que puedan surgir para poner a punto todos y cada uno de los plugins que conforman una distribución.

Y no solo eso… si modificáis los fuentes, los recompiláis y los distribuís a vuestros usuarios, y no revertís esas modificaciones al proyecto, habréis “anclado” a esos usuarios en esa versión de gvSIG. Si intentan actualizarse para acceder a correcciones o mejoras en versiones posteriores perderán vuestros cambios. Los obligareis a elegir entre vuestra personalización o las mejoras que puedan aportar las siguientes versiones de gvSIG. Y a cada versión, tendréis que ir llevando vuestros cambios a ella. Cada vez que salga una nueva versión tendréis que coger vuestros cambios y volverlos a introducir en vuestro fork.

Hay muchos que opinan que bien, vale…¿por qué no ?

En mi opinión particular, a medio plazo eso no suele ser bueno ni para los que realizan esa práctica ni para los usuarios que la sufren. Tarde o temprano los usuario se sentirán decepcionados con ese software que no hace mas que requerir esfuerzos para mantenerlo actualizado. Esfuerzos que van más allá de lo que su personalización requiere, ya que en realidad estaréis cargando vuestro desarrollo con el mantenimiento de una distribución de gvSIG y no solo la solución especifica que precisan vuestros usuarios.

Para evitar esto, en gvSIG hemos ido haciendo un esfuerzo por modularizarlo, e introduciendo los “puntos de extensión” necesarios para que no sea necesario modificar el “núcleo” y podáis realizar lo que preciséis desde vuestros plugins. La idea seria disponer de una distribución estándar de gvSIG Desktop instalada, y sobre ella desplegar vuestros plugins de forma que al final podáis crear vuestra propia distribución a partir de la distribución estándar y los plugins que hayáis confeccionado (ya existen herramientas para poder generar distribuciones personalizadas de gvSIG, podéis leer sobre ello en “Crea tú propio gvSIG (¡¡Nuevo plugin!!)”).

Y si hay alguna cosa que no sabéis hacer desde vuestro plugin y creéis que precisáis tocar el código fuente de gvSIG para hacerla, lo mejor es preguntar por las listas de desarrollo. A veces simplemente lo podéis estar enfocando desde el punto de vista equivocado o podemos añadir algún nuevo punto de extensión para poder hacer lo que necesitáis desde vuestros plugins. O a veces lo que queréis hacer es bueno para otros usuarios y simplemente podemos integrarlo en el código de gvSIG.

En ocasiones me dicen que simplemente quieren ver el código de gvSIG. Bien, pues incluso para eso no hace falta descargarse los fuentes. Normalmente el IDE que usáis se puede descargar los fuentes automáticamente para que podáis verlos ya que para cada jar que se crea de gvSIG se crea otro con sus fuentes, estando disponibles en el repositorio de maven del proyecto.

A pesar de todo esto, entiendo que en un momento dado se quiera saber donde están los fuentes… en ocasiones da cierta seguridad. Los fuentes de gvSIG están siempre disponibles para todo el mundo. Podéis navegar en el enlace que puse al principio y ahí esta todo el “núcleo” de gvSIG. Podéis descargaros los fuentes del trunk, pero no suele ser recomendable usar esos. Esos tienen los cambios sobre los que estamos trabajando desde el equipo de gvSIG y muchas veces son inestables o incluso no compilan. Entonces…

¿ Con qué fuentes debería uno trabajar ?

Con cada distribución que se genera de gvSIG, sea una versión final, RC, de testing o de desarrollo, se crea un tag en el SVN con el número de versión donde podemos encontrar los fuentes de esta. Sin embargo, esos números de versión no siguen el mismo criterio que encontramos en la distribución. La versión y número de build que aparece en una distribución esta orientado al producto. Pueden tener que ser modificados de forma arbitraria para adaptarlos a criterios no técnicos en un momento dado. Desde el punto de vista de desarrollo utilizamos números de versión automáticos, siempre incrementales y únicos, y que pueden no coincidir con los de la distribución. De hecho no coinciden.

Entonces… ¿ Cómo sabemos que numero de versión de “desarrollo” se corresponde con una distribución de gvSIG ?

Empiezo por el fácil… ¿ Cómo puedo saber la versión de desarrollo del núcleo de gvSIG para una distribución dada ?

Bien, pues si tenemos una distribución de gvSIG, podemos mirar en la carpeta “lib” del raíz de la instalación. Allí miramos el fichero :

  org.gvsig.andami-*.jar

Nos encontraremos, por ejemplo:

  • gvSIG 2.2.0-2313 ===> org.gvsig.andami-2.0.100.jar
  • gvSIG 2.1.0-2269 ===> org.gvsig.andami-2.0.84.jar

Eso quiere decir que la versión del proyecto org.gvsig.desktop, que es el núcleo de gvSIG, para la 2.2.0-2313 es la 2.0.100.

Una vez ya tenemos claro cual es la versión del núcleo de gvSIG, podemos ir al SVN del proyecto (la url que puse al principio) y en la carpeta tags encontraremos una entrada:

http://devel.gvsig.org/svn/gvsig-desktop/tags/org.gvsig.desktop-2.0.100

…que contendrá los fuentes de esa versión del núcleo de gvSIG.

Ahora bien, eso son solo los fuentes del núcleo. ¿ Y si quiero descargar los fuentes de un plugin que no está en el núcleo ?

Bueno, tiene su parte oscura, por un lado y otra más simple. Dónde esta el SVN de ese plugin y qué versión es la que usa una distribución dada.

Empecemos por la simple con un ejemplo. ¿ Cuál es la versión de desarrollo del proveedor de datos para PostgreSQL ?

Acudiremos igual que para el núcleo a la instalación de gvSIG. En este caso a la carpeta lib de dentro del plugin:

  gvSIG/extensiones/org.gvsig.postgresql.app.mainplugin/lib

Allí nos fijaremos en el jar:

  org.gvsig.postgresql.app.mainplugin-*.jar

En general el jar tendrá el mismo nombre que la carpeta del plugin seguido del número de versión. Pues bien, ese número de versión será con el que tendremos que ir a buscar a la carpeta tag del SVN del proyecto. En el caso de postgreSQL seria algo así como:

http://devel.gvsig.org/svn/gvsig-postgresql/tags/org.gvsig.postgresql-2.0.30/

Para gvSIG Desktop 2.2.0-2313 .

Lo más complicado es averiguar en que SVN “vive” ese plugin. No hay una lista con esa información. La única recomendación que puedo dar es que vayáis a la página de proyectos del redmine de gvSIG, e intentéis localizar el proyecto del redmine que se corresponde con el plugin del que queréis los fuentes. Por ejemplo, para el de PostgreSQL seria:

https://redmine.gvsig.net/redmine/projects/gvsig-postgresql

Y lo normal es que ahí figure la URL al SVN de ese proyecto.

Si no lo identificáis, pues como siempre, preguntad por las lista de desarrollo.

Espero que os haya sido útil.

Un saludo
Joaquín

Posted in development, gvSIG Association, gvSIG Desktop, spanish | 2 Comments

I Concurso Cátedra gvSIG: Ganadores

Posted on 21/12/2015 by Alvaro

Logo_Catedra_gvsig

Durante las pasadas 11as Jornadas Internacionales de gvSIG se anunciaron los ganadores del I Concurso Cátedra gvSIG, un concurso internacional que en su primera edición ha recibido propuestas de un buen número de países.

Los trabajos premiados han sido:

  • Categoría de “Tesis doctoral o trabajo de investigación”: Nuevos métodos para el procesamiento y análisis de información geográfica, de Romel Vázquez Rodríguez (Cuba).
  • Categoría de “Proyectos Fin de Titulación Universitaria (Licenciatura, Grado, Máster)”: Optimización de la gestión de la Comunidad de Regantes, con tecnología de Sistemas de Información Geográfica (SIG), de Jorge Ayén Padilla (España).

En el primer caso el objetivo era desarrollar un modelo que permitiera integrar herramientas de visualización en gvSIG para el análisis de grandes volúmenes de datos espacio-temporales, brindando la posibilidad de analizar simultáneamente múltiples variables geo-referenciadas, que pudieran representar series temporales.

En el segundo caso el objetivo era conocer la superficie agraria real en la actualidad de la Comunidad de Regantes estudiada, como base de todo proceso de modernización y gestión; conocer los usos reales del ámbito de la Comunidad de Regantes y realizar una gestión más eficiente en la distribución del agua.

Más información de los trabajos y acceso completo a ambos en:

Posted in events, gvSIG Desktop, press office, spanish | Tagged , , | 3 Comments

gvSIG available in OSGeo4W

Posted on 14/12/2015 by Mario

OSGeo4w_gvsig

gvSIG Desktop has been included in OSGeo4W.

OSGeo4W is an open source GIS for Windows distribution. It contains more than 150 packages, and the main geomatics applications are included among them.

From now gvSIG 2.2 can be installed from the OSGeo4W 32 bits official installer: http://download.osgeo.org/osgeo4w/osgeo4w-setup-x86.exe

As it’s planned, gvSIG 2.3 will include a distribution for Windows 64 bits, that also will be available from OSGeo4W.

Other future improvements that are planned are:

– To be available at the “Express Desktop Install” modality

– To include the builds in development

Related news:

– gvSIG is graduated as an OSGeo project: https://blog.gvsig.org/2015/11/27/gvsig-is-graduated-as-an-osgeo-project/ 

Posted in english, gvSIG Desktop, press office, technical collaborations | Leave a comment

gvSIG disponible en OSGeo4W

Posted on 14/12/2015 by Alvaro

OSGeo4w_gvsig

gvSIG Desktop ha sido incluido en OSGeo4W.

OSGeo4W es una distribución de software SIG libre para Windows. Contiene más de 150 paquetes y entre ellos se encuentran las principales aplicaciones de geomática libre.

Desde ahora ya se puede instalar gvSIG 2.2 con el instalador oficial de 32 bits de OSGeo4W: http://download.osgeo.org/osgeo4w/osgeo4w-setup-x86.exe

Tal y como está previsto, gvSIG 2.3 incluirá distribución para Windows 64 bits, que también estará disponible desde OSGeo4W.

Otras mejoras futuras previstas son:

– Que esté disponible en la modalidad “Express Desktop Install”

– Incluir también los builds de desarrollo

Noticias relacionadas:

– gvSIG se gradúa como proyecto OSGeo: https://blog.gvsig.org/2015/11/26/gvsig-se-gradua-como-proyecto-osgeo/

Posted in gvSIG Desktop, press office, spanish, technical collaborations | Tagged , , | 1 Comment

A vueltas con la Resistencia al Cambio

Posted on 11/12/2015 by Gabi

Siempre que se quiere emprender un proyecto de transformación, es habitual que entre los factores a tener en cuenta reluzca un clásico: “La Resistencia al Cambio” ; y sí, por supuesto que hay que tener en cuenta dicho factor, pero quisiera comentar algo al respecto cuando nos referimos a procesos de transformación como la migración a software libre en, por ejemplo, una institución pública.

Se suele argumentar que los funcionarios o servidores públicos están habituados a trabajar con paquetes cerrados (Sistemas Operativos, Ofimática, etc) y claro, que la resistencia del trabajador a sustituir dichos productos privativos por opciones libres dificulta enormemente el proceso de liberación que nos permita transitar de lo privativo a lo libre, pues no estamos migrando la Base de Datos de una versión a otra, estamos liberándonos de las dependencias tecnológicas y económicas derivadas del uso del software privativo.

Y sí, hay que tener en cuenta dicha Resistencia, pero para estudiar la mejor manera de abordarla. Pongamos un ejemplo. Poner en marcha un proceso de liberación tecnológica (migración a software libre) lleva asociadas motivaciones estratégicas (Independencia y Soberanía Tecnológica) y motivaciones económicas. Al respecto de las motivaciones económicas, comentar que cuando gastamos en la adquisición de licencias de productos privativos, en la mayoría de los casos no estamos gastando tan solo el importe de la adquisición de la licencia, sino que también estamos hipotecando presupuesto de los próximos ejercicios con el pago de los mantenimientos futuros. Mantenimientos por cierto que van a depender de la política comercial que quiera plantear la compaña propietaria de la tecnología.

Fijémonos ahora en la parte económica. Que un empleado utilice productos libres, como Sistemas Operativos o productos ofimáticos, lleva asociado un ahorro económico en adquisición y mantenimiento de licencias, entonces, ¿porqué no repartimos los beneficios? Es decir, por cada licencia de ofimática privativa que deje de utilizar el empleado para utilizar un producto libre, la mitad del beneficio económico podría ser para la institución y la otra mitad para el empleado público en forma de complemento salarial, y lo mismo para cualquier otra producto que queramos liberar como Sistema Operativo, Sistema de Información Geográfica, etc.

¿Qué la medida sería difícil de implementar a tenor de las legislaciones vigentes en materia salarial? No sé, no soy especialista, pero vamos, alternativas hay, de lo que se trata es de ser imaginativo y estudiarlas.

Recuerdo que cuando empecé a trabajar en el tema de los Sistemas de Información Geográfica, muchos delineantes seguían dibujando en mesas de dibujo tamaño A0, e incluso había personal administrativo que seguía utilizando máquinas de escribir electrónicas para rellenar ciertos formularios (por cierto, el otro día mis hijos me preguntaban que era una máquina de escribir y que si tenía alguna guardada se la mostrara para ver como son).

Tableros de dibujo, Máquinas de escribir. No recuerdo que en aquellos momentos desde la dirección se tuviera muy en cuenta el factor de la resistencia al cambio para la evolución tecnológica, que seguro que el caso mencionado era mayor que la del paso del paquete de ofimática privativo a libre; y es que, la resistencia al cambio no ha de convertirse en una excusa paralizante. Hay que abordarla, pero para superarla, para vencer a un inmovilismo ideológico al que le aterra el progreso. La Soberanía es cosa de todos.

@GabrielCarrionR

Posted in opinion, spanish | 1 Comment

Camino a gvSIG 2.3: Segmentación dinámica en 4 vídeos

Posted on 09/12/2015 by Alvaro

Crear Rutas:

Compartir Rutas:

Mostrar medidas:

Segmentación dinámica:

 

 

Posted in gvSIG Desktop, opinion, spanish | Tagged , , , , | 5 Comments

#11gvsig: Code Sprint, snapshots

Posted on 09/12/2015 by Alvaro

001 007 006 005 004 003

Posted in community, development, english, events, gvSIG Desktop, spanish | Tagged | Leave a comment