Archivo de la categoría: geodatos

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:

tempuri

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:

positionbus

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:

coordinateint

Antipattern 6: Self-signed SSL certificates

Srsly?

sslcert

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
idClient=user&passKey=12345678-1234-1234-12345678&Nodes=1234

-----

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

{
"resultCode":0,
"resultDescription":"Resultado de la operacion Correcta",
"resultValues":{
  "node":1234,
  "name":"ROBERTO DOMINGO-AV.DONOSTIARRA",
  "lines":["21\/1"],
  "latitude":40.434861209797,
  "longitude":-3.6608600156554
  }
}

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.

</rant>

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.

 

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.

¡Hazme un mapa de España! … ¡y bien rápido!


Ostras como se ponen los jefes de vez en cuando y claro, cuando vas y estiras del hilo te enteras que sobre el supuesto mapa de España van a pintar con chorricientos colores y necesitan que se vea bien a cualquier escala y que tenga el entramado de las calles, pero también salgan las provincias y puedan hacer zoom y pintar sobre las provincias… ¿no os suena?, jopé que suerte, a mi me pasa a menudo…

Así que en esta entrada vamos a intentar dar una solución planteando un mapa desaturado para poder pintar en colorines sobre él, el mapa tendrá orígenes de datos fáciles de conseguir – y libres – y utilizará un stack de software libre para construirlo… así que tendréis un mapa rápido [ish], fácil y bonito [ish]…

Sigue leyendo

OSM + ImpOSM + TileMill


Hacía tiempo que no le dedicaba un ratillo a los temas geofrikis, no por falta de ganas, sino porque soy disperso, muy muy muy disperso, pero se cruzó la posibilidad de mezclar cartografía y juegos de rol y …

Allí que medio liando a otro, que no hace falta que le líe nadie, llamado @RealIvanSanchez, preparamos una versión online del mapa de Cunia, la ciudad sin alma del juego de rol Rol Negro de la editorial Ediciones Sombra.

Y por aquí os voy a comentar el stack que usamos para la hazaña…

Sigue leyendo

Descarga masiva de información del Catastro


Ayer se realizó en el Ministerio de Economía y Hacienda una jornada para informar sobre el nuevo servicio que la Dirección General del Catastro (DGC) ha puesto a disposición de los ciudadanos, el Servicio de descarga masiva de información catastral. Este permite, a través de la Sede Electrónica del Catastro, descargarse la cartografía pública de este organismo en formato vectorial, así como la información alfanumérica (archivos cat). La idea como se comenta en el la presentación de la Jornada, es mediante el acceso a la información, promover la creación de empresas, empleo y avanzar en un uso mas transparente de la información por parte de los ciudadanos.

Es una buena noticia que los organismos oficiales empiecen a poner los datos a disposición pública. Puede que técnicamente todavía no sea la mejor manera, ya que de momento existen algunas limitaciones, como la descarga por municipio que hace extremadamente tedioso descargarse la información para grandes zonas, la necesaria identificación mediante firma electrónica, rellenar una encuesta de utilización, indicarle una estimación de costes o de tiempo que se tardaría en obtener dicha información o la inexistencia de un API pública de acceso a los datos, pero se agradece la linea en la que se ha gestionado la idea.

Aun así sigue dando la impresión de que los organismos públicos son reticentes a liberar su información, de que les cuesta acercarse a un modelo de datos totalmente abiertos que es la base para la transparencia y el desarrollo de una sociedad. El hecho de tener que identificarse mediante firma electrónica a la hora de acceder a la información da la impresión de que a pesar de la buena intención, queda patente un intento de que parezca que se tiene control sobre las descargas, como si en algún momento alguien pudiese dedicarse a comprobar la utilización que se ha hecho de esos datos y responsabilizar a la persona que realizó la descarga. No es que se dude de la capacidad para hacer esto, sino mas bien de su utilidad.

Además se exige que los datos han de ser transformados antes de su publicación, para evitar ofrecer el servicio para el que está destinado la misma DGC. Por transformación hace referencia a los términos establecidos en la Ley de Propiedad Intelectual, o sea, “traducción, adaptación y cualquier modificación de su forma de la que se derive una obra diferente”, lo que da pie al debate sobre lo que entendemos nosotros como transformación, ¿cambiar los estilos?, ¿traducir el nombre de las calles?, ¿transformar el sistema de coordenadas?, o ¿mover las geometrías un milímetro?. En el mismo Artículo 21 hace referencia a que una reordenación de la base de datos se considera una transformación, ¿cargar esos datos en nuestra base de datos es una transformación?.

Sin dudar del esfuerzo que han hecho desde la DGC por poner estos datos a nuestra disposición, no tenemos mas que alegrarnos por la iniciativa y sacar provecho de ella.

Referencias:

[1] Información de la Jornada: http://www.catastro.meh.es/jornada_dm/jornada.asp

[2] Artículo 21 del Real Decreto Legislativo 1/1996, de 12 de abril, por el que se aprueba el Texto Refundido de la Ley de Propiedad Intelectual, regularizando, aclarando y armonizando las disposiciones legales vigentes sobre la materia. http://noticias.juridicas.com/base_datos/Admin/rdleg1-1996.l1t2.html#a21

[3] Manual de usuario para descarga información alfanumérica en formato CAT http://www.catastro.meh.es/ayuda/manual_descargas_cat.pdf

[4] Consulta masiva, Sede Electrónica del Catastro https://www.sedecatastro.gob.es/OVCFrames.aspx?TIPO=TIT&a=masiv

[5] Resolución de 23 de Marzo de 2011, de la Dirección General del Catastro, por la que se aprueban los criterios de acceso, formatos de entrega, y condiciones de la licencia-tipo para el acceso al servicio de descarga masiva de datos y cartografía, a través de la sede electrónica del Catastro http://www.catastro.meh.es/ayuda/legislacion/ovc/resoluciondgc20110323_tfs.pdf

Terr@sit en la Gaceta Tecnológica


De vuelta de la LSWC me entretuve muy temprano en el aeropuerto de Málaga leyendo un ejemplar de la Gaceta Tecnológica que había cogido en el congreso y que todavía no había podido leer. Andaba yo con mi café con leche y bizcocho cuando en el apartado dedicado a la geomática de esta estupenda publicación veo una noticia que me termina de despertar: “La Comunidad Valenciana pone en marcha la primera cartografía digital en 3D de España“.

Así que nada me pongo a leer la noticia y cada párrafo me hacía abrir un centímetro más la mandíbula, básicamente va transcribiendo frases de la presentación del proyecto Terr@sit por parte del Muy Honorable Señor. Está claro que un político no suele acertar demasiado con las orientaciones técnicas reales de un proyecto cuando se presenta, pero hay bastantes perlas en el artículo que me han sorprendido (para mal, claro). De hecho tantas que en lugar de ponerlas aquí directamente las he puesto de una forma alternativa y muy “web 2.0”. He subrayado y anotado la noticia, y se pueden visitar aquí.

Y es que me resultan muy tristes una serie de puntos:

  • Que uno vaya a la web de servicios WMS del ICV y tenga cuatro capas, con 2004 como el año de la última ortofoto publicada
  • Que el portal Terr@sit ofrezca un visor 3D que sólo funciona en Windows, y al resto de usuarios de MacOS y Linux que nos denTerr@sit fail
  • Que la esperanzadora etiqueta de Geoservicios lleve a una página de descargas de archivos GeoPDF un formato que sólo puede visualizarse correctamente con el visor de Adobe (a partir de la versión 6) y que por tanto de servicio tiene poco.
  • Que se diga que los autónomos y pymes se beneficiarán de este visor, ¿alguien me puede explicar cómo?
  • Que se diga que todos los valencianos vamos a gozar de la misma información, cuando mucha de la información de ese portal sólo está accesible mediante el visor (bueno esto no es del todo cierto, luego hablo más) o directamente hay que ir a comprarla al ICV.

En fin, el artículo tiene más perlas que se pueden ver en mis notas, pero estas eran las más gordas. Al menos de todo esto he sacado algo positivo. En primer lugar comprobar que el uso del software libre en el proyecto, ya que el portal está realizado usando OpenLayers y JQuery y en el servidor el ICV sigue apostando por UMN Mapserver como tecnología base.

Y la segunda viene derivado del uso de UMN Mapserver, y esto hay que agradecerlo seguramente a los técnicos que hay detrás del proyecto que se han preocupado de configurarlo correctamente. Resulta que realmente no sólo tenemos un visor, sino un servidor WMS no publicitado para acceder a la cartografía del portal. Desgraciadamente gvSIG no negocia bien el acceso a este servidor por algún problema entre versiones del protocolo WMS que por lo que sé, debería resolverse a medio plazo, pero al menos desde otras aplicaciones de webmapping podemos usar estas pocas capas, ya que el capabilities no dice nada al respecto. La url del servicio es

http://terramapas.icv.gva.es/cgi-bin/mapserv.fcgi?map=/var/www/portal/map/servidor.map

En fin, esta perorata al final va de que Terr@sit ni ofrece abiertamente como servicios estándar la cartografía de la que se nutre, y que para cumplir con INSPIRE al menos debería estar catalogada en algún servidor (¿el de la CMA por ejemplo?) ni cumple con la necesaria neutralidad tecnológica al limitar sus servicios a usuarios de un sistema operativo concreto. Esto último probablemente incumpla alguna directiva nacional pero ahí ya no entro porque la verdad es que no tengo ni idea, si alguien puede confirmar o desmentir esto se agradecería un comentario.