After 4 months of work Google Summer of Code has finished. I'm really happy with the final results. Fernando finally finished all the tasks scheduled and the first tests I've made with the code he has written look promising. After all there's some work left for both of us. While he is going to contribute gvSIG Desktop with the GPX provider and some patches to the GPE library. I'm going to integrate all his work for the next release of gvSIG Mini, so it will be able to load local vector data; a great feature in my opinion.

All the documentation written during this summer can be found at the project wiki. The source code at the Subversion repository. And these are some preview snapshots of the project:

Regarding my own impressions about this summer I have to say I'm really satisfied with the experience. My personal motivation since the beginning was continue working for gvSIG Mini and try to join others to work also for it, so that goal has been fully acomplished. On the other hand, being a mentor there's also a path to learn. During this summer I've learned to teach others in topics that were unknown for them, to manage and track their tasks. I've learned also a bit of Kanban and of course I've coded a lot.

Apart from this, the very real motivation was to give my father the GSoC t-shirt :P

In the end a great experience I hope I could repeat following years.

Queda poco más de una semana para que empiece el combo de eventos geoespaciales del año, en decir, por primera vez se concatenan el congreso anual de OpenStreetMap, conocido como The State of The Map, y el FOSS4G, el congreso nacional de la Fundación OSGeo.

Este año acudiré yo en representación de Prodevelop. En el primer evento no tendremos participación activa al menos a priori porque en estos eventos uno nunca sabe del todo qué se va a encontrar, y en el segundo caso sí que daré tres charlas. En medio además participaré en el encuentro de partners de OpenGeo, presentando a Prodevelop y en general viendo qué tienen pensado en OpenGeo para su OpenGeo Suite para los próximos meses.

El FOSS4G es desde luego mi evento geoespacial favorito por su dimensión, cantidad y calidad de contenidos, por los talleres, por volver a ver a gente con la que no se tiene la oportunidad de conversar en persona en todo el año, y en general por concentrar una alta cantidad de conocimiento y diversión en un muy corto espacio de tiempo. Como se suele decir, viene a ser como hacer un master en poco más de cinco días.

Respecto a las charlas en concreto contaremos:

• Desarrollos en gvSIG Desktop para acceder a datos raster almacenados en la base de datos Postgres
• Desarrollo del soporte en gvSIG mini para almacenar, gestionar y visualizar cantidades elevadas de puntos de interés
• Integración de orígenes heterogéneos de puntos de interés en OpenLayers, concretamente datos provenientes de redes sociales y servicios que exponen APIs con parametrización geográfica.

Queda bastante (todo) por preparar así que se me viene una semanita intensa, de seguro el viaje va a ser muy cansado, pero así y todo la experiencia es siempre reconfortante profesional y personalmente así que de seguro tendré cosas que contar durante el evento (supongo que le daré duro al twitter) y a la vuelta por estos lares.

Ya lo comenté en el blog de OSGeo.es pero lo repito, si lees esto y vas a estar por el FOSS4G y me ves, no dudes en saludarme, aunque no seremos pocos los hispanohablantes por el congreso, escuchar un poco la lengua materna será de agradecer.

Today I had to perform some raster data management for my colleagues and ended up with a little bit o CLI kung-fu with GDAL utilities. By the way I want to share them also as a reminder for the next time :-) I had a number of Arc/Info ASCII Grid files to convert, merge and finally transform to serve them on a WMS service.

First, convert all of them from agr to tiff (execute it all in one line)

find . -name "*.agr" -exec bash -c 
'file={};i=${file%.*};
 gdal_translate -of GTiff -co "TILED=YES" $file $i.tiff ' \;

Then merge all of them (see the acutes to execute ls and expand the list of files):

gdal_merge.py -o 31.tiff `ls *.tiff`;

And finally an easy transform from UTM31N (ETRS89) to Lat/Lon (ETRS89)

gdalwarp -s_srs EPSG:25831 -t_srs EPSG:4258 31.tiff 4258.tiff

I know this is pretty basic stuff, but not everybody knows how to combine good CLI programs like find to avoid some extra executions.

I thought that tweeting "I'm having lunch @ somewhere" was as narcissist as one can get, but I was totally wrong:

El diario El País ha publicado los resultados de las elecciones municipales y autonómicas del 22 de mayo de 2011 en formato XML, de modo que la URL de cada archivo XML utiliza los códigos INE de cada municipio. Por ejemplo, el código INE de Sevilla es 41091, por tanto la URL del XML con los resultados de Sevilla es:

http://resultados.elpais.com/elecciones/2011/municipales/01/41/91.xml2

El 01 es el código asociado a Andalucía. Este es el aspecto del archivo XML:

Por otro lado en la web del IGN se puede descargar un shapefile de centroides o polígonos de cada municipio y una de los atributos de cada elemento es precisamente el código INE.

A lot of info about the recent 4th Italian gvSIG conference (Quarte Giornate italiane di gvSIG) held in Udine can be found here, here and here.

I'm going to add a couple notes about things that came up during this event regarding gvSIG Mobile.

Field-oriented features

I had the pleasure of meeting Giuliano Gallerini who works for Leica Geosystems in Italy. According to him, gvSIG Mobile looks too much like a simplified version of gvSIG desktop and does not include some very interesting features that make sense only when you are doing some field work with a hand-held device. These are the two examples he seemed to be especially interested in, which obviously need the help of some additional hardware, for example, this one.

Shifted acquisition of points

The acquired points are shifted by a certain value (entered by the user when the operation starts) in order to overcome some physical obstacle:

Simple triangulation

In this case, the user has to measure the three sides of a triangle, where one of the vertices is unreachable. There are two possible values for the third vertex. The good one is the one that lies behind the obstacle:

SQLite and Spatialite

Alessandro Furieri presented Spatialite and asked when gvSIG will support it. I mentioned a funny pure Java version of SQLite and he replied he knew it but it was very slow and did not recommend it at all. I have just found a second pure Java version of it.

I still believe these pure Java libraries can be useful in a mobile application for a number of resons:

• We are currently seeing a boom in the mobile industry. Every few months we have new platforms (new hardware, new operating systems or both). Java applications need in the first place a JVM. If a third-party library has a native component which needs to be compiled for each platform, we're losing portability, which is Java's advantage.
• This pure Java library is probably slower than the one with the native component, but I think the future in mobile mapping applications is not about handling huge amounts of geopraphical data, but smartly handling a relatively small amount of data, which should be feasible also with a relatively slow version of SQLite.
• I still have not seen a pure Java version of Spatialite, but I think the spatial metadata needed in a Spatialite database file can be created by using SQLite after studying a bit the Spatualite documentation.

La semana pasada tuvimos la cuarta reunión de Drupal en Valencia, esta vez dedicada al desarrollo de módulos. Díria que la reunión se ha consolidado y gracias al apoyo de nuestro anfitrión, el bar Bipolar y de la incombustible coordinación sobre todo de David Hernández y Alessandro Mascherpa, los últimos viernes de cada mes vamos a tener la oportunidad de reunirnos y aprender sobre este estupendo CMS.

La sesión fue conducida por Alessandro, se trató de una introducción muy ligera a los fundamentos de desarrollo de Drupal, sin entrar en cosas complejas todavía y en realidad más o menos todo lo que se contó lo tenía claro gracias a que había hecho mis deberes y me había mirado la documentación que nos indicaron.

Así y todo, acudí con mi instalación limpia de Drupal 7, eso sí, como no puedo evitar complicar las cosas en lugar de con la configuración clásica de Apache+PHP+MySQL yo iba con Cherokee+PHP+SQLite que por otro lado no me dio ningún problema para desarrollar el taller.

La verdad es que no hay mucho más que contar salvo que la sesión fue más lenta de lo normal porque entramos a tocar varios puntos referentes a recursos, particularidades de los multisitios, traducciones y alguna cosa más que me dejo en el tintero. Al final, como es inevitable en una reunión de este tipo, la cosa derivó a un debate de las ventajas y desventajas de que Drupal no esté orientado a objetos de forma estricta, las razones de que esto sea así, etc.

Como recursos de la reunión, dejo unas transpas de desarrollo  y un artículo que sirvió de guía para crear un módulo sencillo para Drupal 7.

La próxima drupalada parece que será también sobre desarrollo, para seguir profundizando en lo visto el viernes pasado. Será el próximo 27 de mayo, ¡nos vemos!

Hace casi dos años Miguel Montesinos hablaba sobre las luces y sombras del programa Galileo tras unas jornadas que se realizaron en Valencia. Ayer, de nuevo exactamente en el mismo auditorio Santiago Grisolía de la Ciudad de las Artes y las Ciencias de Valencia, pero esta vez en una conferencia enmarcada en las actividades relacionadas con la Astronomía que la CAC viene realizando desde hace tiempo, tuvo lugar una conferencia sobre el programa Galileo y sus aplicaciones.

El ponente era Javier Ventura-Traveset, anteriormente jefe de ingeniería del programa EGNOS y actualmente es jefe de la Oficina de Comunicación y Educación del Centro Europeo de Astronomía Espacial (ESAC) que la ESA tiene en España (CV de Javier en PDF).

La conferencia estaba bien dirigida a un publico generalista, por lo tanto con un nivel técnico bastante bajo aunque explicó perfectamente en qué consisten los sistemas de navegación por satélite, las principales diferencias entre GPS, GLONASS y GALILEO, así como sus campos de aplicación.

Entrando ya en Galileo y al motivo de mi post es sobre todo porque parece que el futuro del sistema se va despejando de dudas y parece este mismo año empezarán a lanzarse satélites de la que será la constelación operativa. Los satélites GIOVE que se lanzaron en 2005 y 2008 estaban destinados a temas de testeo. De aquí a 2014 se lanzarán 18 satélites, momento en el que se podrá empezar a utilizar el sistema, aunque tendrá carencias de cobertura, ya que no se alcanzarán los 30 satélites que forman el sistema Galileo completo hasta 2019.

Es decir, a partir de 2014 podremos empezar a usar Galileo, aunque supongo que si no se utiliza conjuntamente con GPS o GLONASS no será muy operativo, pero gradualmente durante los cinco años siguientes, se irán lanzando los 12 satélites restantes, en lanzamientos sucesivos más o menos cada seis meses.

Otro punto interesante que comentó es acerca del resurgimiento del sistema ruso GLONASS. Este sistema estuvo completamente operativo a mediados de los noventa , pero debido a la corta vida útil de sus satélites (de unos 3 o 4 años) y a la falta de recursos, llegó a quedarse con apenas 6 satélites en 2001. Pues bien, parece que la apuesta por el sistema por el gobierno ruso es ya total, y parece que durante este año volverá a recuperar el estatus de completamente operativo, y de hecho, los nuevos satélites sin perder compatibilidad con los anteriores, van a utilizar una tecnología de transmisión similar a la utilizada por GPS. Esto significará que será mucho más fácil diseñar receptores que trabajen con ambas constelaciones, punto clave para el mercado de la navegación.

También hablo bastante de EGNOS, el sistema de aumentación y de corrección de la señal GPS, y me quedo con la noticia (ya apuntada en las jornadas de hace dos años) de que EGNOS se ha certificado como válido para su uso en aviación civil. Esto significa que los aeropuertos podrán ofrecer aproximaciones utilizando este sistema, de forma alternativa al tradicional ILS, permitiendo aproximaciones más eficientes y que mejorarán la calidad de vida de los vecinos de los aeropuertos, además de aumentar la seguridad en muchos de ellos.

Ya para acabar Javier entró en cómo Galileo podrá ser utilizado en la industria y en la sociedad en general, no sólo en navegadores personales o en vehículos, sino también en otros muchos ámbitos, saliendo incluso fuera del campo de la navegación, ya que gracias a Galileo vamos a tener un sistema de referencia temporal tremendamente preciso que podrá usarse en aplicaciones tan distantes de la navegación como la banca. Los relojes atómicos que tienen los satélites del sistema Galileo son un orden de magnitud mejor que los de GPS y por dar una cifra, atrasan o adelantan un segundo cada tres millones de años.

En fin, fue una amena charla de apenas una hora, pero me sirvió para tener una idea más clara de los tiempos y plazos que se manejan en el programa y de los diferentes programas que se están abordando en el mundo en este campo. Solo nos falta esperar que no se atrase más su puesta en marcha o entre GLONASS y el sistema chino COMPASS, Galileo perderá algo de fuelle en este mercado aparentemente tan competitivo en los próximos años.