Quiero desarrollar cosas con la versión 2.0 de gvSIG ¿por dónde empiezo?

El otro día se me acercó un compañero a ver si podía orientarle sobre por dónde podía empezar si quería contribuir de alguna manera al desarrollo de gvSIG 2.0. Me quede pensando un momento y le pregunté….

¿Pero qué quieres hacer?

Después me di cuenta que él mismo no tenía muy claro realmente qué es lo que quería hacer. Quería empezar a hacer algo con la versión 2 de gvSIG pero no tenía nada claro aun el qué.

Hay bastante documentación sobre cómo desarrollar con y para la versión 2.0 de gvSIG, pero todos los que se acercan se plantean…

¿Por dónde empiezo?

En general al acercarse al desarrollo con o para la versión 2.0 de gvSIG podemos identificar tres escenarios:

  • Contribuir al núcleo de gvSIG
  • Contribuir a un proyecto que no forma parte del núcleo de gvSIG
  • Creación de plugins propios

Para simplificar aquí he utilizado el termino “núcleo de gvSIG” aunque realmente tendría que hablar del “workspace principal de gvSIG”, pero de momento nos quedaremos con lo de núcleo de gvSIG.

Lo primero que haría sería empezar por leer, y probablemente seguir, la Guía de inicio rápido del desarrollador y las Normas de codificación y desarrollo pero después según el escenario en que me encuentre lo mejor seria poder seguir con la documentación más adecuada para él.

Contribuir al núcleo de gvSIG

¿Qué quiere decir eso de “Contribuir al núcleo de gvSIG”?

Pues me refiero a cuando tengo o me gustaría realizar alguna mejora o corrección de algún bug de lo que serian los proyectos que forman parte del “workspace principal de gvSIG”. Si quiero aportarla al proyecto, tendré que poder probar que funciona y saber qué tengo que hacer para aportarla. Será interesante leer:

Después de leer esta documentación, probablemente estemos en condiciones de compilar el “núcleo de gvSIG” para poder introducir nuestras mejoras, y sabremos cómo hemos de hacer para que estas sean integradas en el núcleo para próximas revisiones.

Contribuir a un proyecto que no forma parte del núcleo de gvSIG

Lo primero que nos puede venir a la cabeza es la pregunta de que es eso de proyectos que no forman parte del núcleo de gvSIG… bueno… el workspace principal de gvSIG consta de una serie de proyectos que constituyen el núcleo sobre el que se monta toda la aplicación, pero no todos los plugins que se distribuyen con la aplicación están en este workspace. Cada vez más plugins tienen su propio proyecto independiente y su propio ciclo de vida. Con su grupo de desarrollo y criterios para aceptar nuevos desarrolladores o contribuciones, algunas veces más laxos que sobre el workspace principal. Algunos de esos plugins son:

  • Catalog
  • Gazetteer
  • ARC IMS
  • Oracle
  • Layout document
  • ECW
  • MrSID
  • WMS
  • WCS
  • Scripting

Algunos tienen ya su propio proyecto en la infraestructura de desarrollo de gvSIG y siguen una vida independiente del núcleo de gvSIG. Si estamos interesados en contribuir en alguno de ellos podemos consultar en la pagina infraestructura de desarrollo de gvSIG la ficha del proyecto y ponernos en contacto con alguno de sus responsables para gestionar con él la forma en que queremos desarrollar. Si no, siempre podemos trabajar como se describe en Contribuciones y parches al código de gvSIG.

Si vamos a ser desarrolladores de un proyecto puede ser interesante leer:

Ya comentado en el apartado anterior, y además:

Creación de plugins propios

Y por ultimo comentar esta parte… porque la creación de nuestros propios plugins y que estén disponibles para el resto de la comunidad de usuarios de gvSIG también es una forma de contribuir al proyecto.

Para este caso aconsejo sobre todo la Guía de inicio rápido del desarrollador, pero nos ayudará también leer algunos de los documentos comentados en los apartados anteriores como:

Y más específicamente nos vendrá bien leer:

  • Crear un proyecto para gvSIG de la Guía para desarrolladores de gvSIG 2.0.0
  • Proyectos oficiales en gvSIG que nos guiara sobre cuáles son las directrices para que nuestro desarrollo sea un proyecto oficial gvSIG. Recomiendo leerlo antes de abordar un desarrollo para la versión 2 de gvSIG, ya que aunque a priori no vayamos a solicitar que nuestro proyecto sea un proyecto oficial, hay bastantes cosas que son simples de seguir cuando vas a crear tu proyecto pero pueden ser muy costosas una vez ya esta confeccionado, así que merece la pena leerlo para intentar seguir las lineas que ahí se piden al inicio del desarrollo, aunque sea solo como buenas prácticas de desarrollo.

Para acabar

La documentación que he ido referenciando es documentación sobre cómo trabajar, pero no se trata de documentación de referencia sobre las librerías que conforman gvSIG. De esta hay menos, pero si alguien quiere leer algo puede encontrarla en el apartado de Documentación de desarrollo del proyecto gvSIG-desktop en la web http://www.gvsig.org . De ahí, por su especial relevancia es recomendable leer:

Y bien, para acabar estas letras, simplemente comentar que la documentación puede no estar todo lo completa que nos gustaría y que aunque la sigáis, podéis tener problemas, pero no os desaniméis, preguntar por las listas de desarrollo las dudas que tengáis o si tenéis algún problema para hacerlo por las listas no dudéis en escribir correo a los responsables de desarrollo de los proyectos con los que tengáis problemas.

¡Ah!, se me olvidaba, también podéis contribuir aportando documentación al proyecto, o traduciendo la existente a otros idiomas.

Hasta la próxima

Posted in community, development, gvSIG Desktop, spanish, technical collaborations | 6 Comments

Cómo crear la persistencia de DynClasses en gvSIG 2.0

En el post anterior, descubrimos cómo definir y hacer uso de los DynObjects en gvSIG 2.0, pero no se documento la forma de hacer que la información que en ellos se contiene fuera persistente.

En este punto, continuamos profundizando en este mecanismo, continuando por los pasos marcados para llevar a cabo este proceso.

Persistencia de los DynObjects

  • Deberemos definir los atributos del objeto que queremos persistir. En nuestro caso, se persisten los siguientes atributos:
    public static void registerPersistenceDefinition(){
      PersistenceManager manager = ToolsLocator.getPersistenceManager();
      DynStruct definition = manager.getDefinition("ChartProperties");
      if(definition == null){
        definition = manager.addDefinition(AbstractChartProperties.class, "ChartProperties" , "description", null , null);
        definition.addDynFieldString("name").setMandatory(false);
        definition.addDynFieldString("title").setMandatory(true);
        definition.addDynFieldString("type").setMandatory(true);
        definition.addDynFieldObject("service").setClassOfValue(ChartService.class);
      } 
    }

    En apariencia es similar, pero contiene las siguientes diferencias:

    • La primera es fundamental: se define la estructura en dos métodos diferentes, ya que no siempre todo lo que se maneja en el DynObject, se quiere persistir.
    • Por otro lado, en lugar de una DynClass, se obtiene un DynStruct (obtenido del PersistenceManager, en lugar del _DynObjectManager)
    • Los DynStruct se definen en el namespace“Persistent”, por lo que no hay que indicarlo a la hora de buscar definción
      ... = manager.getDefinition("ChartProperties");
      ...

      y cambia ligeramente a la hora de añadir la definición al Manager

      ...
      definition = manager.addDefinition(AbstractChartProperties.class, "ChartProperties" , "description", null , null);
      ...

    Este método de registro de la persistencia de la DynClass también deberá ser llamado desde la librería correspondiente después de la definición.

  • Despues tendremos que hacer que nuestra clase implemente el interfaz Persistent.
    public interface ChartProperties extends DynObject, Persistent
  • Esto nos añadirá un par de métodos a implementar, para guardar los datos y recuperarlos, respectivamente:
    public void saveToState(PersistentState state) throws PersistenceException;
    
    public void loadFromState(PersistentState state) throws PersistenceException;

    Estos métodos son los encargados de persistir y recuperar los atributos de nuestra clase. En nuestro caso, se persisten los siguientes atributos:

    public void saveToState(PersistentState state) throws PersistenceException {
      state.set("name", this.getChartName());
      state.set("type", this.getChartType());
      state.set("title", this.getChartTitle());
    }
    
    public void loadFromState(PersistentState state)
            throws PersistenceException {
      this.setChartName(state.getString("name"));
      this.setChartType(state.getString("type"));
      this.setChartTitle(state.getString("title"));
    }
    

Con todo esto, ya disponemos de las herramientas suficientes para poder manejarnos con los DynObjects en gvSIG y disfrutar de los beneficios que nos aportan.

¡Suerte y a por ellos! 😉

Posted in development, gvSIG Desktop, spanish | 1 Comment

Cómo crear una clase que ofrezca el interfaz DynObject

En el post anterior referente a los DynObjects, se hizo una pequeña explicación y motivación de su uso en distintos ámbitos de gvSIG. Este HowTo se presenta como un ejemplo en el que se pretende describir el proceso de definición y su uso.

Para apoyar la explicación, se tomará un ejemplo real sobre el que se citarán los pasos a seguir para que quede más ilustrado.

El modelo de objetos del ejemplo es bastante básico: partimos de un interfaz, que es implementado por una clase abstracta. Ésta última, a su vez, es extendida por más clases (se describirá sólo una, ya que el resto sería identíco para la definición de DynObjects), tal y como muestra la figura siguiente:

Definición de los DynObjects

Vamos a cumplimentar la definición básica de un DynObject:

  • Lo primero es que la clase que va a albergar los DynObjects debe extender la clase de mismo nombre.
    public interface ChartProperties extends DynObject
  • Esto nos genera una cantidad de métodos a implementar (en nuestro ejemplo, en la clase abstracta AbstractChartProperties).
    DynClass getDynClass();
    
    void implement(DynClass dynClass);
    
    void delegate(DynObject dynObject);
    
    Object getDynValue(String name)  throws DynFieldNotFoundException ;
    
    void setDynValue(String name, Object value)  throws DynFieldNotFoundException ;
    
    boolean hasDynValue(String name); 
    
    Object invokeDynMethod(String name, DynObject context) throws DynMethodException;
    
    Object invokeDynMethod(int code, DynObject context) throws DynMethodException;
    
    void clear();

    En nuestro caso, delegaremos en la implementación genérica, rellenando los métodos de la siguiente forma:

    • Definimos un DynObjectpor defecto que se creará en el constructor del objeto:
      protected DelegatedDynObject data;
      
      protected AbstractChartProperties(String definitionName){
        this.data = (DelegatedDynObject) 
          ToolsLocator.getDynObjectManager().createDynObject(definitionName, "Chart");
      }
    • Completamos la definición de los métodos delegando en su implementación genérica:
      public DynClass getDynClass() {
          return data.getDynClass();
      }
      
      public void implement(DynClass dynClass) {
          data.implement(dynClass);
      }
      
      public void delegate(DynObject dynObject) {
          data.delegate(dynObject);
      }
      
      public Object getDynValue(String name) throws DynFieldNotFoundException {
          return data.getDynValue(name);
      }
      
      public void setDynValue(String name, Object value)
              throws DynFieldNotFoundException {
          data.setDynValue(name, value);
      }
      
      public boolean hasDynValue(String name) {
          return data.hasDynValue(name);
      }
      
      public Object invokeDynMethod(String name, DynObject context)
              throws DynMethodException {
          return data.invokeDynMethod(name, context);
      }
      
      public Object invokeDynMethod(int code, DynObject context)
              throws DynMethodException {
          return data.invokeDynMethod(code, context);
      }
      
      public void clear() {
          data.clear();
      }
  • Ahora definimos la DynClass:
    public static void registerDefinition(){
      DynObjectManager manager = ToolsLocator.getDynObjectManager();
      DynClass definition = manager.get("Chart","ChartProperties");
      if(definition == null){
        definition = manager.createDynClass("Chart", "ChartProperties", "aquí va la descripción");
        definition.addDynFieldString("name").setMandatory(false);
        definition.addDynFieldString("title").setMandatory(true);
        definition.addDynFieldString("type").setMandatory(true);
        definition.addDynFieldObject("service").setClassOfValue(ChartService.class);
        manager.add(definition);
      }
    }

    Analizamos por partes los elementos más destacados de esta definición:

    • Como se puede ver, el método es estático:
      public static void registerDefinition(){
      ...

      el registro de la DynClass se debe hacer una única vez, cuando se carga la librería, por lo que se llamará a este método en el momento se haga el doInitialize() de la librería correspondiente.

      @Override
      protected void doInitialize() throws LibraryException {
        ...
        AbstractChartProperties.registerDefinition();
      }
    • Tras obtener el manager de los DynObjects, intentamos recuperar la definición de la DynClass (del namespace“Chart”, la DynClass de identificador “ChartProperties”). Si no existe, la creamos:
      DynObjectManager manager = ToolsLocator.getDynObjectManager();
      DynClass definition = manager.get("Chart","ChartProperties");
      if(definition == null){
        definition = manager.createDynClass("Chart", "ChartProperties", "aquí va la descripción");
           ...
        }
      ...
    • Por último, añadimos a la definición los atributos que compondrán la DynClass. La definición contiene los métodos para trabajar con los tipos básicos (String, Integer, Float, …):
      ...
      definition.addDynFieldString("name").setMandatory(false);
      definition.addDynFieldString("title").setMandatory(true);
      definition.addDynFieldString("type").setMandatory(true);
      ...

      en el caso de que se trabaje con otra clase más compleja, ésta deberá implementar la clase DynObject también, delegando su definición en ella misma.

      ...
      definition.addDynFieldObject("service").setClassOfValue(ChartService.class);
      ...
    • Una vez completa la definición, la añadimos al mánager:
      ... 
        manager.add(definition);
      }
  • Además, y esto ya más por comodidad, definiremos métodos de acceso get y seta los atributos:
    public void setChartType(String type) {
      data.setDynValue("type", type);
    }
    
    public String getChartType() {
      return (String) data.getDynValue("type");
    }

En el caso de querer ampliar esta definición a alguna de las clases que extienden a AbstractChartProperties para ampliar la definición del DynObject, los pasos a seguir serían:

  • Dado que se puede delegar en los métodos de la clase abstracta, la definición de los métodos típicos de DynObject no sería necesario volver a implementarlos.
  • Lo único necesario, sería aumentar la definición de la DynClass, en función de nuestras necesidades:
    public static void registerDefinition(){
      DynObjectManager manager = ToolsLocator.getDynObjectManager();
      DynClass definition = manager.get("Chart","BarsChart");
      if(definition == null){
          definition = manager.createDynClass("Chart", "BarsChart", "aquí va la descripción");
          definition.addDynFieldString("xValuesTitle").setMandatory(true);
          definition.addDynFieldString("yValuesTitle").setMandatory(true);
          definition.extend("Chart", "ChartProperties");
          manager.add(definition);
      }
    }

    El proceso es muy similar, salvo que se definen úncamente en la DynClass los parámetros añadidos respecto a la clase extendida, indicando que recoja el resto de la definición del padre a través de la instrucción:

    ...
      definition.extend("Chart", "ChartProperties");
    ...

    Este método también es estático y se carga una única vez cuando se carga la librería correspondiente.
    Nota: debido a que utiliza la definición de la clase AbstractChartProperties, hay que asegurarse que se carga después utilizando cualquiera de los métodos disponibles para la carga de librerías (poniendo el registro de la clase padre en el doInitilize() y las que dependen de él en el postInitialize(), o a través de fijar dependencias en el método doRegistration())

En el siguiente post, comentaremos cómo crear una clase que implementa el mecanismo de persistencia de gvSIG 2.0 basado en DynClasses.

Posted in development, gvSIG Desktop, spanish | 1 Comment

DynObjects en gvSIG 2.0

Hola,

vamos a hacer una introducción rápida a esta funcionalidad de gvSIG 2.0. Contaremos de forma rápida que son y después, en un par de artículos más intentaremos describir con un ejemplo dos usos de ellos.

En gvSIG se han introducido mecanismos para la definición de estructuras de datos dinámicas. Se tratan de estructuras de datos que se definen en tiempo de ejecución y nos permiten manejar datos con esa estructura sin que tengamos que saber exactamente cuál es esa estructura en tiempo de compilación. Sería algo parecido a manejar un Map para almacenar una estructura de datos en la que las claves son los nombres de los campos y el valor asociado a la clave su valor, pero con un valor añadido que nos permite consultar los tipos de los datos.

Para dar soporte a esto, a grandes rasgos, disponemos de los siguientes interfaces:

  • DynStruct. Contiene la definición de una estructura de datos. Qué atributos tiene la estructura, de qué tipos son, qué valores por defecto deben tener o qué restricciones se les deben aplicar a los atributos.
  • DynClass. Extiende a DynStruct añadiendo los mecanismos para definir operaciones o métodos asociados a la estructura de datos.
  • DynObject, que representaría a una instancia de un DynStruct o DynClass.
  • DynObjectManager, que nos hace de factoría para crear instancias de definición de estructuras (DynStruct y DynClass) o de las propias instancias de éstas (DynObject).

Para complementar a estos interfaces, hay implementaciones por defecto para cada uno de estos, de forma que podemos instanciarlas desde el DynObjectManager.

A este grupo funcional que aporta estas clases e interfaces es lo que genéricamente llamamos DynObjects.

Aunque el uso principal de los DynObjects es el de disponer de datos cuya estructura es dinámica y creada en tiempo de ejecución, en algunas partes de gvSIG se usa sólo para definir la estructura de datos propiamente dicha sin que luego se vaya a usar para almacenar éstos. Por ejemplo cuando definimos los metadatos de un objeto o cuando definimos qué atributos queremos que persistan de él. Tanto en un caso como en el otro se utiliza una definición de la estructura de datos para indicar qué metadatos tendrá el objeto o qué atributos de él serán persistidos, pero no para instanciar objetos con esa estructura.

Dada una definición de estructura de datos, podríamos crear una instancia de ellos mediante el DynObjectManager.

DynObjectManager manager = ToolsLocator.getDynObjectManager();
DynObject mydata = manager.createDynObject("MyStruct");

De esta forma tendré un DynObject que responderá a la estructura de datos definida con el nombre “MyStruct”. Este DynObject estará implementado por la clase por defecto para el manejo de DynObjects, pero es muy común que queramos disponer de nuestra propia implementación de nuestra estructura, usando los DynObjects como mecanismo para intercambiar estructuras de datos de las que no sabemos su definición en tiempo de compilación. En ese caso lo que haremos sera crear nuestra propia clase que implemente el interfaz DynObject, y proporcionar un manager o factoría para crear las instancias de éstos.

En los próximos dos artículos que continuaran a este veremos:

Espero que esto pueda servir para aclarar algunas ideas.

Un saludo

Joaquin del Cerro
Jose Badia

Posted in development, gvSIG Desktop, gvSIG development, spanish, technical collaborations | Leave a comment

Versión de desarrollo de gvSIG 1.12 lista para testear

Se ha publicado una nueva versión de desarrollo (build 1411) de gvSIG 1.12. Este será uno de los últimos builds antes de publicar la Release Candidate, por ello, queremos animar especialmente a toda la comunidad gvSIG a que la instale para probarla y testearla.

Se trata todavía de una versión no recomendable para su uso en producción, aunque no se ha detectado ningún error grave. Esta versión contiene ya todas las mejoras que podremos encontrar en la versión final de gvSIG-Desktop 1.12, que saldrá en las próximas semanas. Los instaladores para Linux y para Windows pueden obtenerse desde la página de descargas de gvSIG.

Las novedades que presenta esta versión 1.12 son:

  • Para los usuarios:
    • Se ha integrado la última versión de Sextante, 1.0.
    • Se ha incluído una nueva paleta de colores.
    • Se ha incrementado notablemente la usabilidad a la hora de organizar las capas en el TOC.
    • Mejoras generales de usabilidad (ventana de vista maximizada por defecto, colores aleatorios, etiquetado de tamaño y color fijo, abrir ficheros independientemente de su tipo, zoom con la rueda del ratón más amigable, ventana del localizador no modal, etc.).
    • Arreglos varios en el driver de Postgis (Simplificada la conexión a bases de datos, disminución de consumo de recursos en el servidor, soporte de fechas, etc.).
    • Mejoras e incremento del rendimiento en la unión de tablas y conexiones odbc.
    • Añadida la traducción al idioma Khmer.
    • Actualizado el acceso a datos para WMS 1.3 y la última versión de kml.
    • Mejoras varias en la carga de ráster, especialmente a la hora de capas pesadas.
    • Mejoras en la creación e impresión de mapas.
    • Soporte de simbología por intervalos para valores negativos.
    • En cuanto a Navtable, se ha mejorado la interfaz gráfica y los filtros rápidos.
  • Para los desarrolladores:
    • Se ha actualizado la librería jts a la versión 1.12.
    • Automatizado el proceso de generación de instaladores.
    • Uso de installjammer y launch4j.
    • Cambiada la API de la clase View.
    • La calculadora de expresiones puede usarse desde plugins externos.

Los errores encontrados pueden ser reportados en el tracker del proyecto o bien directamente a través de la lista de correo, usando un mensaje claro en el asunto del correo, como “bug en build 1411”.

En caso de que no aparezcan errores graves en el plazo de una semana se publicará la RC (versión candidata a final) y se iniciará un nuevo periodo de prueba por parte de la comunidad. Si los errores encontrado en la RC tampoco son graves se publicará la versión final.

Gracias por vuestra colaboración.

Posted in gvSIG development, spanish, testing | 2 Comments

Las 4as Jornadas de Latinoamérica y Caribe de gvSIG declaradas de Interés Ministerial por el Ministerio de Transportes y Obras Públicas de Uruguay

Con fecha 19 de abril de 2012, el Ministro de Transportes y Obras Públicas de Uruguay, Enrique Pintado, ha aprobado la resolución 2012/006/040 que otorga a las Cuartas Jornadas de Latinoamérica y Caribe de gvSIG y Segundas Jornadas Uruguayas de gvSIG [1] el rango de Interés Ministerial [2].

Estas 4as Jornadas se celebrarán del 24 al 28 de septiembre de 2012 en Montevideo (Uruguay), bajo el lema “Creciendo en Comunidad”, y tienen como objetivo proporcionar un lugar de encuentro donde los técnicos, investigadores, desarrolladores, expertos, y la comunidad en general, se reúnan en un entorno con debates en relación de la geomática libre y el Sistema de Información Geográfica de código abierto gvSIG. Para ello contará con diversos talleres, seminarios y ponencias.

[1] http://www.gvsig.org/web/community/events/jornadas-lac/2012/
[2] http://www.gvsig.org/web/community/events/jornadas-lac/2012/documentos/declaracion-interes_MTOP.pdf

Posted in community, events, spanish | Leave a comment

FOSS4G-CEE Conference in Prague

Last week (21.5-23.5.2012) took place in Prague, Czech Republic conference focused on free and open source called Free and Open Source Software for Geospatial in Central and East Europe (FOSS4G-CEE). The conference was co-organized by Faculty of Civil Engineering, Czech Technical University in Prague, so the venue was localized in university campus. The conference was focused on wide portfolio of free products, but in every case with some relationship to Central Europe. There was 60 papers, 6 workshops, 5 tutorials and 120 registered participants all over the world (CZ – 35, RO – 14, DE – 12, FR – 6, AT – 5, SK – 4, EE, HU, CH, PL, TU, USA – 3, IT, UK – 2, HR, NRW, NZ, Georgia, Ghana, Nigeria 1).

The program was divided into 3 main parts. On Sunday and Monday morning there were practice workshops, on Monday afternoon there was plenary session, where keynote speakers presented their papers. It was very interesting to see Arnulf Christl (OSGeo president), Markus Neteler (OSGeo founding-member) or Athina Trakas (OGC Director for European Services). In next two days presenters presented their papers in three parallel sections.

One of the presentations was focused on gvSIG topic as well. Rostislav Nétek talked about Influence of e-learning and Open Source solutions for education at Palacký University in Olomouc inspired by Polytechnic University in Valencia (see an abstract).

 

He talked about different approaches in education between Western and Eastern Europe. It is based on case study, which compares universities conventions between Spain and Czech Republic, focused on eLearning and open source sources. The author, originally from Palacký University in Olomouc, Czech Republic spent two internships at Polytechnic University in Valencia, where he met gvSIG for the first time and visited gvSIG lessons of Jesús Palomar Vázquez. He was surprised by fact that in Eastern Europe free solutions and eLearning was deeply implemented into education at universities compared to situation in Czech Republic. So now the author is responsible for gvSIG class at Palacký University. Due to fact that open source is little bit repressed in Czech education, inspired by situation at UPV he put great emphasis on self education and videotutorials for learning with gvSIG programme. After presentation there was quite long discussion about it, especially with one of keynote speaker Helena Mitasova (North Carolina State University), which confirmed that it is very important to increase awareness about software like gvSIG among students in Europe as well in USA. Moreover the discussion about it continued in the foyer.

Generally, FOSS4G-CEE was really great conference, with strong impact of knowledge and experiences about open source solutions. It was agreed, that, FOSS4G-CEE 2013 will be organized by Vasile Crăciunescu and his team at geo-spatial.org in Bucharest, Romania.

Posted in community, english, events, opinion | Tagged , , , | 1 Comment

1as Jornadas Chilenas de gvSIG: “Abriendo Horizontes”

Los días 21 y 22 de junio de 2012 se celebrarán las 1as Jornadas Chilenas de gvSIG [1], en la Facultad de Ingeniería de la Universidad Mayor (Santiago de Chile), bajo el lema “Abriendo Horizontes”.

Este evento representa la primera reunión tanto de usuarios, con conocimientos básicos, medios y avanzados, como también de desarrolladores de gvSIG formalmente organizada en Chile.

El objetivo es congregar y fortalecer a la comunidad gvSIG, así como difundir el uso de esta herramienta, que junto a otras de uso libre, han contribuido al acercamiento de la información geográfica a la ciudadanía en general. Esperamos que sirva como punto de encuentro para la comunidad ligada a su uso, y se genere un ámbito donde intercambiar ideas, compartir conocimientos y favorecer sinergias que beneficien a todos.

Ya está abierto el periodo para el envío de propuestas para comunicaciones para las Jornadas. Desde hoy pueden enviarse las propuestas de comunicación a la dirección de correo electrónico jornadas.chile@foss4gchile.org, que serán valoradas por el comité científico de cara a su inclusión en el programa de las Jornadas. Toda la información sobre las normas para la presentación de comunicaciones puede consultarse en el apartado de Comunicaciones de la web [2]. El periodo de recepción de resúmenes finalizará el próximo 12 de junio.

Mañana día 30 de mayo se abrirá el periodo de inscripción. Estas jornadas son gratuitas.

[1] http://www.gvsig.org/web/community/events/jornadas-chile/2012
[2] http://www.gvsig.org/web/community/events/jornadas-chile/2012/Comunicaciones

Posted in community, events, spanish | Leave a comment

About 1st gvSIG Russian meeting

Hi! this is a translation from the Russian blog.
Bye,
Viqui-.

The 1st Russian gvSIG Meeting started its work in the Lipetsk State Pedagogical University, Russia, on Monday 14th May. The first activity of the Meeting was the gvSIG workshop which was attended by 14 specialists from six cities of the Russian Federation. Participants represented 10 different organizations, including a number of universities from Lipetsk, Smolensk, Orel, Moscow, Institute of Geography, Department of the Administration of the Lipetsk region, as well as business enterprises from the Lipetsk and Tambov regions.

The venue of the workshop was given by the Center for Free Software of the LSPU (the Head – Vladimir Kalitvin, Ph.D., Associate Professor). The workshop was opened by Lyubov Belyaeva, the Head of the Department of Geography. A brief story about the gvSIG project was made by the coordinator of the Russian gvSIG Community Serguei Mikhailov.

The workshop was led by the lecturer and coordinator of the Russian gvSIG Community Alexander Karandeev from the Department of Geography of the Lipetsk State Pedagogical University.

Workshop participants received a set of teaching materials, including textbook, “Geographic Information Systems. Basic Course. Workshop “, prepared by Alexander Karandeev and Serguei Mikhailov. The exercises were focused on gvSIG Desktop 1.11 and other open source software products.

The workshop organizers are grateful to the Organizing Committee of the International Conference “Fifth Semenov’s Reading: Legacy of the P.P. Semenov-Tyan-Shansky and modern science” dedicated to 185th anniversary of P.P. Semenov-Tyan-Shansky, also to the Center for Free Software of the LSPU, Alkis LLC [1] and of NPO “GISIT” [2] for their help in organizing and conducting the gvSIG workshop.

[1] http://www.maplip.ru/
[2] http://npogisit.ru/

The reports of participants of the Fifth Semenov’s Readings and the 1st Russian gvSIG Meeting were presented on the 15th May. The plenary session was opened by the President of the Lipetsk State Pedagogical University Pavel Bugakov.

After greetings from the representatives of the Public Administration of the Lipetsk Region and the territorial authority of the Federal State Statistics Service of the Lipetsk Region, the conference continued with a report on the role of P.P. Semenov-Tyan-Shansky in the  reform of 1861 that was made by the chairman of the “Semenov’s Charity Society (the society of descendants of P.P. Semenov-Tyan-Shansky, Saint-Petersburg)” Alexander Semenov-Tyan-Shansky.

As part of the 1st gvSIG Users Meeting in Russia, there was the report about The gvSIG Project (Authors: V. Agazzi, G. Carrion, M. Madrid from the gvSIG Association) at the plenary session. On behalf of the authors the presentation was performed by the coordinator of the Russian gvSIG Community Serguei Mikhailov.

In the afternoon there were session meetings, being one of them the session devoted to the 1st Russian gvSIG Meeting. One report about Cartographic Information ALKIS web-service based on the OpenSource products was made by Vladimir Egorov, General Director of Alkis LLC, Lipetsk.
Another report was based on the usage of gvSIG for the protection of cultural heritage of the Lipetsk Region told by Serguei Mikhailov (NPO “GISIT”, Lipetsk).

Polemical, but funny, was the report by Maxim Dubinin (@gislab), General Director of NextGIS LLC, Moscow. His presentation can be found at [1]. The final slide of the presentation was accompanied by the applause of the audience.
The day ended with an evening stroll along the Lipetsk streets and discussing the various issues of development and use of GIS open source software.

The final day of the Fifth Semenov’s Readings was on May 16th, where participants visited the family estate of Semenov-Tyan-Shansky in the village Ryazanka, Chaplyginsky district of the Lipetsk Region. Participants also visited the Museum of Local History of Chaplygin Town.

Once the conference passed, we would like to thank everyone who was involved in its organization and support, especially the staff of the Department of Geography of the Lipetsk State Pedagogical University under the direction of the Head of Department Lyubov Belyaeva.

[1] http://gis-lab.info/blog/2012-05/gvsig-1/

Posted in opinion | Leave a comment

Nuevo soporte adicional de gestión de CRS para gvSIG 2.0

En las primeras versiones de gvSIG se desarrolló un soporte de CRS (Sistema de coordenadas de referencia) con una funcionalidad y soporte de definiciones básico. Esta implementación permite al usuario seleccionar el sistema de referencia en base al datum, la proyección y el huso.

CRS selection in the gvSIG basic CRS support

Sin embargo tiene algunas limitaciones a la hora de realizar transformaciones, además de no soportar, por ejemplo, los husos del hemisferio sur.

A continuación se desarrolló una nueva versión basada en las librerías geotools y Proj4, con muchas más funcionalidades, definiciones de CRS, incluso con la opción de permitir al usuario a creación de sus propios CRS.

CRS selection in the gvSIG proj4 based CRS support

Sin embargo el nuevo soporte presenta dos problemas:

  • Mientras que gvSIG está desarrollado en lenguaje java, permitiendo su ejecución en multitud de plataformas, al usar Proj4 que es una librería nativa se ha perdido esa independencia de plataforma. Aunque Proj4 está disponible en múltiples arquitecturas y sistemas operativos, obliga a gvSIG a generar instalables distintos para cada uno de ellos. Todo ello aumenta la complejidad y el mantenimiento de gvSIG.
  • El nuevo soporte emplea una base de datos local para la consulta CRS soportados, además de requerir la instalación de la librería Proj4, junto con sus dependencias. Esto implica unas necesidades de recursos (memoria y disco duro) mayores que en el soporte previo.

Recientemente además la Asociación gvSIG ha desarrollado un nuevo proyecto enfocado a entornos educativos: gvSIG Educa. Dentro de dicho proyecto se incluye gvSIG Batoví, que es la distribución que da origen a gvSIG Educa. Esta distribución está impulsada por el Ministerio de Transporte y Obras Públicas (MTOP) de la República Oriental del Uruguay y desarrollada por la Asociación gvSIG y la Facultad de Ingeniería de la Universidad de la República (UdelaR), y está enfocada al uso de un Sistema de Información Geográfica en entornos educativos con destino al PlanCeibal (Uruguay)

Se trata de una distribución de gvSIG desktop 2.0 para ser instalada en ordenadores OLPC. Dichos ordenadores tienen unos recursos limitados, por lo que no es viable el uso del soporte de CRS basado en Proj4. Por otro lado el uso del soporte básico no es posible, al carecer de soporte para los husos del hemisferio sur.

Como alternativa se ha desarrollado un nuevo soporte de CRS, empleando para ello la librería Proj4J, que es una implementación parcial de Proj4 en lenguaje Java, por lo que es independiente del sistema en el que se instale gvSIG.

Funcionalmente permite elegir el CRS en base a la autoridad y código, aportando soporte para gran número de definiciones.

CRS selection in the gvSIG proj4j based CRS support

Este nuevo soporte se incluirá de base en las distribuciones de gvSIG Batoví, además de estar disponible para ser instalada en gvSIG desktop 2.0 a través del gestor de complementos.

En gvSIG desktop 2.0 estarán disponibles inicialmente las 3 implementaciones de soporte de CRS. La básica va de base con gvSIG, y las otras dos se pueden instalar como complementos. En el caso de instalar las tres, la activa será la basada en Proj4. Sino está instalada ésta, entonces se activará la basada en Proj4J.

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