Esto es lo que significa cloud en zonas en desarrollo. #siglibre7 #firstworldproblems

Otra gran cuestión que se ha levantado en estas jornadas ha sido, de la mano de Malcolm Bain, cuales son los límites legales de los servicios de almacenamiento de datos en la nube, qué podemos esperar y exigir y hasta qué punto, desde la perspectiva del proveedor de servicios, tenemos que ofrecer un mínimo de nivel de servicio. Resulta sin duda sorprendente aprender que algunos de los contratos que aceptamos en servicios muy conocidos (como correo electrónico web o hosting) son, sencillamente, ilegales.

La batalla del software libre ya está ganada, ahora queda la batalla de la libertad y privacidad de los datos.

También ha resultado una delicia ver el enfrentamiento dialéctico entre varios de los ponentes, como cuando Javier de la Torre (Cartodb) arremetió contra OGC o las IDE. Sin duda un tema que, aunque no coincido completamente con su opinión, es algo a debatir y mejorar. ¿Deberían intentar los IDE hacerse más amigables para acercarse al usuario o es suficiente con ser un repositorio de datos?

El jueves por la tarde, Geocat tuvo sesión doble entre varias charlas muy centradas en los metadatos y su importancia en los IDE. Primero presentamos rápidamente quiénes éramos y qué hacíamos, centrándonos sobre todo en GeoNetwork y Bridge, mencionando también nuestro futuro GeoCat Live. Y justo antes de terminar el día, un taller de 30 minutos para presentar GeoNetwork, justo antes de dar paso a la primera reunión de geoinquietos nacionales.

Es difícil resumir en un sólo artículo toda la tremenda dimensión alcanzada en estas jornadas. Mucho optimismo, muchas ganas de seguir trabajando y, sobre todo, la certeza de que estamos en el camino correcto, apoyando el software y los datos libres, centrándonos en la parte social de nuestro trabajo. El viernes, casi para finalizar, Javier Sánchez orientó la recta final de las jornadas hacia este tema, hablando de las empresas sociales, las cuales no sólo tienen una cuenta de resultados económica sino también social.

En resumen, las Jornadas SIG Libre Girona son sin duda el Evento SIG(en mayúsculas) que cualquier hispano hablante debería tener en cuenta si quiere estar al día de las últimas novedades.

Se despliega sobre un contenedor de aplicaciones java (como tomcat o jetty), funcionando sobre el framework Jeeves. Jeeves se basa en transformaciones XSLT que permiten un desarrollo rápido y sencillo (a la vez que potente) de interfaces tanto para un usuario como para máquinas (XML).  Esto hace que los datos en GeoNetwork sean fácilmente accesibles por diferentes plataformas.

Mis principales motivaciones para dejar de trabajar en Emergya, a pesar de la enorme calidad humana y técnica que tiene, fueron tres:

• La coyuntura actual en la que se debate España ahora mismo impide en gran medida poder realizar proyectos interesantes, forzando a las empresas a centrarse únicamente en sobrevivir, con todos los roces e incomodidades que esto genera.
• El reto. Y esta, creo que es la motivación principal. El enorme reto que supone el cambio de contexto a una nueva empresa, con una forma de trabajar tan parecida y a la vez tan diferente. Necesitaba ver mundo, aprender, beber de otras fuentes. Cinco años en Emergya son maravillosos, pero empezaba a sentir que se me estaba quedando pequeña. ¿Pez grande en lago pequeño o pez pequeño en el mar?
• GeoGatos¿Alguien podría rechazar la posibilidad de convertirse en un geo-gato? ¿Puede haber un paso más allá de esto? ¿Se puede no querer trabajar con metagatos?

Por supuesto que no ha sido una decisión fácil. Para mi Emergya es, y siempre será, esa empresa que me acogió con todo el cariño del mundo y me ayudó a dar mis primeros pasos en el mundo laboral, fortaleciendo mi convencimiento de que el software libre es el camino correcto. Lo quiera o no, Emergya forma parte de mi y el título de “ex-emergyana” ya no me lo quita nadie. Espero no olvidarme nunca del camino de vuelta a la gatera.

Pero era una paso que tenía que dar. Así que me lancé a la piscina, y tras una semana de toma de contacto, ya no tengo ninguna duda de que ha sido la decisión correcta. GeoCat tiene un equipo de trabajo impresionante y acogedor y su línea de desarrollo es realmente fascinante. Así que supongo que a partir de ahora me escucharéis menos de cálculo de rutas y más de metadatos e interoperabilidad (que no quiere decir que vaya a abandonar el routing, por supuesto, una tiene su corazoncito). Próxima parada: GeoNetwork.

Sin embargo, lo más sorprendente de todo es que este proyecto ha salido de la mente de un joven informático canario, Luis Falcón. Y es que muchas veces no tenemos que buscar lejos para encontrar talento capaz de cambiar el mundo.

Por ejemplo, si queremos que nos avise con un print cada vez que ejecutemos ciertas funciones, no tenemos más que definir una interfaz que imprima el log que queremos antes de ejecutar la función:

from functools import wraps
def log(func):
 @wraps(func)
 def log_func(*args, **kwargs):
  print "log"
  return func(*args, **kwargs)
 return log_func
@log
def func1():
 print "Ejecutando funcion uno"
@log
def func2():
 print "Ejecutando funcion uno"
func1()
func2()

Este código devolvería el siguiente resultado:

log
Ejecutando función uno
log
Ejecutando función dos

También podemos usar las anotaciones para cosas más útiles, como indicar a python que cierta función se va a ejecutar en modo asíncrono en un hilo diferente:

from multiprocessing import process
def run_async(func):
 @wraps(func)
 def async_func(*args, **kwargs):
 func_hl = Process(target = func, args = args, kwargs = kwargs)
 func_hl.start()
 return func_hl
 return async_func
@run_async
 def process():
 print "Ejecutado en asíncrono"

Las anotaciones pueden ser de tres tipos, según el momento en el que son visibles:

Información para el Compilador

Estas anotaciones permiten al compilador indicar si debe o no omitir errores y warnings o qué hacer con ellos. A nada que se haya trabajado con un IDE Java (como eclipse) se habrán utilizado este tipo de anotaciones de forma natural, por ejemplo usando @Override sobre una función para indicar que está sobreescribiendo una declaración definida en una clase padre. Esta anotación es completamente opcional,  pero permite tanto al compilador como al desarrollador comprobar que efectivamente se está sobreescribiendo una funcionalidad existente por herencia.

Por ejemplo:

public class Padre {     
    public void do(){
        System.out.println("Padre");
     }
}

public class Hijo extends Padre{     
    @Override
    public void do(){
        System.out.println("Hijo");
     }
}

Anotaciones en Tiempo de Compilación y Despliegue

Estas anotaciones permiten añadir información extra al compilador para que modifique la forma en la que se genera el código de los ficheros .class. Puede servir para modificar clases (añadiendo o modificando funcionalidad respecto a lo descrito en el código fuente), generar clases nuevas (por ejemplo en base a un fichero descriptor), etc…

Estas anotaciones sólo serán visibles en este punto, es decir, no se escribirán sobre los .class y por tanto no se podrán consultar en tiempo de ejecución.

Anotaciones en Tiempo de Ejecución

Estas anotaciones pueden ser consultadas en tiempo de ejecución y funcionan de forma muy parecida a como se utilizaría una interfaz.

Veamos directamente un ejemplo de cómo crear una anotación Runtime y cómo se puede utilizar. La anotación MyAnnotation se podrá aplicar a elementos de tipo field, es decir, a atributos de una clase:

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
     public @interface MyAnnotation {
}

Ahora podemos crear una clase que esté anotada con esta anotación:

public class myObject
 {
 @MyAnnotation
 public String field;
 }

De esta forma, en cualquier otra parte del código, podemos comprobar mediante reflexión si un objeto tiene un campo marcado con la anotación:

Class<?> res = objeto.getClass();
for (Field f : res.getFields()) {
     if (f.isAnnotationPresent(MyAnnotation.class)) {
          System.out.println("OK");
      }
}

Más información:

• Tutorial de Oracle
• Tutorial de Metadatos
• Ejemplo Práctico

Es fundamental cambiar la configuración geoserver_data_dir en el fichero web.xml para no perder los datos cada vez que se reinicia el contenedor de aplicaciones (como Tomcat). Así mismo, es bueno echarle un vistazo al resto de configuraciones ya que contiene datos interesantes como el tipo de proyecciones que se van a utilizar o el tamaño de la caché. Hay datos configurables “on the fly” y datos no configurables sobre la marcha.

Vamos a probar a añadir algunas fuentes de datos para generar las capas. Para agregar un shapefile, tienes que copiar el fichero del shape en la misma máquina física del servidor. Para incluir el shapefile en el geoserver, hay que buscar la opción de añadir un nuevo datastore de tipo shapefile. Si se utiliza la localización del tipo “file:data/…” es una uri relativa al geoserver. También se puede buscar con el botón “Browse” y se utilizarán rutas absolutas.

Cuidado: No debes dar permiso a cualquiera para la interfaz de configuración porque pueden ver todo el disco duro físico en este tipo de cuadro de diálogo.

Lo mejor es utilizar memory mapped buffers (salvo que uses Windows) si tienes suficiente memoria RAM, ya que evitarás contínuos accesos físicos a disco. Así mismo, lo mejor es reproyectar desde el EPSG nativo al declarado. Si el shapefile es muy grande, calcular el bounding box tardará bastante. Esto no pasa en bases de datos reales donde hay índices espaciales.

GeoServer te permite introducir marcas de agua en tus datos (por ejemplo para usar OpenStreetMap).

Cuando se usan conexiones a bases de datos, marcar la opción de validar la conexión, porque nunca sabes cuándo va a petar la conexión.

GeoWebCache permite en las últimas versiones de Geoserver, administrar cómodamente qué capas se cachean.

Se pueden poner datos que varíen según el tiempo, por ejemplo para tornados o tormentas. En la tabla de la base de datos habrá una columna indicando el tiempo. También se pueden poner datos con elevaciones. Pero todo esto hay que hacerlo con Google Earth. Lo interesante es que se sirven los datos, luego algún visor libre que lo soporte podría ser interesante…

Pre-requisitos:

• Java
• Eclipse
• Ant (preferiblemente)
• Maven (preferiblemente)
• gvSIG (esto es recursivo )

La principal ventaja de gvSIG 2.0 es que puedes crear un plugin sin saber cómo funciona gvSIG ni tener que compilarlo. Tenemos una instalación de gvSIG que despliega unos binarios que genera el workspace. Pero no tenemos que tocar los fuentes de gvSIG, salvo que algo no funcione (bugs) o haya que añadir alguna funcionalidad al núcleo. Preferentemente no lo toques, mejor consulta con los desarrolladores del núcleo de gvSIG y ellos intentarán encargarse.

Con el binario de gvSIG viene un asistente para ejecutarlo y que cree un workspace de eclipse con una plantilla prefijada que deja todo configurado para compilar nuestra extensión. También incorpora un asistente para generar instalables fácilmente. Estos asistentes son accesibles mediante la aplicación gvSIG, en el menú de la aplicación.

La librería org.gvsig.tools es la infraestructura básica para desarrollar plugins. La principal funcionalidad se centra en registro de puntos de extensión, utilidades para separar API, implementaciones y SPI (proveedor de servicios), así como monitorización de tareas (que en la versión 1.0 solía congelar la aplicación). Esta librería también soporta eventos, persistencia, etc…

Una librería es un jar. Cuando nuestra aplicación levante el jar, org.gvsig.tools prepara dicha librería y la inicializa dentro del core de gvSIG. Las clases dentro de la librería implementan la interfaz Library (AbstractLibrary).

Los managers (PluginsManager) son el punto de entrada a las funcionalidades. Son como factorías (singletons) (al menos uno por librería) que levanta instancias de las funcionalidades incluídas dentro de la librería. También guarda la configuración del módulo.

Los locators (PluginsLocator) permiten registrar implementaciones de managers. Nos permiten recuperar la implementación de manager de un API en concreto. “Dame el manager de esta librería.”

Un plugin es una pieza que aporta una funcionalidad: botones y barras de herramientas, opciones de menús, proveedores de datos y tipos de documentos. Andami no ha evolucionado demasiado desde la versión gvSIG 1.x. Andami es el framework de los plugins.

El plugin siempre tendrá al menos dos ficheros:

• config.xml que indica las clases que implementan el plugin, las dependencias y los menús
• package.info que indica la versión, el nombre, el build,… del plugin.

Una extensión (IExtension) es un conjunto de herramientas asociadas a un plugin metidas en una barra de herramientas o menú y funcionan de forma conjunta. Un grupo de plugins, vaya. La extensión que implemente ExclusiveUIExtension especifica qué herramientas están o no visibles en cada momento, sin tener que tocar código en el core de gvSIG.

Para crear un nuevo plugin, hacemos uso de la herramienta del menú de generación de plugins disponible en la versión de desarrollo de gvSIG. Esto genera el workspace automáticamente e instala dicho plugin en el gvSIG desde el que hemos generado el plugin. Si no tienes versión de desarrollo, tendrás que compilar gvSIG de los fuentes.

Conviene ir haciéndolo mientras se leen estos apuntes o puedes perderte.

El plugin constará de dos proyectos maven: org.gvsig.plugin y org.gvsig.plugin.app. org.gvsig.plugin aportará la funcionalidad de la librería de forma independiente de gvSIG (la lógica de negocio). Puede tener dependencias de librerías de gvSIG, pero debería poder funcionar sin tener que abrir la aplicación. Es decir, no requiere nada de Andami, por ejemplo. En org.gvsig.plugin.app.mainplugin (dentro de org.gvsig.plugin.app) tendrá la implementación de dicha funcionalidad dentro de gvSIG.

Lo suyo sería que los paquetes que ponen “api” contengan interfaces y que los paquetes que contienen “impl” tengan clases con la funcionalidad.

En principio el workspace está preparado para trabajar con eclipse e importar los proyectos con el plugin de maven. Si hemos cogido una plantilla adecuada al generar los fuentes del plugin, tendremos prácticamente todo el trabajo hecho (salvo la lógica de negocio exacta de nuestro plugin).

Es importante hacerse un proyecto java para probar nuestro plugin, con su propio main, sin tener que arrancar gvSIG. Así mismo se recomienda que en la parte de librería haya tests unitarios. Es decir, podemos hacer una aplicación con toda la potencia de gvSIG, pero sin utilizar gvSIG en sí, es decir, como si gvSIG fuera una potente librería gis. Conclusión: si lo hacemos bien, podríamos incluso utilizar nuestro plugin de gvSIG en otra aplicación… como Gofleet.

Cada plugin tiene su propio instalador, que también se genera con un asistente dentro de la aplicación gvSIG.

Aunque se puede encontrar una guía más completa en la documentación oficial, estos sencillos pasos te permitirán personalizar y compilar tu propia versión de gvSIG 2.0 sin muchos problemas.

Lo primero, instalar ciertas dependencias básicas:

#apt-get install maven2 subversion

A continuación, creamos un directorio sobre el que trabajar.

$mkdir gvSIG; cd gvSIG

Una vez tenemos el directorio de trabajo, descargamos los fuentes
básicos para preparar el entorno:

$svn co https://joinup.ec.europa.eu/svn/gvsig-desktop/branches/v2_0_0_prep/build/

Antes de compilar nada, preparamos un fichero de configuración básica.

$ cat > ~/.gvsig.platform.properties << EOF
native_platform=linux
native_distribution=all
native_compiler=gcc4
native_arch=i386
native_libraryType=dynamic
export native_classifier=\${native_platform}-\${native_distribution}-\${native_compiler}-\${native_arch}-\${native_libraryType}
EOF


El siguiente código puede meterse en el fichero .bashrc del /home del
usuario, pero también podemos ejecutarlo directamente sobre la consola
que estamos trabajando:

$if [ -f "${HOME}/.gvsig.platform.properties" ]
then
. ${HOME}/.gvsig.platform.properties
export MAVEN_OPTS="-Xmx256M -XX:MaxPermSize=64m -Dnative-classifier=${native_classifier} -Dnative-platform=${native_platform}"
else
export MAVEN_OPTS="-Xmx256M -XX:MaxPermSize=64m"
fi

Una vez tenemos el entorno preparado, hacemos la primera compilación
con maven. Paciencia, puede tardar.

$mvn install

Y ahora que hemos hecho la primera compilación con maven, procedemos a
usar ant para terminar de preparar todo el entorno. Este comando
accederá al repositorio online de gvSIG para descargar el resto de
fuentes y compilará y generará el gvSIG.

$ant svn.checkout.all

Una vez tenemos el entorno listo, procedemos a preparar la aplicación
gvSIG que vamos a utilizar. En este ejemplo usaremos la instalación
típica de gvSIG:

$cd projects/gvsig-standard
$ant svn.checkout.all

Paciencia, mucha paciencia.

$mvn install

Y ya está. La aplicación gvSIG aparece en la carpeta products. Para
ejecutarlo, ejecutamos el fichero gvSIG.sh.

Si al intentar arrancarlo aparece como error “command java not found”
habrá que especificcar la variable JAVA_HOME:

$export JAVA_HOME=/usr/lib/jvm...

Y ya puedes utilizar tu propia versión compilada de gvSIG.

Próximamente hablaré sobre cómo crear plugins para gvSIG 2.0.