The Null Island Algorithm


We geomaticians like to gather around a mythical place called Null Island. This island has everything: airports, train stations, hotels, postcodes, all kinds of shops, a huge lot of geocoded addresses, and whatever geographical feature ends up with null coordinates due to whatever buggy geoprocessing pipeline and ends up in the (0,0) coordinates.

But earlier this year, some geonerds such as @mizmay and @schuyler realized that there is no one Null Island, but one Null Island per datum / coordinate system (depending on who you ask). And @smathermather had the spare time to find out how the “Null Archipielago” looks like:

(Null archipielago image by @smathermather, containing Map tiles by Stamen Design, under CC BY 3.0. Data by OpenStreetMap, under CC BY SA)

Fast forward a few months. I received an e-mail from one of my university peers, asking for help with a puzzle:

A friend of mine received a puzzle with some coordinates. He has to find a place on earth represented by 861126.41, 941711.64.

It’s supposed to be a populated place. Any ideas?

Well, off the top of my head, those looked slightly like UTM coordinates – two digits after the decimal point, suggesting centimeter precision… but the easting is way off the valid range for UTM coordinates.

And I realized this is the Null Archipielago problem, all over again; but instead of plotting (0,0) on a map, let’s plot all points having (861126.41, 941711.64) coordinates in any reference system.

Cue PostGIS. We can create a point in every CRS like so:

select srid, ST_GeomFromText('POINT(861126.41 941711.64)',srid) as geom
 from spatial_ref_sys;

Note the complete absence of PL/SQL in there.

But it will be much easier to work with the data if all the points are in our beloved EPSG:4326 latitude-longitude coordinate system. And while we’re at it, let’s materialize that data into a table:

select srid, ST_Transform(ST_GeomFromText('POINT(861126.41 941711.64)',srid),4326) as geom
 from spatial_ref_sys;

But there is a problem with this – the PostGIS query will crash due to some CRSs having an empty Proj4 string. This took me a while to trace and fix:

select srid, ST_Transform(ST_GeomFromText('POINT(861126.41 941711.64)',srid),4326) as geom
 from spatial_ref_sys where proj4text!='';

And now we can take this data out into a file… but once again, there’s a catch: some of the coordinates are out of bounds and represented by (∞, ∞) coordinate pair. Even though file formats can handle ∞/-∞ values (good thing we know how IEEE floating point format works, right folks?), some mapping software can not accommodate for these values. And I’m looking at you, CartoDB upload page.

In this particular case, there are only points for (∞, ∞) so the data can be cleaned up in just one pass:

delete from archipielago where ST_X(geom)>180;

Then just add a tiny bit of CartoDB magic, and publish a map:

nullarchipielago

https://ivansanchez.cartodb.com/viz/1ac4a786-805a-11e4-bc48-0e853d047bba/public_map

I still don’t know if the original puzzle has anything to do with any obscure used-in-the-real-world CRS, but at least it’s worth a try.

Bicipaseo 21Sep

Mapping for the busy cartographer: today moving dots


This article describes how to make a quick map using some nice services we have at our hands. Nowadays almost everyone can create a maps using services like CartoDB, Mapbox, uMap or even Google My Maps. In this case I’ll show how I used the incredible flexibility of CartoDB to combine some Postgres/PostGIS SQL with CartoCSS to animate some dots on top of OSM cartography rendered by Mapbox.

This combination is really unique and convenient, other services only allow you to upload or draw some features and decide some static styling for them. But with this combination, using old SQL you can adapt your data for different uses, with CartoCSS the power of the Mapnik rendering library is available and finally, using the awesome Torque capabilities, animation can be added to our map.

About

The idea of this map is to represent a crowd of cyclists running along the future bike line by the interior ring of the city of Valencia. Tomorrow Sunday 21 September there will be a march to show the interest of city bikers for this line so my idea was to make people think about how the city look like with this (still imaginary) bike lane full of cyclists, instead of cars.

Data preparation

  1. Trace a line that represents the route
  2. Transform the line to EPSG:3857
  3. Make the line denser, placing points every 25 meters using the «Densify geometries given an interval» QGIS processing tool
  4. Convert the line to points (again with Processing) and give them these properties:
    • route it will serve to produce more routes in the future
    • lap to separate the points of the route of other points of interest outside the route
    • id to order the rendering of the points

Visualization

After uploading the dataset to my CartoDB account I’ve created a new visualization that will have these layers:

  1. A blurred line with the route
  2. A point marking the meeting place to start the activity, just in front of the city hall.
  3. The animated points moving over the route

Line

Load the layer paseo and customise the SQL. The SQL is quite self-explanatory, first we filter the points over the line and then we use the ST_MakeLine aggregated function to rebuild our original line.

WITH route AS (
  SELECT *
  FROM paseo
  WHERE route = 1 AND lap>0
  ORDER BY id)
SELECT
  1 cartodb_id,
  ST_MakeLine(the_geom_webmercator) as the_geom_webmercator
FROM route
GROUP BY lap

The styling of this layer is a simple CartoCSS rule with the only trick of a heavy blur filter.

#paseo[cartodb_id=1]{
    line-color: #A53ED5;
    line-width: 8;
    line-opacity: 0.7;
    line-comp-op: lighten;
    image-filters: agg-stack-blur(10,10);
}

Moving dots

This is the most important part of the map, of course. I have a path of points ordered and what I want is to show a more or less crowded ring of people moving. To do it, I’ve created a UNION of ten SELECTs to the table offsetting the id over the full range of id’s. To acieve that I’ve used this long SQL:

WITH route AS (
    SELECT * FROM paseo WHERE lap>0 AND route = 1
),
laps AS (
    SELECT
        cartodb_id, the_geom_webmercator,
        id
    FROM route r1
    UNION SELECT
        cartodb_id, the_geom_webmercator,
        CASE WHEN id  > 25 THEN id - 25 ELSE id - 25 + 254 END id
    FROM route r2
    UNION SELECT
        cartodb_id, the_geom_webmercator,
        CASE WHEN id  > 50 THEN id - 50 ELSE id - 50 + 254 END id
    FROM route r3
    UNION SELECT
        cartodb_id, the_geom_webmercator,
        CASE WHEN id  > 75 THEN id - 75 ELSE id - 75 + 254 END id
    FROM route r4
    UNION SELECT
        cartodb_id, the_geom_webmercator,
        CASE WHEN id  > 100 THEN id - 100 ELSE id - 100 + 254 END id
    FROM route r5
    UNION SELECT
        cartodb_id, the_geom_webmercator,
        CASE WHEN id  > 125 THEN id - 125 ELSE id - 125 + 254 END id
    FROM route r6
    UNION SELECT
        cartodb_id, the_geom_webmercator,
        CASE WHEN id  > 150 THEN id - 150 ELSE id - 150 + 254 END id
    FROM route r7
    UNION SELECT
        cartodb_id, the_geom_webmercator,
        CASE WHEN id  > 175 THEN id - 175 ELSE id - 175 + 254 END id
    FROM route r8
    UNION SELECT
        cartodb_id, the_geom_webmercator,
        CASE WHEN id  > 200 THEN id - 200 ELSE id - 200 + 254 END id
    FROM route r9
    UNION SELECT
        cartodb_id, the_geom_webmercator,
        CASE WHEN id  > 225 THEN id - 225 ELSE id - 225 + 254 END id
    FROM route r10
)
SELECT
    cartodb_id, the_geom_webmercator,
    ((random()*10-10) + id) id
FROM laps

The first with subquery filters the points of the path for this route that feed the next subquery: 10 unions with an id offset separation of 25 points. This subquery is passed to the main query that finally randomizes the id by +-5 positions, that is the order, so the moving dots are not regular, giving a more interesting (anarchic?) effect.

Using the wizard, the main aspects of the Torque animation are set up. It’s important to use a proper resolution, duration and frame count to adjust the rendering to a nice motion. Afterwards some last touches to the CSS to adjust the compositing operation and specially the trails, leaving just one more rendering of a similar point, instead of the default bigger and more transparent feature.

Map {
-torque-frame-count:64;
-torque-animation-duration:30;
-torque-time-attribute:"id";
-torque-aggregation-function:"count(cartodb_id)";
-torque-resolution:4;
-torque-data-aggregation:linear;
}

#paseo{
  comp-op: minus;
  marker-fill-opacity: 1;
  marker-line-color: #FFFFFF;
  marker-line-width: 0.5;
  marker-line-opacity: 1;
  marker-type: ellipse;
  marker-width: 6;
  marker-fill: #41006D;
}
#paseo[frame-offset=2] {
 marker-width:6;
}

Meeting point

To add a feature to the map to render the meeting point, I manually added a new feature to the layer using the CartoDB editor. This feature will have the property lap=0 so it won’t be on the other layers. The SQL for this layer is just a

SELECT * FROM paseo WHERE route = 1 and lap = 0

And the CartoCSS is quite simple with the only important trick to use an external SVG. I’ve used directly the town-hall marker from the Mapbox Maki repository.

#paseo{
  marker-fill-opacity: 0.9;
  marker-line-color: #FFF;
  marker-line-width: 1.5;
  marker-line-opacity: 1;
  marker-placement: point;
  marker-type: ellipse;
  marker-width: 40;
  marker-fill: #3B007F;
  marker-allow-overlap: true;

  marker-file: url(https://raw.githubusercontent.com/mapbox/maki/mb-pages/src/town-hall-24.svg);

Fixed info window

On this layer I’ve also configured an infowindow so when you click on the town hall icon you get some data about the schedule for the event.

Base map

I started using the Nokia day grey base map offered by CartoDB, but after a couple of iterations on the design, I thought it could be great to use a pale purple base map so I went to Mapbox web and quickly crafted a variation of their Mapbox Streets base layer.

Other components

Finally, using the new nice CartoDB layout capabilities I’ve added a simple title for the mobile version of the rendering and a couple of texts and an image (uploaded to imgur) for the logo of the group promoting this activity.

Conclusion

Well that’s all. You can check the visualization here. The job took like 4 to 5 hours. I finished the first animated version in 2/3 hours but you know, devil is in details and designing is always about iterations and refinement. Anyway I’m quite satisfied on the result and I think it serves for its purpose. Definitely I’ll have the opportunity to review and refine this process, as I imagine more routes and bike marches will happen in Valencia where bikers are winning the battle :-)

What do you think about this visualization. What do you like and what do you hate? Improvements? I’d love to hear your thoughts and comments to make better maps.

Update: almost same effect without crazy UNION

This morning Pedro-Juan asked my, why so many UNIONs? why not using just one long CASE?. After accepting the challenge I did something with CASEs but then realized that I wast just looping over a smaller set of id values, so I could use the modulo function. So the long UNION SQL could be reduced to this easy and simple SQL:

SELECT
    cartodb_id, the_geom_webmercator, 
    ((random()*10-10) + id%3) id
FROM paseo WHERE lap>0 AND route = 1

Wow, that’s so concise compared with the huge SQL above!! Using this id%3 I forced all the values to be just 1,2,3 but with the afterwards random the moving effect is achieved.

The CartoCSS would need also some changes to allow to “fill” the rendering over all the animation time. Check the differences with the above code, specially the number of offsets added:

Map {
-torque-frame-count:50;
-torque-animation-duration:8;
-torque-time-attribute:"id";
-torque-aggregation-function:"count(cartodb_id)";
-torque-resolution:2;
-torque-data-aggregation:linear;
}

#paseo{
  comp-op: minus;
  marker-fill-opacity: 1;
  marker-line-color: #FFFFFF;
  marker-line-width: 0.5;
  marker-line-opacity: 1;
  marker-type: ellipse;
  marker-width: 6;
  marker-fill: #41006D;
}
#paseo[frame-offset=4] {}
#paseo[frame-offset=8] {}
#paseo[frame-offset=12] {}
#paseo[frame-offset=14] {}
#paseo[frame-offset=16] {}
#paseo[frame-offset=18] {}
#paseo[frame-offset=20] {}
#paseo[frame-offset=22] {}

The resultant visualization can be accessed here. Which one do you like more? Do you think it’s worth the simplicity over the (in my opinion) slightly worse effect?

Cartografiando para Filipinas en OSM


Tras una semana frenética de actividad en OpenStreetMap para ayudar en todo lo posible en la crisis por el tifón Haiyan/Yolanda, acabar haciendo una sesión de formación y sobre todo construcción de comunidad en Valencia para mí ha sido toda una experiencia.

Por un lado la increíble respuesta de la comunidad OSM en general a esta crisis (ya casi llegamos a los mil colaboradores), con noticias cada día más esperanzadoras de la cantidad de información que se ha generado en tan poco tiempo, así como la actividad en la lista de correo del equipo HOT. Por otro lado artículos en medios de comunicación como The Atlantic y espectaculares visualizaciones como la del NY Times. Y finalmente la guinda con la sorpresa de obtener una buena aceptación por parte de los estudiantes de cartografía de Valencia para participar en la sesión.

De hecho se nos desbordó un poco el asunto y tuvimos que prometer que repetiremos la actividad la semana que viene en la universidad con ellos para que no vinieran todos hoy. Y menos mal porque hemos casi llenado las instalaciones que tan amablemente nos han cedido la gente de beCode. Creo que vamos a seguir contando con ellos para hacer cosas juntos, ya que casi sin conocernos nos han abierto sus puertas y nos ofrecido de forma desinteresada su local para que hagamos allí lo que se nos ocurra. ¿Mola no?

Al final hemos sido algo más de veinte personas, prácticamente todas noveles en OSM. Tras una charla ultra rápida sobre qué es OSM y qué íbamos a hacer hoy, la gente se ha puesto primero a pillarle en tranquillo a JOSM, y después ya a trabajar. Y la tarea no era para nada sencilla, ya que había que comparar datos anteriores al tifón (la imagen proporcionada por Bing) con la imagen del satélite Pleiades que Esri ha servido para que la comunidad pueda identificar los daños del tifón. Imágenes desplazadas, usuarios que no habían sido muy cuidadosos con la creación de cartografía y algunas nubes más o menos densas han sido los mayores problemas que ha tenido la gente para poder dar de alta nuevos edificios y carreteras y marcar aquellos que han quedado destruidos por el paso de Haiyan.

Como suele ser habitual en estas sesiones, han habido muchas dudas, algún problema técnico y unos cuantos despistes por mi parte pero en general la gente creo que ha entendido tanto la mecánica del trabajo en OSM, como la importancia del trabajo en estas situaciones de desastres medioambientales. Realmente sesiones como hoy hacen comunidad y me alegra ver que las nuevas generaciones de cartógrafos se interesan por estos temas, espero que cale el mensaje y desde Geoinquietos Valencia hayamos contribuido a aumentar la comunidad de OSM en nuestra ciudad.

A ver qué tal nos sale la semana que viene.

 

Cómo instalar la toolbox de LAStools en QGIS


El conjunto de herramientas LAStools para procesar datos LiDAR están disponibles en el software propiertario ArcGIS desde abril de 2012, pero no ha sido hasta el FOSS4G13 de Nottingham que no han estado disponibles para QGIS. Las herramientas han sido testadas en QGIS 1.8.0-Lisboa y 2.0.1-Dufour. En esta entrada os enseñamos el modo de installar LAStools en QGIS y, básicamente, es la traducción y adaptación del manual de instalación que se encuentra en el blog de Martin Isenburg aka rapidlasso.

Nos centraremos en instalar las herramientas en la versión de QGIS 2.0.1-Dufour, por lo que lo primero que necesitamos es descargar e installar dicha versión. A partir de entonces, seguiremos las siguientes instrucciones:

  1. Si tienes abierto QGIS, ciérralo

  2. Borra la carpeta donde está contenido el plugin de LiDAR en sextante. La ruta para los usuarios de Windows es:

    "C:\Program Files\QGIS Dufour\apps\qgis\python\plugins\processing\lidar"

    La ruta para los usuarios de GNU/Linux es

    ~/.qgis/python/plugins/processing/lidar
  3. Copia la carpeta lidar que está en este archivo comprimido en el lugar de la carpeta borrada.

    Nota: Los usuarios de QGIS 1.8.0-Lisboa tienen que sustituir la carpeta lidar dentro de:

    "C:\Program Files\QGIS Dufour\apps\qgis\python\plugins\sextante\lidar"

    o si utilizas GNU/Linux, dentro de:

    ~/.qgis/python/plugins/sextante/lidar

    por la que se encuentra en este otro archivo comprimido.

  4. Descarga la versión más reciente de las LAStools que se encuentra en lastools.zip.

  5. Extrae la carpeta lastools. Si estás usando Windows, procura no estraerlo en ninguna ruta con espacios, si estás en GNU/Linux tendrás que compilar las herramientas.

  6. Inicia QGIS, y si encuentras algún error cuando se carge el script de Python, repite los pasos de 1 a 3 con más cuidado ;)

  7. Habilita el toolbox que se encuentra bajo el menú procesing como se muestra en la siguiente figura:

    images/qgis_2-0_menu_toolbox.png

  8. Cambia el toolbox de Simplified Interface a Advanced Interface, imágenes de la izquierda y derecha respectivamente:

    http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_simplified.png?w=625   http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_advanced.png?w=625

  9. Abre el submenú Options and configurations de la pestaña Processing como se muestra a continuación:

    http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_opts-config.png?w=625

  10. Activa la casilla Activate que se encuentra en Providers -> Tools for LiDAR data como se muestra en la siguiente figura, e introduce la ruta de la carpeta donde estén alojadas las LAStools en LAStools folder:

    http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_activate.png?w=625

  11. Ahora deberías ver el conjunto de herramientas Tools for LiDAR data en el toolbox y todas las LAStools como en esta figura:

    http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_lasinfo.png?w=625

  12. Inicia cualquier comando mediante un doble click y rellena las opciones. En la siguiente figura se muestra la interfaz de lasinfo.

    http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_lasinfo_interface.png?w=625

Tened en cuenta que, al distrubuirse el código de manera libre sólo de unas pocas herramientas, los usuarios de GNU/Linux tendrán menos funcionalidades disponibles. No así los usuarios de Windows, cuyas herramientas se distribuyen como shareware.

Martin Isenburg agradece a Victor Olaya por crear todo el entorno de sextante para crear nuevos plugins y por los ejemplos de cómo crear módulos. Al igual que él, yo también agradezo a Victor todo el trabajo porque también estoy trasteando con la creación de módulos dentro de sextante :P

Herramientas Libres para trabajar con datos LiDAR


En los últimos años ha proliferado el uso del LiDAR como técnica topográfica. Básicamente, consiste en un telémetro láser que mide el tiempo que tarda una pulso láser en ir y volver después de haber rebotado en un objeto. De este modo consigue hallar la distancia entre el instrumento y el objeto. Es decir, es sencillamente un distanciómetro, pero con la particularidad de que puede llegar a medir unos 100000 puntos por segundo (100 MHz). Si, además, incorporamos a los equipos de medición un GPS que nos dé la posición y un sistema inercial que nos de la orientación si estamos en movimiento, podemos dar coordenadas globales, normalmente en el sistema WGS84, a todos los puntos medidos. Por tanto, tendremos lo que se denominan nubes de puntos de los cuales conoceremos su posición en un sistema de referencia global, además de otras características relativas al objeto, como la intensidad o diferentes ecos de retornos, o referentes a la medición como ángulo de emisión del pulso, tiempo o distancia relativa al sensor.

Las compañías que desarrollan instrumentación LiDAR, ya sean telémetros aerotransportados, dando lugar a lo que se denomina en inglés Airborne Laser Scanning (ALS), o telémetros terrestes, Terrestrial Laser Scanning (TLS), también desarrollan su propio software destinado a:

  1. Extraer los datos del equipo de medida y ofrecer los datos en algún
    formato propio o, al menos, conocido.
  2. En algunos casos, hacer post-proceso de dichos datos y obtener productos
    cartográficos finales.

Sin embargo, como en el ecosistema de los GIS, existe un software privativo que monopoliza casi todo el mercado del software para realizar los trabajos de post-proceso. No voy a dar el nombre de ninguno de estos paquetes porque el objetivo de esta entrada es justamente la contraria, exponer las posibilidades existentes para utilizar software libre a la hora de trabajar con datos LiDAR.

Lamentablemente, para extraer los datos de la mayoría de los equipos actuales no hay alternativas y necesitamos utilizar obligatoriamente software privativo. Comprar la licencia no es el verdadero problema, porque si tenemos dinero para comprar un equipo que cuesta varias decenas de miles de euros es que también podemos comprar al menos una licencia por un par de miles. Lo peor es lo que verdaderamente implica el software privativo, es decir, que no eres libre de hacer lo que quieras con producto adquirido. Sin embargo, si alguien quiere hacerse un telémetro láser, puede utilizar el módulo para la captura de datos de las librerías PCL, ya que soporta algunos dispositivos conocidos. Pero sobre la librería PCL y otras más hablaremos más datelladamente en otra entrada. Además, en la mayoría de los casos, cuando podamos acceder a datos LiDAR, estos estarán ya en un fomato conocido. Lo lógico es que obtengamos los datos en el formato LAS que es el formato estándar que define la ASPRS (American Society for Photogrammetry and Remote Sensing).

Hay varias librerías libres para la lectura y escritura de archivos en este formato LAS. La decana de ellas es LASlib. Está desarrollada y mantenida por Martin Isenburg y está escrita en C++. Está licenciada bajo LGPL, por lo que se puede utilizar en otros paquetes, aunque sean privativos. Al descargar estas librerías y compilarlas genera unas herramientas llamadas LAStools que sirven para la gestión de archivos LAS (las2las, lasmerge), para creación de LAS a partir de archivos de texto (txt2las) o archivos de texto a partir de LAS (las2txt), para dar información sobre archivos (lasinfo, lasprecision, lasdiff) o para crear un índice espacial de los puntos dentro de los archivos (lasindex). En las últimas versiones, también se crea la herramienta laszip que sirve para comprimir archivo LAS. El formato de salida es LAZ y el archivo de comprimido ocupa SOLO entre el 7% y 20% del tamaño del archivo original. A todo esto hay que añadir que con la librería LASlib también se distribuye otra librería para leer y escribir formatos LAZ, también en C++ y también con licencia LGPL. Para los usuarios de windows, además, están disponibles otras herramientas precompiladas, de las cuales no voy a dar detalles porque no son libres, sino que son shareware.

De la librería LASlib se hizo un fork y nació la librería libLAS, que está bajo el auspicio de OSGeo. También escrita en C++ pero incorporan bindings para una gran cantidad de lenguajes de programación. También incorpora herramientas para la gestión de archivos en formato LAS y texto, que se llaman de igual manera que las LAStools, aunque la utilización de los comandos pueda variar. Las diferencias que existen actualmente entre ambas librerías se pueden encontrar aquí.

La librería SPDLib es bastante reciente. Tanto es así que empezó a desarrollarse en el verano de 2011. El formato estándar que utiliza para trabajar con datos LiDAR se denomina precisamente SPD (Sorted Pulse Data) y está basado en el formato HDF. Es un formato de datos ordenados e indexado que está optimizado para el acceso rápido a los datos y en el que es posible trabajar con toda la señal del pulso de retorno, en inglés full waveform, no sólo con ecos discretos, como hace las librerías anteriores. Y precisamente ésta es una de sus grandes virtudes. Por lo demás, está en consonancia con las librerías ya vistas. Está desarrollada en C++, con bindings para python e IDL, y con licencia GPL. Al compilar se crean una serie de herramientas para la gestión, manipulación e información de archivos SPD, así como una herramienta imprescindible para transformar entre formatos LAS y SPD. Otra de las ventajas que presenta es que incorpora utilidades para generar modelos digitales en cualquier formato soportado por gdal, y para aplicaciones forestales. ¡Todas ellas libres! Sin embargo, al ser desarrollada principalmente por una sola persona y ser tan reciente, uno de los problemas que presenta es la escasa y, en algunos casos, inexacta documentación.

Sin duda, existen más librerías capaces de trabajar con datos LiDAR pero con otros propósitos distintos a los que hemos cubierto aquí. Las intentaremos tratar en otras entradas. Manteneos atentos.

PD: Mientras escribo estas líneas me llega un tuit en el que hablan de otra libreria
en python para leer y escribir datos LiDAR en formatos LAS. Se llaman laspy :)

Primeras impresiones de Smart Citizen


Smart Citizen es un proyecto que apareció en goteo hace un año. Goteo es una web de crowdfunding al estilo de Kickstarter. Apareció poco después del Air Quality Egg, al cual llegué tarde para participar. Así que nada, cuando vi una idea similar me apunté sin pensármelo mucho. ¿Cuál es la idea? Bien es sencillo, imaginad una red completamente voluntaria para la medición de variables medioambientales, sobre todo aquellas relacionadas con la contaminación tanto acústica como de cualquier otro tipo. Esa red no estaría controlada por ningún organismo, realmente es una red porque existe una forma común de acceder a todos los datos, pero los miembros ni se conocen, ni tienen por qué tener los mismos objetivos, ni las mismas motivaciones. ¿A que recuerda a otras actividades similares? Efectivamente, se trata al igual que en OSM por ejemplo, de «mapear» el territorio solo que de una forma diferente, un paso más allá de la representación estática de la realidad, hacia un conocimiento más profundo de nuestro entorno al entrar en el mundo de los sensores en tiempo real, de la famosa Internet de las Cosas.

Tanto Smart Citizen como AQE solo son los comienzos de una nueva generación de hardware, software y servicios que nos harán ser más conscientes (y espero concienciados) de nuestro entorno, de la calidad del mismo y de cómo evoluciona tanto en el corto plazo como con miras un poco más alejadas. Con todo este conjunto de datos en bruto publicados en tiempo real, ¿quién sabe qué innovaciones veremos en los próximos años y cómo éstas afectarán nuestras vidas?.

En fin, volviendo al caso concreto de Smart Citizen, hace poco me llegó la placa. Básicamente es una placa Arduino con una placa superior de sensores (shield en el argot Arduino) y una batería. La placa ya viene con el software precargado aunque ciertamente van a ir saliendo actualizaciones del mismo que hay que cargar con el entorno de desarrollo estándar de Arduino, sin mucho más misterio.

SCK

Para poner en marcha la placa solo hay que configurar la red wifi a la que se conectará. Esto se hace a través de la web mediante un applet java que realiza todo el proceso. El único problema que tuve es que en mi caso, cuando se genera el puerto para el dispositivo no tengo permisos para usarlo por lo que tuve que ejecutar un sencillo sudo chmod 777 /dev/ttyACM0 para que fuera capaz de cargar la configuración. Una vez cargada, se reinicia la placa y empieza a enviar datos sin mayor inconveniente, quedando publicados de forma automática en la web.

La web todavía está en desarrollo, bueno TODO está aún en desarrollo, incluyendo el firmware que ciertamente aún no presenta los datos de los sensores todo lo bien que debiera. Por ejemplo los valores de calidad de aire vienen en Ohmios, en lugar de las más típicas «partes por millón». Todo esto estoy seguro que se irá puliendo y aún cuando algún sensor no vaya del todo fino (me temo que el de sonido, por ejemplo), solo como primera aproximación a lo que puede ser el disponer de una red de sensores publicando en tiempo real toda esta información es más que interesante.

La red Smart Citizen está sobre todo (de momento) enfocada en Barcelona, de hecho la mía es la única placa hasta la fecha activada en la provincia de Valencia.

Smart CItizen en Barcelona

Por otro lado todavía hay mucho que hacer en cuanto a la presentación de los datos que se van subiendo a su plataforma. Además de la web del sensor hay algún punto de acceso para descargar en formato JSON todos los registros y también una web para ver datos más antiguos que los escasos 20 minutos que se pueden ver desde la web oficial.

En fin de momento eso es todo, la placa ahora mismo la tengo «indoor» porque aún tengo que ver cómo le conecto un panel solar o bien saco un cable USB para poder tenerla en el balcón de casa, y que haga medidas lo más estables posible. Ya iré contando.

Geocamp


La semana pasada en Óbidos tuvo lugar el tercer Geocamp de Portugal. Geocamp es un modelo de jornada en cierta manera similar a otras desconferencias como las Barcamp o las Wherecamp donde la idea inicial es que la gente llegue y proponga sus charlas y el mismo día se organice todo el evento en función de lo que le apetezca a la asistencia.

En realidad esto este año no ha sido del todo así porque el programa parece que estaba más o menos claro al arrancar el día y por tanto no hubo esa dinámica de grupo de decidir qué se presenta y cuándo. Así y todo sí se hizo una ronda inicial de presentación de todos los asistentes, cosa que está muy bien para tener una idea de qué tipo de gente asiste, qué podrían esperar y tal.

Yo acudí con Pablo, Micho y Fran, unos amigos geoinquietos gallegos que muy amablemente me recogieron en Oporto y con los que pasé el fin de semana.

Cuando me inscribí no tenía ninguna idea interesante que contar pero al poco tiempo y viendo un trabajo que había empezado yo y que estaba terminando Vicente, pensé que podía ser un caso de uso que podría quedar bien en un evento como el Geocamp. Se trata de un pequeño ejemplo de uso de Geokettle, un software que usamos a diario en Prodevelop para todo tipo de tareas que hay que ejecutar de forma repetida y a menudo desatendida. Geokettle es un verdadero GIS de escritorio (en su variante gráfica) que permite diseñar complejos flujos de trabajo en los que se involucran datos geográficos y que luego pueden ejecutarse por consola de forma programada. Dejo el enlace a las diapositivas que darán una idea (en parte divertida espero) sobre lo que conté.

Fom CAD to DB

Centrándome en el evento, me gusta mucho el formato por varias razones. En primer lugar el detalle con el que se diseña, buscando un lugar alejado de la ciudad pero que tenga algo que ofrecer, una comida en un espacio abierto al aire libre en el que poder conversar con una cerveza fresquita, varias pausas que buscan tanto el descanso como la conversación, que sea un evento para poca gente donde prime la interactividad frente a la pasividad de «ir a que te cuenten un rollo», la multidisciplinariedad de las charlas variando del open data en la administración electrónica al uso de drones para fotogrametría o el arte digital. Lo importante es que siempre hay un punto de conexión en las ciencias de la información geográfica, pero con una amplitud de miras que invita a participar y charlar.

2013-05-25 13.43.05

Si no tienes nada realmente interesante que hacer el 22 de junio y esto que te he contado te parece atractivo, que sepas que los mismos amigos gallegos con lo que pasé el fin de semana pasado están organizando para ese día un evento muy muy, pero que muy parecido. Se llama Geocamp, oh sorpresa. Yo voy, pero lo que es más importante, gente tan interesante como Juan Freire, Juan Marín o Jorge Arévalo estarán por allí para pasarlo bien.

¿A QUE TE APUNTAS?