Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Datos abiertos #9

Open
voodoorai2000 opened this issue Oct 21, 2015 · 14 comments
Open

Datos abiertos #9

voodoorai2000 opened this issue Oct 21, 2015 · 14 comments
Labels

Comments

@voodoorai2000
Copy link
Member

Objetivo

La página deberá ser capaz de importar datos en forma tabular originados de excel/csv.

Notas:

  • Por motivos administrativos el backend debe ser PostgreSQL (es posible hacer uso de configuraciones avanzadas de postgresql como hstore)
  • Los administradores deben poder subir tipos de ficheros nuevos sin tener que pedir a los desarrolladores que implementen un modelo nuevo a medida para cada tipo.
  • Los datos importados deberán tener un "tipo" (al importar el fichero se podrá utilizar un tipo ya existente o crear uno nuevo)
  • Si se importan datos de tipos ya existentes, la página debe chequear que las columnas de los nuevos datos coinciden con las existentes
  • Los datos obtenidos deben después poder ser mostrados descargados al menos en csv.
  • Idealmente, las páginas informativas ( Páginas informativas #8 ) deberían poder listar al menos los registros de una categoría en formato tabla.

Extras:

  • Idealmente los administradores tendrían que poder editar los datos tabulados (por ejemplo para eliminar duplicados)
  • Punto extra si se guarda la metainformación relativa a quién y cuándo hizo la importación/modificación de cada registro.
  • Punto extra si se desarrolla como gema independiente, que se pueda incluir en otros proyectos fácilmente.

Referentes:

http://opendata.aragon.es/
http://ckan.org/

Datos:

http://datos.madrid.es/portal/site/egob/

@ianvatega
Copy link

Referencias sobre transparencia

@voodoorai2000
Copy link
Member Author

Gracias por los videos @ianvatega! La interfaz de Zaragoza esta genial!

@dgilperez
Copy link

Buenos días!

Esta tarea me parece muy interesante!

Me gustaría poder colaborar, pero estoy en remoto. ¿Hay algún equipo ya con esto?

@voodoorai2000
Copy link
Member Author

Grande @dgilperez! Toda tuya :)

@dgilperez
Copy link

Ole, toda entera para mi? 😄

Pues le voy a dar una vuelta a las referencias y vuelvo por aquí con ideas. Tengo ya algunas dudas sobre el alcance, pero prefiero estudiar y volver en un ratito con ellas.

Parece efectivamente una tarea clara para sacar una gema independiente. ¿Propuesta de nombres? ¿Tin-opener, por aquello de abrir latas de datos ;)?

@voodoorai2000
Copy link
Member Author

Genial!
+1 tin-opener

@dgilperez
Copy link

@voodoorai2000 estaba revisando las referencias que citas y me surgen dudas, quizás porque no estoy allí con vosotros:

  • ¿Vamos a usar CKAN como base para publicar los datos? Entonces: ¿esta gema realmente sería un conector con CKAN, para tipos de datos que no estén directamente soportados allí? Opendata Aragon tiene algo así, en python: https://github.com/aragonopendata/Python
  • ¿O, por el contrario, se trata de replicar funcionalidad de CKAN? Si es así, la primera pregunta sería por qué hacerlo de cero y no usar CKAN directamente, que parece que está muy bien, pero asumo que ya lo habéis valorado y ¿qué funcionalidad exacta hay que replicar en cuanto a la carga de datos? Si habéis hecho ese ejercicio, puedo enfocar más el alcance probando un CKAN local.

Aparte de esto, dudas y consideraciones sobre alcance:

  • Tendría que soportar un modelo DataType, que tenga información del tipo concreto. Esta sería: estructura de cabeceras, ¿y qué más?
  • Para almacenar los datos, ¿estamos hablando de almacenar cada dato (cada columna de cada excel de cada tipo) en entradas independientes de DB, o simplemente almacenamos el CSV / Excel en un Posgresql usando hstore, o incluso el fichero en S3 / similar? Evidentemente lo primero permitiría mejorar la visualización o procesado, pero no sé si este es el alcance buscado. Dicho de otra forma, cuando nos referimos a un "Registro", entendemos "encuesta semanal de calidad de vida, semana 43 2015, CSV", o entendemos "fila uno de la encuesta [...]". En este sentido, me despista el requerimiento "Si se importan datos de tipos ya existentes, la página debe chequear que las columnas de los nuevos datos coinciden con las existentes".
  • Esta gema tiene toda la pinta de ser una Rails Engine, montable en alguna ruta concreta, y que ofrezca una API para cargar, procesar y almacenar los datos. ¿Estamos de acuerdo?

Me voy a comer, a la vuelta arranco motores 👍

@kikito
Copy link
Member

kikito commented Oct 24, 2015

Esta sería: estructura de cabeceras, ¿y qué más?

Pues en principio eso es lo que necesita. Eso y un nombre. Sugiero estudiar el nombre DataSet más que DataType (DataSet has_many :records?)

Para almacenar los datos, ¿estamos hablando de almacenar cada dato (cada columna de cada excel de cada tipo) en entradas independientes de DB, o simplemente almacenamos el CSV / Excel en un Posgresql usando hstore, o incluso el fichero en S3 / similar? Evidentemente lo primero permitiría mejorar la visualización o procesado, pero no sé si este es el alcance buscado.

Lo que yo había pensado era tener una instancia de record por "fila del excel", utilizando hstore para los "valores de los campos de la fila". Así podríamos hacer manejo básico de datos en la tabla (tipo: ordenar o filtrar). Si tuviéramos libertad para poder elegir la tecnología, para este punto a lo mejor habría buscado algo nosql para esto (Mongo). Pero tenemos la limitación de usar postgres, y hstore es un poco el "nosql para postgres". Aun así estamos abiertos a sugerencias. Pero sí, el requerimiento de "poder mostrar y filtrar" nos lo han dado.

entendemos "encuesta semanal de calidad de vida, semana 43 2015, CSV", o entendemos "fila uno de la encuesta [...]".

Lo segundo ("fila uno de la encuesta").

me despista el requerimiento "Si se importan datos de tipos ya existentes, la página debe chequear que las columnas de los nuevos datos coinciden con las existentes".

El escenario es: subo un nuevo fichero con las columnas "nombre, edad y salario" y lo meto en un nuevo dataset llamado "Personas". Luego subo un segundo fichero, lo asocio al dataset existente ("Personas") pero las columnas del nuevo fichero son "nombre, sexo y salario". El programa debe dar un error y decir "el dataset Personas" tiene la columna edad y no tiene la columna sexo".

Esta gema tiene toda la pinta de ser una Rails Engine, montable en alguna ruta concreta, y que ofrezca una API para cargar, procesar y almacenar los datos. ¿Estamos de acuerdo?

Totalmente de acuerdo 👍

@voodoorai2000
Copy link
Member Author

CKAN lo tenemos en el radar y nos gusta mucho. Si se pudiera utilizar sería genial.
Parece que hay una gema en Ruby https://github.com/apohllo/CKAN

@kikito
Copy link
Member

kikito commented Oct 24, 2015

Sobre CKAN: aunque haya una gema de ruby para leer de CKAN, tendríamos que tener una instalación de CKAN en los servidores del ayuntamiento. Y alguien tendría que mantenerla etc.

Aunque CKAN esté muy bien, creo que si asumimos que lo podemos utilizar, puede que luego lo tengamos que echar para atrás.

@dgilperez
Copy link

Aquí os dejo puntero a una primerísima y completamente work-in-progress versión de lo que queremos hacer en esta tarea:

https://github.com/dgilperez/tin_opener

Instrucciones de montaje en el README.

Mañana podré echarle otro rato, a ver si conseguimos dejarlo usable para esta primera versión. Si tenéis algún comentario ya (insisto, WIP), muy bienvenido.

@voodoorai2000
Copy link
Member Author

Espectacular @dgilperez! 😮 👏👏👏

Yo seguiría con unos buenos specs y una rake para parsear unos cuantos data sets. Igual la rake ya tendría que ser parte del proyecto de transparencia en sí.

@dgilperez
Copy link

Sí, aún tengo que investigar cómo montar los specs en un engine, en una horita o así estaré con ello.

No había pensado en la rake, me parece buena idea. De fuente de datos, todos los CSV de un directorio, por ejemplo, o fichero a fichero? O quizás una URL? Si se hace genérica, puede pertenecer a la gema, y luego montar en el proyecto una tarea que la herede o incluya.

También falta que la interfaz ofrezca la posibilidad de reutilizar un dataset, o crear uno nuevo, creo que eso sale hoy.

¿Hay plan de usarlo para parsear datos para el proyecto hoy? Lo digo por mandar una PR y testar con esas fuentes de datos.

@kikito
Copy link
Member

kikito commented Oct 25, 2015

Hola,

He echado un vistazo a tin_opener y tiene buena pinta!

No creo que haga falta utilizarlo para para parsear datos hoy - pero se puede meter para probar.

@dgilperez dgilperez mentioned this issue Oct 26, 2015
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants