Blog

Día triste. Hoy AEMET "despublica" datos

Hoy es un día triste. Hoy es el día en el que se cierra el acceso a muchos datos públicos sobre meteorología que AEMET liberó hace alrededor de dos años. Estos datos incluían información meteorológica, climatológica, de radiación solar, de ozono, contaminación, rayos, radar o predicciones.

 

Con este anuncio, AEMET comunica que los datos dejarán de estar públicos. El motivo:

"Con objeto de dar cumplimiento a la O.M. del MAM/160/2006 de 2 de enero, por la que se regulan las prestaciones de AEMET, los productos deberán ajustarse al régimen de precios públicos establecido".

En otras palabras, se escudan en un incumplimiento de la Orden Ministerial que regula los precios para cancelar la liberación de datos y, en vez de modificar dicha O.M., se restringe el acceso a estos datos. Desconozco si existía alguna denuncia sobre el incumplimiento de esta ley, aunque lo dudo mucho, pero cuando hay interés real, se modifican las leyes en un tiempo record.

 

Esta decisión, que tan poco plausible nos parece, tiene muchos argumentos que la desaconsejan, pero por sintetizar, nada mejor que la propia política de datos expuesta en su día por AEMET en su Web al anunciar el libre acceso a los datos:

"Con el cumplimiento de esta segunda fase de accesibilidad libre y gratuita a todos sus datos AEMET avanza sustancialmente en su compromiso de ofrecer el mejor servicio meteorológico a la sociedad española."

 

¿Qué sucede ahora con el ofrecimiento del "mejor servicio meteorológico"?

 

Si estás en contra de esta política restrictiva, puedes firmar esta petición, que nuestro amigo Félix Pedrera ha lanzado enmarcada en change.org.

Video de las JIDEE 2011

La semana pasada tuvo lugar las JIDEE 2011, también conocidas como II Jornadas de Infraestructuras de Datos Espaciales, que desde el año pasado se celebran conjuntamente entre España y Portugal.

Dicen que una imagen vale más que mil palabras. Probablemente se pueda extender, exagerando, a que un vídeo vale más que mil imágenes. Aquí dejo el video resumen de la organización, donde aparece entrevistada nuestra compañera Amelia del Rey, responsable del área geoespacial de Prodevelop.

OGC's GeoSMS a brand-new outdated standard

Some months ago, diving into OGC's technical stuff, I found a document about a possible OGC standard. We were working on an indoor location project, and studying possible location formats, so the name "Open GeoSMS Specification" got my attention.

I read the full specification (quite short indeed), and left it away, thinking it would hardly see the light as an OGC specification.

I was mistaken. Last week, I received a message from OGC, calling for comments about this future specification.

First of all, I'll describe very briefly what it's about. It defines a format for exchanging location messages through the use of SMS text messages. The format is quite simple:

GeoSMS/Version Num;Latitude;Longitude;Format Type;Data Section
e.g. GeoSMS/2;2504.8015,N;12133.9766,E;B;

It has 5 variations, aimed at different uses of the Data Section:

  • Standard (B): Basic format, like the example above.
  • AGPS (A): For AGPS support when no GPS signal is available.
  • Extended (E): For special private purposes.
  • Point of Interest (P): For Points Of Interest interchange.
  • Query (Q): To query the location of a mobile node.

In my opinion it's a standard I would have liked to use 12 years ago, when SMS was almost the only way of communicating mobile equipment at an affordable telecommunication cost.

Nowadays with so many communications protocols available in the mobile realm, it seems pretty outdated. For most uses it will be much cheaper to use HTTP transport layers, rather than GSM-tight ones. It's also much more versatile not to be restricted to 160 characters, what gives you the ability to encapsulate extra information (location precision, location system, timestamps, authentication, sensor measurements, etc.). An HTTP transport would also allow different protocols on top of it.

So, I find it old-fashioned for most purposes.

Nevertheless the use case stated in the specification is about an offline usage, where the users don't have data communication. Maybe I'll give the specification a try and test it with gvSIG Mini, which has a strong offline usage.

 

 

V Jornadas de SIG Libre Girona 2011. Visión humana.

Este viernes pasado concluyeron las V Jornadas de SIG Libre de Girona 2011.

Logo SIG Libre 2011

El interés técnico de esta edición justifica claramente el esfuerzo de acudir a este evento. No obstante, dejo a posibles compañeros la valoración técnica de las novedades, presentaciones y descubrimientos de esta edición.

Para mí, el principal interés en acudir a este evento consiste en la vertiente humana. Este año es la quinta vez que acudo a las Jornadas de SIG Libre de Girona, y ya desde la primera edición, todo lo que se movió alrededor del evento y sus presentaciones destacó sobre los conocimientos técnicos que todos compartimos.

 

Mi experiencia personal es que en el pasado, el lado humano de estas jornadas ha servido para la creación de una red de networking de gran utilidad. Ya en la primera edición se creó espontáneamente el germen del capítulo hispano-hablante de OSGeo, gracias a la iniciativa de Lorenzo Becchi y Luis Sevilla, y un grupo de personas que impulsamos la creación. Han surgido colaboraciones que luego han sido llevadas a la práctica en el mercado. Han surgido incluso relaciones que han acabado plasmadas en la creación de nuevos proyectos empresariales.

El ambiente típico de este evento es el de colaboración. Me encanta la definición de Nacho Varela, de Cartolab (ahora en la Xunta de Galicia), que más o menos es así: "en otros eventos se cuenta qué se ha hecho; en éste se cuenta cómo se hacen las cosas".

Esta edición no ha sido la excepción. En primer lugar destaca, por encima de todo, el comité organizador. El SIGTE no tiene ninguna necesidad de impulsar año tras año este evento. Sin embargo, ahí están, una vez más, consiguiendo con éxito celebrar las Jornadas de SIG Libre de Girona.

Del SIGTE destaco su calidad humana. Da gusto tratar con ellos. En esta edición he tenido la ocasión de conocer mejor a Gemma Boix, su directora, y desvirtualizar a Rosa Olivella, con quienes hemos estado moviendo temas conjuntamente. Ambas comparten la imagen de buen ambiente que transmite todo el grupo del SIGTE.

Me gustaría destacar el lado humano de Lluís Vicens y Nuria Pérez, almas máter de este evento. Lluís se pasa todo el año pensando en el evento, y transmitiendo optimismo al resto del grupo, en años como éste en el que la crisis aparecía amenazante en el horizonte. De hecho, ya me confesó que está pensando en ponentes del año que viene. Disfruto particularmente con los entresijos de organización de ponentes "top", como cuando consiguieron traer hace dos ediciones a Richard Stallman. Nuria sigue manteniendo y contagiando la felicidad, a pesar de los múltiples problemas que Murphy se pueda encargar de crear.

Las conversaciones de pasillo valen su peso en oro. Las demos en vivo en un portátil, teléfono o tablet en cualquier rincón son, simplemente, únicas.

El poder compartir con asistentes de otros años las experiencias, penas y alegrías del último año, aportan tanto o más valor, que las interesantes sesiones técnicas.

Y ¡cómo no! las sesiones post-congreso en forma de cena o cerveceo, siguen aportando valor, información y relaciones de forma única. Aunque sólo sea una muestra, un vistazo al hash tag #siglibre2011 da cuenta de lo que se mueve fuera de horas de programa.

En resumen, que el lado humano de estas Jornadas y el contacto personal son insustituibles, y justifican ampliamente la asistencia al evento.

Hasta el año que viene

FOSS4G 2010 Tagcloud

Free and Open Source Software for Geospatial (FOSS4G) 2010 is going to take place during the next days in Barcelona (September the 6th - 9th).

FOSS4G 2010 logo

As part of a keynote I'm going to present, I've made a tag cloud of what's going to be there. I've taken all the relevant words out from the official FOSS4G 2010 program, removing articles, company names, numbers and so on.

With all the content I've used Wordle to generate the tag cloud of FOSS4G 2010. Here it is!

FOSS4G 2010 tag cloud

Programar sin Google

Recuerdo una conversación no muy lejana, entre un compañero, Jefe de Proyecto con cicatrices ganadas en muchos años de pelea informática, y un desarrollador que ya no está en la empresa.

A mi compañero le cambiaba la cara del verde al morado, así que agucé el oido.

- "Es que he buscado en google y no encuentro cómo hacerlo".
- "Pues invéntatelo, eres Ingeniero Informático, ¿no?".
- "Bueno seguiré buscando".

- "¿Cual es el problema?". Le pregunté a mi compañero cuando se marchó el desarrollador.

El problema en cuestión era "tan complejo" como un simple cast de hexadecimal a binario, con la pequeña complicación de que se trataba de cadenas muy largas y las conversiones automáticas de tipo habituales fallaban por overflow. En resumen, que había que hacer el cast a mano.

- "¡Lleva dos días con esto!"

Al día siguiente, volvió a aparecer por el despacho el susodicho Ingeniero, que contaba en su CV con varios certificados oficiales de Ingeniero Desarrollador de esos de a 1.000 € el certificado.

- "¡No hay manera! Da overflow. He buscado en codeplanet, etc, etc. y no encuentro nada igual".
- "Mira, mañana esto tiene que estar solucionado", le dijo el Jefe de Proyecto.

Al día siguiente la escena se repitió, con la diferencia de que mi compañero le enseñó un sencillo algoritmo hecho a mano en un rato para hacer manualmente la conversión.

El Ingeniero abría los ojos como platos. "¿Has hecho el cast a mano?"

Esta escena es una buena prueba del nivel al que podemos llegar si todo lo confiamos a San Google. Ha quedado muy atrás la época en la que programábamos sin más ayuda que un libro de referencia (bendito Kernighan & Ritchie), y el prueba y error, porque Internet aún no existía. Sin embargo, esa etapa nos obligó a buscarnos la vida, a encontrar soluciones desesperadas, y a no olvidar nada, una vez vista la luz.

Propongo que todo programador pase por una etapa (corta, eso sí) de programación sin Google, para cultivar la extinta ciencia de pensar un problema en profundidad, y encontrar un camino propio de salida. No hace falta meditar tres años, tres meses y tres días como los lamas, pero esta experiencia debería ser obligatoria.

Quizás sea una buena idea para formar becarios, y la ponga en práctica ...

No hay proyecto open-source serio sin su fork

Recientemente estaba en las IV Jornadas de SIG Libre de Girona hablando con la gente de Sextante, cuando un conocido se dirigió a ellos. La conversación fue más o menos en estos términos:

- "¡Os he hecho un fork!"

- "¡Por fin! ¡No hay proyecto open-source serio sin su fork!"

- "¡Ahora ya somos un proyecto de verdad!"

- "Ahora cuéntanos, ¿qué ha pasado?"

- "Vereis es que necesitaba ..."

 

Bromas aparte, la proliferación de forks y similares parece que estos días está de moda. En el caso de Sextante, el tema se debía, según creo recordar, a versiones de bibliotecas; nada que no resuelva una siguiente release de Sextante.

Ha coincidido que esta semana ha habido bastante revuelo en las listas de correo internacionales de gvSIG, tras el anuncio de una distribución paralela no oficial de gvSIG, que soluciona varios problemas existentes en la versión oficial 1.9.

El asunto no habría pasado de ahí si no fuera porque ha habido intentos de comunicación con la organización responsable de la nueva distribución ("quasi-fork"), sin respuesta. Confío en que, dejando a un lado intereses de vender una imagen a través de una nueva distribución, se trabaje en común, con repositorio de código fuente común, aplicaciones y cadenas de L10N comunes, bugtracking común, etc. Parece que va a ser así.

 

Pensando en las razones que motivan a alguien aventurarse a hacer un fork, se me ocurren varias:

  • Motivos técnicos. El proyecto original presenta limitaciones técnicas que para alguien son tan insalvables que fuerzan a hacer un fork. Un ejemplo de este caso podría ser GeoToolkit, fork de GeoTools (con aditivos de motivos estratégicos).
  • Motivos personales. Problemas de comunicación, inter-personales o ansias de portagonismo personal motivan que alguien decida no seguir colaborando en un proyecto y lance un fork.
  • Motivos estratégicos. La dirección del proyecto diverge de los intereses estretégicos de un desarrollador o grupo, forzando a realizar una rama del proyecto, creando uno nuevo.

Habitualmente, suele darse una mezcla de motivos. Mi opinión personal, es que muchas veces las divergencias surgen de problemas de comunicación que derivan en posiciones forzadamente inamovibles. En ocasiones es beneficioso, ya que la "forkabilidad" implica un consenso tácito en la dirección del proyecto; consenso que se hace explícito cuando aparece un fork y la comunidad debe decidir el camino a seguir. La posibilidad de que se pueda hacer un fork es intrínsecamente buena y sana, característica única de los proyectos open source.

Sin embargo, lanzar forks alegremente es en general una manera horrible e ineficiente de solucionar los problemas que puede tener un proyecto. ¡Comunicación, por favor! Una mejor comunicación solucionaría muchos de los problemas que motivan un fork.

Así, que a fin de cuentas, la aparición de forks es, en cierta manera, una consecuencia del éxito de un proyecto. No se producen forks de proyectos en vía muerta, simplemente se extinguen (como sucedió con el proyecto Community MapBuilder).

 

Así, que puede afirmarse que gvSIG ya es un proyecto maduro, con su propio fork. Seguiremos la vida de este "pseudo-fork" nacido para morir con la publicación de la versión 2.0 de gvSIG. ¿Extraño? No, además de los motivos técnicos concretos que puedan existir, la publicidad que está recibiendo la organización que lo ha lanzado, probablemente le valga la pena.

1as Jornadas de usuarios de gvSIG en Alemania

Constelación Galileo
Las presentaciones han tenido un variado perfil, con casos de uso, descripciones técnicas de capacidades de gvSIG, e incluso de la potente combinación gvSIG y Sextante.

He asisistido a las primeras jornadas de usuarios de gvSIG en Alemania, con una impresión altamente positiva.

Antes de describir las jornadas, conviene repasar los antecedentes. Alemania es el país europeo con la industria geomática más fuerte de toda Europa. Dentro de esta industria, destaca ESRI, cuyos cuarteles generales están emplazados cerca de Munich. Por otro lado, existen diversos proyectos open-source relacionados con geomática nacidos o con un fuerte impulso de la comunidad germana, como Mapbender, deegree, QGIS, SAGA o Grass.

En este entorno aparece gvSIG, como una avanzada aplicación de escritorio, que es visto con curiosidad desde el mundo germano, y que va ganando adeptos de manera progresiva.

gvSIG está en sus albores en el mercado alemán, por lo que ha resultado una grata sorpresa ver como la propia comunidad germana se ha coordinado para organizar las primeras jornadas alemanas de gvSIG. La organización ha ido de la mano del Ayuntamiento de Munich (Wolgang Qual), la Cámara de Comercio de Baviera (Andreas Fritzsche) y la empresa CSGIS (José A. Canalejo & Ruth Schönbuchner), que han realizado una inversión de tiempo, energías e ilusión, así como una importante apuesta personal.

Las expectativas iniciales era de reunir a 15-20 usuarios, ya que es lo habitual en proyectos de open-source que se empiezan a dar a conocer en el país. La primera sorporesa se produjo al saturarse el aforo de la sala prevista, con 70 asistentes, teniendo que cerrar la inscripción a más asistentes. Otra sorpresa positiva ha sido la variedad de la afluencia, con asistentes provenientes de toda Alemania, y con una buena distribución de organizaciones (administraciones públicas grandes y pequeñas, universidades, empresas usuarias, empresas de desarrollo de software y consultores).

Al final de la reunión, hubo un apartado para reunir a la comunidad, que ya está trabajando de forma activa en la traducción de la aplicación y de la documentación de usuario al alemán, con el 80% del trabajo ya realizado. La ayuda brindada por gvSIG a través del trabajo realizado sobre el plone para la gestión de las traducciones ha sido muy valorada por la comunidad local.

Galileo avanza con luces y sombras

La semana pasada (22 y 23 de abril de 2009) se celebraron las IV Jornadas sobre Servicios de Movilidad, organizada por el ITACA, centradas en el futuro GNSS (Global Navigation Satellite System) de la Unión Europea (Galileo), a las que tuve el placer de acudir como miembro de una mesa redonda.

Constelación Galileo

El proyecto Galileo arroja muchas luces y, desafortunadamente, también algunas sombras.

Luces de Galileo

Como luces mencionaré unas cuantas:

Se trata de un proyecto en manos civiles, frente al control militar del sistema GPS. Esta característica puede parecer poco importante en general, pero ya se ha demostrado su importancia en épocas de crisis, como el apagón del sistema GPS durante 72 horas, tras los atentados a las torres gemelas, o el desvío intencionado a nivel mundial de la posición calculada en unos cientos de metros durante la invasión a Irak.

Relacionado con el control civil está la independecia tecnológica, siendo ambos aspectos los auténticos catalizadores del proyecto. Esta independencia tecnológica la veo muy similar a la migración de sistemas críticos a software libre, que van realizando las Administraciones Públicas, y que suele ser el catalizador de estos proyectos, más que un ahorro de costes.

La provisión de garantía de servicio permitirá utilizar Galileo en sistemas críticos, con fiabilidad asegurada. Se está estudiando la responsabilidad subsidiaria que asumiría el futuro operador del sistema Galileo, como garantía de servicio.

La mayor precisión suele ser una de las primeras ventajas que se enumeran al describir el sistema Galileo. Realmente, las precisiones no serán mucho mejores que el actual sistema GPS con ayudas (WAAS, EGNOS, NTRIP, ...), pero sí más sencillas de implementarse en dispositivos de bajo coste, sin sistemas de ayudas, y con una posibilidad de mejor precisión a través de un servicio comercial de pago. Los servicios que se prevé ofrecer son los siguientes:

 

Tipo de Servicio Monofrecuencia
Multifrecuencia
Con elemento local
 Open Service (OS)
15 m.
4 m.
-
 Commercial Service (CS)
TBD
< 1 m.
< 10 cm.
 Safety of Life (SoL)
15 m.
< 4 m.
TBD
 Public Regulated Service (PRS)
15 m.
< 6,5 m.
TBD

Aparte de la precisión, hay una serie de aspectos tan importantes (o más) en mi opinión, como son la utilización de canales independientes de los dedicados a datos para acelerar la adquisición de información necesaria para fijar la primera posición o TTFF (Time-To-First-Fix), que con el sistema Galileo pasa a ser inferior a 1 seg., frente a los habituales minutos del sistema GPS. Esto permitirá una utilización instantánea de aplicaciones basadas en Galileo.

Otro aspecto importante es la mejora de los esquemas de codificación, que permitirán una mejor cobertura en áreas tradicionalmente difíciles para el sistema GPS, como es el caso de recepción en zonas urbanas (lo que se conoce como cañón urbano), pasando de una cobertura en entorno urbano del 50% del GPS al 95% del sistema Galileo. Otra mejora se producirá en el interior de edificios, evitando la necesidad de uso de A-GPS (Advanced GPS).

Para servicios críticos, como SoL o PRS se incluye también una señal de alerta en caso de fallo de integridad de la señal, con un retardo máximo de 6 segundos (SoL) o 10 segundos (PRS).

Galileo ha previsto también la puesta en marcha de un servicio denominado SAR (Search And Rescue), que permitirá, ante una emergencia transmitir la señal de la posición hacia un centro operador, con una confirmación de vuelta de que la emergencia ha sido recibida y va a ser atendida.

Una ventaja indirecta del sistema Galileo es que una vez desplegado, será posible la combinación de múltiples GNSS, a través de dos mecanismos:

  • Interoperabilidad: Utilización conjunta de diferentes sistemas de GNSS para proporcionar mejores prestaciones que las obtenidas por las señales o servicios de cada sistema.
  • Intercambiabilidad: Posibilidad de utilizar de manera integrada para el cálculo de la posición de "cualquier satélite de cualquier sistema", conformándose un sistema de sistemas de navegación, algo así como un GNSSS (Global Navigation Satellite System of Systems). ¿Acabará llamándose GNS3?

Sombras de Galileo

No es oro todo lo que reluce, y Galileo no iba a ser la excepción. Algunas sombras se ciernen sobre el futuro de Galileo.

La más peligrosa de todas es el retraso del proyecto, desde una fecha inicial de operación de 2008 se pasa a 2012 como fecha prevista actualmente. Esto tiene varias consecuenicas negativas.

Se corre un riesgo no despreciable de perder las frecuencias asignadas por la UIT (Unión Internacional de Telecomunicaciones) a favor de Galileo, si China empieza a operar con antelación su sistema COMPASS. Ello se debe a una premisa de la UIT que dice "first to come, first served" (el primero que llega se queda con las frecuencias)

Por otro lado el retraso ayuda a que otros sistemas se actualicen (GPS está modernizando su sistema con nuevos satélites y señales, Glonass está resurgiendo de sus cenizas, Compass copia ideas, etc.) perdiendo claramente ventajas competitivas.

Una crítica vertida con demasiada ligereza sobre el proyecto, achaca un coste excesivo a éste. Actualmente el coste total previsto a fin de proyecto (inicio de operación) es inferior a los 4.000 millones de euros. Esta cantidad comparada con alguna inversión como los 6.000 millones del enterramiento de la M3 y accesos en Madrid queda diluida, entendiendo la importancia de la independencia tecnológica de la Unión Europea.

Conclusiones

Las ventajas como se ve son altamente beneficiosas para usuarios finales, Gobierno, ingenierías o prestadores de servicios. Galileo contribuirá a universalizar el uso de sistemas de posicionamiento todavía más, así como a ser utilizados con fiabilidad en entornos comerciales o críticos.

La sombra del retardo acechará a lo largo del desarrollo y despliegue del proyecto; aunque espero que la voluntad política evite nuevos desencuentros y descoordinaciones cuya aparición supondrían un grave riesgo para el proyecto.

Fue tranquilizadora la información transmitida por personal de la ESA, acerca del cumplimiento de los últimos plazos.

Distribuir contenido