Creating a collaborative photo map: From Flickr to CARTO with Amazon Lambda

Phew, it’s been almost two years since my last techie blog post. I know I know, blame on me, I should’ve been writing more here but at least I did some nice posts at CARTO blog. Anyway, It’s Christmas today and because Internet is my playground and any piece of data I can put on a map can be a toy I spent a few hours having some geeky fun.

A few days ago a friend asked I knew any service to create a map of pictures in a collaborative environment. I thought maybe a trendy photo service like Instagram would be a good fit but it happens it’s super restrictive for developers so I headed to the good old Flickr. Flickr is one of those services that are really developer friendly, has a ton of super cool features and a decent mobile application and still, for some reason, it’s loosing its traction. Sad.

Anyway, Flickr has groups so a number of individuals can share geolocated pictures and they can display it on a map but sincerely, it has a very bad interface so probably we can do something better with CARTO. The issue then is how can we maintain an updated map in CARTO from a Flickr Group?

I’m a big fan of unmanaged services. I know there are people that love to maintain their servers but I’m not one of them. If I have to publish a website I try to use something static like uploading the site to Amazon S3 (i.e. my own website) or even better, use Github Pages like the Geoinquietos website. In this case not so long ago the only option to build an application to solve this issue was going to a PaaS service like Heroku, Amazon Beanstalk or Google App Engine, but they are meant for big applications typically involving a database and in general an architecture prepared for bigger things than this simple requirement. Over the last two years a new approach has emerged, a type of service that provides an automatically managed infrastructure to define small functions where each one is aimed to do a single functionality. They only live while they are being executed and afterwards the server is shut down. Amazon Lambda was the first of it’s class but recently also appeared Google Cloud Functions. On both services you can write your function in different languages (Python, Java, NodeJS, even PHP) and they can be triggered from a HTTP call or schedule its execution periodically.

As everything with Amazon, configuration from their website can be difficult and using it from the command line can be heroic. But it was a matter of time that something like Zappa would appear. Zappa is an application that makes deploying Python functions to Lambda dead easy. You basically configure a few settings and code your function and it takes care of the full cycle of deploying, versioning and even you can tail the logs from the cloud into your console in real time.

So to make this as short as possible, I coded a Lambda function that is exposed as a url acting as a proxy to Flickr API. This proxy will take URL arguments (or use some defaults) to retrieve photos information and will output them as a valid GeoJSON file. This allows me to create a CARTO Synchronized Table that updates every hour for example and retrieves the last pictures sent to a group (up to 500, as a Flickr API limitation). This dataset can then be used to create a BUILDER dashboard to present the pictures as nicely as possible.


Map for the last 500 pictures of the “Your Best Shot of 2016” group on Flickr

Additionally, on this map I kind of reverse geocoded image locations using a world borders dataset so I was able to add a country widget. Apart from that and a bit of CartoCSS to reproduce Flickr logo, the dashboard is quite simple. If you click on any of the images the pop up highlights the image (I love this feature) and you can go and visit the picture page in Flickr.


Pop up with the picture

But there are other methods on Flickr that returns photos, you can create a map of an account public uploads, or a map of the most interesting photos of the day, by photoset, etc. etc. All using the same proxy!!

I’ve created a github repo with the source code of this proxy (just around 130 lines of code) and more detailed instructions on how to set up your environment to deploy your own version of it on your account and use it in your own integrations. I have more ideas that I want to explore and I’ll try to share it here when I do them.

  • Leverage the Foursquare real time API to create a dataset in CARTO that is automatically updated every time I do a check-in
  • How to configure a scheduled task using the CARTO Engine SQL API. This is a super common use case when you develop projects with CARTO.
  • Create a CARTO Engine proxy to allow anonymous users to perform some tasks only accessible by default to authenticated users.

What do you think of this approach? Have you used Lambda for any other interesting use cases? Do you want me to continue posting on this topic about the other ideas I have? Feel free to comment here or reach me on twitter.


III Edición Geocamp ES

A través de Geoinquietos Sevilla

El próximo 20 de junio se celebrará en Sevilla la tercera edición de la versión española de la Geocamp este año organizada por Geoinquietos Sevilla.

¿Qué es una Geocamp?

– Una desconferencia sobre temática GEO y software libre.
– Evento basado en el concepto de Barcamp y que se viene celebrando desde hace tiempo en Portugal.

El mundo de las tecnologías de la información geográfica (TIG) y el software libre está teniendo cada vez más peso en el mundo en que vivimos, tanto desde el punto de vista personal como profesional. Muestra de eso, en últimos años, se está generando un movimiento muy significativo formado por gente con grandes inquietudes sobre estos temas, a la par que están apareciendo cada vez más  profesionales del sector que participan en proyectos y jornadas de carácter nacional e internacional.

A partir de una de estas participaciones, concretamente en la Geocamp del año 2012 en Campo Maior (Portugal), nace la idea de crear un evento similar aquí en España, donde compartir experiencias y conocimientos sobre temas geo y software libre. Aquí está el germen de la Geocamp española.

Organizada por un grupo de Geoinquietos y apoyados por un conjunto de empresas e instituciones, la Geocamp es un evento con formato desconferenciaque intenta favorecer la participación y la colaboración, puesto que serán los propios participantes de la Geocamp los que conformen el programa de charlas el mismo día de su celebración, justo antes de comenzar. Por supuesto, está garantizada la participación de grandes nombres del mundo del software libre y de la geomática a nivel nacional e internacional.

La Geocamp 2015, que viene precedida de sus anteriores ediciones, realizadas en La Coruña y Vigo, respectivamente, se celebrará en el Parque del Alamillo, parque metropolitano que discurre entre el municipio de Santiponce y la propia ciudad de Sevilla y es de acceso libre (previo registro) y gratuito. Además, se ofrecerá a los asistentes coffe break y almuerzo para reponer fuerzas, regalos, etc., así como alguna sorpresa final. Todo esto gracias a los patrocinadores del evento.

Patrocinadores III Geocamp.es

Para estar atentos a todas las novedades sobre la Geocamp 2015 está disponible su portal web (http://geocamp.es/) y el blog de Geoinquietos (http://geoinquietos.blogspot.com.es/), así como sus perfiles de Twitter y Facebook.

Página de registro: http://geocampes2015.eventbrite.es/

¡Os esperamos en Sevilla!

Fuente de la foto original: https://flic.kr/p/ambxAZ

Dear OSM, just chill out.

This is kinda a reply to Gary Gale’s “Dear OSM, it’s time to get your finger out“. The more I read that, the less sense it makes to me.

Update 2015-04-30: Read also Richard Fairhurst’s Realpolitik and the OpenStreetMap License and Simon Poole’s Is OSM business unfriendly?

I think of myself as a Linux nerd. I consider myself a hacker. And I’ve spoken so many times about open/libre licensing in conferences the issue became boring.

A couple of years ago, a psychologist asked me a question as part of a job interview: What makes you angry?. And my response was clear: Things not working and logical fallacies. So my brain hurt a little when I read these particular sentences in Gary’s blog post:

There are really only three sources of global mapping […]: NAVTEQ, TeleAtlas , and OpenStreetMap. […]

Surely now is the moment for OpenStreetMap to accelerate adoption, usage and uptake? But why hasn’t this already happened?

See, a tiny part of my brain screams “fallacy“. «OpenStreetMap has things in common with NAVTEQ and TeleAtlas, ergo it has to play in the same field and by the same rules as NAVTEQ and TeleAtlas».

Maybe OSM was given birth by SteveC to cover the lack of affordable datasources, and then a way for him and his VC-fueled CloudMade to compete with them. But for me and a whole lot of nerds, OSM basically was, and still is, a playground where we can run database queries all night long. OSM is a wholly different animal.

In 2010 I argued that Geo businesses and Geo hackers are playing the same game, but with different goals, which makes for an interesting game; a game in which it would be foolish to think that the opponent will play for the same goal as you. You have to play this game to maximize your score, which is not a synonim of decreasing the opponent’s score.

In other words: when I put something into OSM, I don’t frakking care what happens to NAVTEQ or TeleAtlas. The same way when I cook something for friends I don’t care what happens to the local pizza joint.

See, maps are an infrastructure. In Spanish GIS circles, specially those around the Spanish NSDI, cartography is often called “the infrastructure of infrastructures” You need maps to plan roads, power lines, land zoning. You need stupidly accurate maps to collect taxes based on how many centimeters square your house has, or to give out grants based on exactly how many olive trees you own.

During the late 2000’s I heard a lot of criticism about OSM. But most of it didn’t come from data-collecting companies – it came from public servants. “Volunteers use cheap GPS with low accuracy, OSM will never be accurate”, they said. “The OSM data model cannot be loaded into ArcGIS and won’t be of any use”, they said. “OSM data will never be authoritative”, they said. And a few years later, this happened:

That, right there, is the Guardia Civil (who are public servants) in a freakin’ control room using OSM for freakin’ pan-european coastal border patrols. Which means OSM is a freakin’ de facto infrastructure for sovereignty.

Fact is, government agencies play a wholly different game than commercial providers. The goal of a govt’ agency (and specifically those which maintain infrastructures) is to provide a service to citizens, not to make money. As a thought exercise, think about the public servants who place the border milestones, or the ones checking road surface quality, and guess how many fucks they give about NAVTEQ or TeleAtlas.

OSM is about the ownership of infrastructure. It’s about the efficiency of copyright law. It’s all about the digital commons, dammit.

And this is where I kick a wasps’ nest by turning this post into a political one.

A capitalistic liberal will argue that infrastructure is better handled by competing private entities, renting it to citizens for a fee. But remember, I’m a Spaniard, and that means that I’ve seen infrastructures such as power lines, water companies, telcos, motorways, airports and banks privatized under the excuse of theoretically running more efficiently in private hands. We have a nice word for what happened in the real world: “expolio“, which english-speakers might translate as “plunder”.

Thanks but no, thanks. I want infrastructures to be as close to the commons as possible. Maybe it’s because I now live in the land of the dugnad, and my bias makes me see maintaining the commons as beneficial for the society as a whole.

So when you look at OSM (or at the Wikipedia, for that matter) you’re really looking at a digital common good. Which puts OSM in the same basket as other digital common goods, such as programming languages, the radioelectric spectrum, technical RFCs, or state-owned cartography. Now go read the tragedy of the digital commons.

It’s sad to live in a world where the money-making is held above many commons, even at the expense of the commons. Fortunately it’s difficult for a private entity to pollute air, water or the radioelectrical spectrum without going unnoticed, but unfortunately copyright law cares next to nothing about intellectual commons.

<rant>Please, someone explain to me how giving me intellectual ownership of something I thought about until 70 years after my death makes me think about better things; then explain to me how that reverts into the common good. </rant>

TL;DR: Dear OpenStreetMap: just chill out and don’t listen to what they say. Corporations may come and go, but a common infrastructure such as you is here to stay.

Mapping Party en Poio, Pontevedra

El sábado 11 de abril en el Centro Xaime Illa de Raxó (Poio) llega la fiesta de las fiestas, la Mapping Party Poio’15 con el objetivo de pasarlo bien mientras aumentamos los datos geográficos de la costa de Poio con una licencia libre.


Este taller está organizado por la asociación de software libre Xeopesca y cuenta con la colaboración del Concello de Poio y las asociaciones SCD Raxó y ACDeM Armadiña.


  • 10:00-11:00 Presentación de OSM, organización de equipos para la zona a cartografiar.
  • 11:00-14:00 Trabajo de campo con explicaciones de como emplear osmAndroid.
  • 14:00 -16:00 Comida.
  • 16:00-20:00 Trabajar con las computadoras para el volcado de los datos OSM
  • 20:00-20:30 Clausura del curso.


El número de asistentes será de 25. La selección de los candidatos se realizará por orden de inscripción. Se recomienda la disposición de cualquiera de los siguientes dispositivos:  GPS, teléfono con GPS y cámara digital.

Formulario de Inscripción

Para inscribirse a Mapping Party Poio’15 cubre el formulario. (ver aquí) (poio.xeopesca.gal) .

Material fungible

Se hará entrega a cada uno de los asistentes de un bloc de notas, un bolígrafo y un lápiz.

Redes SociaLes

Establecemos el hashtag #mappingpartypoio para seguir el evento a través de las redes sociales. Además también puedes seguir la  Mapping Party Poio’15 a través de twitter mediante el hashtag #mappingpartypoio o en la  página de facebook de XeoPesca.





EMT Madrid, or Open Data antipatterns

Today, february 21st 2015, is the Open Data Day. And given that I’m far asay from my favourite Open Data nerds down at the Medialab Prado, I decided to work on giving the old ¿Cuánto Tarda Mi Autobús? website a facelift.

The story behind ¿Cuánto tarda mi autobús? is rather simple. A couple of years ago I got my first smartphone, and one of the things I wanted to do is check for the bus times in Madrid. Back then, EMT Madrid (the public company which runs the buses) was heavily promoting its new website in the Spanish GIS scene. The major problem was that the website for checking the times was made with Flash (actually, with ESRI Flex) and simply there is no way to use that with a smartphone.

So I reverse-engineered the protocol (if you call “reading a WSDL document” reverse engineering), did a bit of PHP plus Leaflet, and I was able to check the bus times with a web app.


Fast-forward to the present. EMT had released the API details under the banner of «Open Data EMT», I had a saturday to devote to the Open Data Day, and my little web app needed some love after two years of no updates at all.

But, oh boy, every time I try to develop anything with interfaces made by big subcontractors, I cannot stop cringing at the amount of WTF found around.

The antipatterns

Antipattern 1: «Open Data» which isn’t actual Open Data.

In the same way that Open Source software can only be Open Source if it meets the Open Source Definition, Open Data is only Open Data if it meets the Open Definition. Period. These definitions are evolved versions of the DFSG and Free Software Definition, curated with years of experience and discussions about what is open and what is not.

So, the Open Definition states:

2.1.8 Application to Any Purpose

The license must allow use, redistribution, modification, and compilation for any purpose. The license must not restrict anyone from making use of the work in a specific field of endeavor.

From «OpenData EMT»’s terms and conditions:

1. The re-user agent is explicitly prohibited from distorting the nature of the information, and is obliged to:
a. Not to manipulate nor falsify the information.
b. Ensure that any information displayed in your system is always up to date.
c. Not to use the information to undermine or damage EMT’s public image.
d. Not to use the information in sites that might lead to a relation with illegal acts or attempts to sabotage EMT or any other entity, organization or person.

So apparently I cannot:

  • Display historical information (because my data must be up-to-date).
  • Say that the system is a complete piece of steaming crap from a technological point of view.
  • Use the information in sites such as Facebook or Twitter, because those sites might be used for an attempted sabotage to «any entity or person». Who the fuck wrote this blanket clause, folks?

Please, don’t call it «Open Data».

I have to give praise to the EMT, though. The previous version of the agreement obliged the reuser to not disclose that he/she signed an open data agreement. At least they fixed that.

Antipattern 2: Your SOAP examples contain raw XML.

The whole point of SOAP was to abstract data access. And, still, every public SOAP interface I’ve ever seen includes examples with raw XML fragments that you’re supposed to build up.

If you cannot write code that access SOAP without writing XML, you’re doing it wrong.

Think about how WMS interfaces work nowadays: you just publish the WMS endpoint, and your GIS software takes care of the capabilities and the

Antipattern 3: Keep default fake values in your production code.

From the docs:


Note «tempuri.org». A quick search will tell you that the system was designed using Visual Studio, and some lazy so-called software engineer didn’t bother to change the defaults.

Antipattern 4: Fuck up your coordinate systems

Note to non-spaniard readers: The city of Madrid is located roughly at latitude 40.38 north, longitude 3.71 west.

Now look at this example from the EMT docs about how bus coordinates are returned:


Antipattern 5: Mix up your coordinate systems

Write things like “UTM” and “geodetic” in your documentation, but do not write which UTM strip you’re referring to (hint: it’s 30 north, and the SRS is EPSG:23030). Make some of your API methods to return coordinates in EPSG:23030 and some others to return coordinates in EPSG:4326.

And for extra fun, have your input coordinate fields accept both of those SRSs as strings with comma-defined decimal point, and then do this in the documentation:


Antipattern 6: Self-signed SSL certificates



Antipattern 7: Wrap everything up in HTTP + JSON and call it “REST”

REST is a beautiful technology because it builds up pretty much on top of raw HTTP. Every object (“resource”) has its own URI (“universal resource identifier”), and the HTTP verbs are used semantically (GET actually gets information, POST modifies information, DELETE deletes a resource, and so on).

Also, HTTP status codes are used for the return status. An HTTP status code 200 means that the data is OK, a 404 means that the resource doesn’t exist, a 401 means that you are not authorized to get/post/delete the resource. Reusing the semantics of HTTP is way cool.

So, in a REST interface for bus stops, the stop number 1234 (a resource) would be located at its URI, e.g. http://whatever/stops/1234. It’s beautiful because the URI has a meaning, and the HTTP verb GET (which is the default when a web browser is fetching something) has a meaning. The server would answer with a “200 OK” and then the resource.

Low-level, it should look like:

GET /stops/1234 HTTP/1.1


HTTP/1.1 200 OK
Content-Type: text/JSON

"stopId": 1234, 
"latitude": 40.3,
"longitude": -3.71,
"stopName": "Lorep Ipsum Street",
"lines": ["12", "34"]

Now compare the theoretical RESTful way to fetch one bus stop with the real-life mess:

POST /emt-proxy-server/last/bus/GetNodesLines.php HTTP/1.1


HTTP/1.1 200 OK
Content-Type: text/JSON

"resultDescription":"Resultado de la operacion Correcta",

So, meaningless URI, POST request to fetch a resource, duplicated return status codes (for the HTTP layer and some other underlying layer).

Let me say this very, very clearly: In REST, you do not wrap a resource in a call to get that resource. Geez.

My takeaway

Readers will do good to keep in mind that I’m using my spare time in order to participate in the Open Data Day, for fun. The problem is that working with such an arquitecture is no fun at all. I can deal with these kind of enterprisey, Dilbertesque software stacks in a day-to-day basis, but only if I’m getting paid to endure the cringing and teeth-grinding.

I think it’s because the mind of an Open Source / Open Data nerd like me is difficult to understand by the classic propietary software people. I develop software just for the fun of doing so, just because I can, just because I like the feeling of empowerment of creating my own tools.

I write a lot of open source stuff. I fix wikipedia from time to time, I map stuff on OpenStreetMap if something’s wrong. I like to do it, and I empower other people to build upon my work.

Building upon good Open Source/Data doesn’t feel like standing on the shoulders of giants. It feels like standing on the soulders of a mountain of midgets… and if you’re lucky, you’ll be one of those midgets and someone will stand upon your shoulders.

For me, that involves a great deal of humility. When I watch the closed-source crowd talk about their latest product or software, they are congratulating themselves, but when I watch the open-source crowd, they’re constantly critizising themselves. And I can critizise them and they can critizise me and we all learn and that’s why they’re awesome.


About Antipodes Map

We’ve been pretty quiet over the last year but that doesn’t mean we’ve been unoccupied. Last summer we (Pedro and me) participated with some friends on a hackathon with a project to give to teachers from our region a tool to help them to relocate, precalculating travelling times with OSRM and some open datasets, one of them a database of schools that our government published as a spreadsheet. That gave us the chance to work and improve our knowledge on the CartoDB Platform, we used their JavaScript API to place a Leaflet map with a parametrized map where the SQL that defined the layer changed depending on user selections. The project is online with some slides with further information, all in Spanish.

De Casa al Cole map

De Casa al Cole Map

After that experience, and thanks to Pedro’s friendship with Carlos Galcerán, a Cuban GIS consultant working in New Zealand, we had the opportunity to put our brains working again for another pet project. The idea is easy, have you ever wondered who is on your antipodes? Yes, three quarters of our planet are oceans so the chance to have an inhabited antipodes is not high but here in Spain, it happens that half of the Iberian Peninsula is antipodal to New Zealand. Join that with the possibility to have data about schools on both countries and well, that’s reason enough for us to start playing. Imagine a geography class on primary school, say in the north coast of Galicia, where kids can contact their antipodal school in Christchurch and practice their English, or kiwis practicing their Spanish, both learning about our cultures, favorite sports, our differences.

We started with a dataset only for Galician schools and end up digging a national registry of schools to create a full dataset of schools for the country. That and the help of Carlos and some help from the Spanish Embassy in New Zealand, gave us all the data needed to set up two tables on CartoDB, so the last piece was just a web interface to develop. With the recent release of OpenLayers 3, and having played with it a bit before, I wanted to do something more complex. We’ll leave the technical details about data and software for another post or two. The application is available at http://antipodes.decasaalcole.com.

Antipodes Map

Antipodes Map

If you like the idea and know someone in New Zealand or Spain that could be interested, please spread the word. And of course, the data is available for reuse on CartoDB and the code is also on GitHub, ready to be reused on other lucky antipodal combinations, we’d love to see both data and software reused and improved!!

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:



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.