Datos, bien, pero, ¿y APIs?

[cjgb]

Colgar datos, con o sin preproceso está bien. Pero en las más de las situaciones no es ni necesario ni deseable: p.e., no quiero bajarme todos los shapefiles de España para pintar los contornos municipales de un mapa de Madrid y alrededores. Mejor, puedo consultar la API de Cartociudad y tengo las capas que quiera: códigos postales, secciones censales, etc. También puedo usar la API de Cartociudad para geolocalizar direcciones sin las restricciones de GoogleMaps. Pero no quiero ni necesito la base de datos sobre la que está construido el servicio.

Hay proyectos tales como rOpenSci que fomentan la creación de herramientas para consultar distintas APIs públicas (y semipúblicas) de interés científico programáticamente (en este caso, desde R).

En España hay pocas APIs disponibles para la consulta de datos públicos; p.e., el INE, p.e., que yo sepa, no tiene ninguna (más allá del servicio WMS de secciones censales). Pero la creación de interfaces bien documentados y explicados para las distintas APIs existentes para los lenguajes de programación más populares podría servir tanto para poner en valor esos servicios como para animar a popularizarlos entre las administraciones públicas.

[fesja]

@cjgb muy de acuerdo, pero hacer la API es segunda fase. Es decir, primero necesitamos tener los datos. Y una vez conseguidos, ya podemos hacer la API con esos datos.

Podemos ir pensándola eso si. Si tienes tiempo, cuéntanos cómo la veríais o qué recursos necesitarías. Gracias!

[cjgb]

@fesja, no me refiero a construir un API contra los datos de CodeForSpain sino a que CodeForSpain contemple también la creación de software que facilite la consulta de APIs ya disponibles de datos públicos (Cartociudad es un ejemplo) en los lenguajes de programación más habituales (p.e., Python).

Hay un ejemplo aquí. Es una lista de paquetes de R para consultar programáticamente APIs abiertas al público.

[fesja]

@cjgb ah vale, crear librerías entonces que ataquen el servicios web de datos.gob.es y similares. Tiene mucho sentido sí. Por ejemplo, en populatetools han hecho esto https://github.com/PopulateTools/ine-places

[inigoflores]

Pensaba que esa era la idea: Además de alojar ciertas fuentes (según lo acordado en #8), también pondremos a disposición del público las herramientas para la descarga directa desde la fuente original (según hemos comentado en #9). La novedad que introduce el comentario de @cjgb es incluir funcionalidad en estas herramientas que permitan la consulta y filtrado de los datos, lo que me parece una magnifica idea. Por cierto, muy interesante la iniciativa rOpenSci!.

Con respecto a la gema INE Places, parece más un wrapper para los datos del INE descargados previamente en formato CSV, que una herramienta de consulta de las fuentes originales (si no me equivoco).

[fesja]

@inigoflores tienes razón, es más un wrapper. Vamos a ver cada fuente por separado y decidimos. Ya nos toca entrar al lío :)

[jgsogo]

El problema de las APIs es que requiere montar un server para que estén en ejecución... con todo lo que eso implica y no sé si quedaría fuera del alcance de esta iniciativa.

La otra opción es tener una librería que levante un servidor con API en local, o bien un paquete (realmente varios, uno por cada lenguaje de programación que queramos soportar) que acceda a los datos de forma conveniente (tanto si residen en su fuente original como si los tenemos almacenados nosotros)

[fpedrera]

Para montar APIs sobre datos (fácil) podéis:

1. Usar CartoDB: http://docs.cartodb.com/cartodb-platform/sql-api/
2. Usar CKAN: http://docs.ckan.org/en/ckan-1.7.1/using-data-api.html

Dependerá de la licencia del dato, a lo mejor no podéis alojarlo en vuestros servidores y sólo enlazar al repo original. Esto es algo que CKAN puede hacer (almacena los metadatos, pero no el dato).

En CartoDB ya hay una librería de datos públicos importante, tal vez sería más práctico poblar esa librería que crear vuestra propia infraestructura (o cualquier otra que ya exista). Preguntadles a los chicos de CartoDB...

[jorgeas80]

Aparte de consultar otras APIs, también puede ser interesante consultar fuentes de datos públicos con formatos menos procesables de manera automática. HTML, por poner uno sencillo.

No hace mucho he tenido que programar un par de scrapers para obtener datos de índices bancarios, actualizados mensualmente. También, para un par de proyectos personales, he hecho scrapers que obtienen películas recién estrenadas en cine, y horarios de cercanías.

El problema de tener los scrapers corriendo en una máquina, lo solucioné usando el cloud de scrapy: http://scrapinghub.com/scrapy-cloud/

[palmerabollo]

Hola. Me he topado con esta issue de 2016. No sé en qué estado está el proyecto "code for spain" (parece tener poca actividad reciente), pero me gustaría comentaros que he estado trabajando un tiempo en un proyecto (egov) para exponer datos públicos a través de un API GraphQL.

Hay un portal divulgativo https://palmerabollo.github.io/egov e información más técnica en https://github.com/palmerabollo/egov, junto con algún ejemplo real 100% funcional. Si le echáis un ojo y a alguien le parece interesante, quizá se puedan unificar algunos esfuerzos y tratar de relanzar alguna cosa, ya que es imposible hacer y mantener proyectos de esta envergadura en solitario.