search

codeforspain / ds-organizacion-administrativa

Listado de comunidades, provincias, municipios con su correspondiente código INE
15 stars 15 forks source link

Primera versión. Feedback por favor #1

Closed inigoflores closed 8 years ago

inigoflores commented 8 years ago

Ya he subido una primera versión. Iba a pedir feedback antes de ponerme a picar código, pero al final he decido empezar con algo para ir dándole forma. He empezado con los municipios.

He incluido un datapackage.json, que no sé si es del todo correcto, aunque parece que está bien formateado: Organiazación Administrativa de España en DataPackage Viewer. Mola! :)

Dudas:

Cualquier comentario o crítica es bienvenido!

inigoflores commented 8 years ago
saleiva commented 8 years ago

Que estas pensando para las geometrías?

jalbertoroman commented 8 years ago

Las geometrias están aquí: https://github.com/codeforspain/ds-limites-administrativos y quizas lo veo como @saleiva, creo que deberían ir juntas, no entiendiendo la separación! Propongo unir los repositorios. En muchas ocasiones este tipo de datos, dan lugar a confusiones si no van asociados a una geometría.

saleiva commented 8 years ago

Si, por eso preguntaba. Creo que deberían ir juntos (como polígonos y no como líneas). Si no, vamos a acabar teniendo un montón de columnas duplicadas en ambos datasets, o teniendo que hacer el crunching muchas mas veces de lo deseado.

jalbertoroman commented 8 years ago

Por mi parte cerramos el repo de límites-administrativos y que se incluyan las geometrías en este. @inigoflores dime lo que necesitas y te ayudo en este repo.

inigoflores commented 8 years ago

Puede ser, aunque quizás no es mala idea mantenerlos separados.

Motivos:

Si pensamos en este dataset como un "Core Dataset", tiene sentido mantenerlo separado. Echadle un vistazo a http://data.okfn.org/roadmap/core-datasets.

Con respecto a la duplicidad de columnas, sigo pensando que el campo nombre se puede obviar en otros datasets, pues el código INE es suficiente para identificar el dato (geometría, dato de empleo, pib, etc.). Sin embargo, se acordó mantenerlo.

Si se elimina, podríamos crear una herramienta que combine datasets, y así tener la posibilidad de obtener, por ejemplo, el listado de geometrías con sus denominaciones en inglés.

saleiva commented 8 years ago

Si lo veis claro adelante, pero...

Por lo general, creo que hay que pensar en en quien va a tirar de estos datos y en que la mayor parte de la gente no se va a poder poner a hacer herramientas de merge de diferentes datasets.

Lo que comentas del código INE es cierto pero también te obliga a partir de ahí para todo. En muchos casos es meter una capa de complejidad enorme que se soluciona poniendo el nombre más común. On Apr 26, 2016 8:28 PM, "Iñigo Flores" notifications@github.com wrote:

Puede ser, aunque quizás no es mala idea mantenerlos separados.

Motivos:

  • Este repo "maestro" sirve de referencia a otros datasets. Permite validar los datos y comprobar si falta información. Esta fue la razón principal de su concepción: Ver codeforspain/datos#22 https://github.com/codeforspain/datos/issues/22.
  • Hay ocasiones en que no se necesitan geometrías.
  • Buenas prácticas: Separation of Concerns / Single Responsibility. Normalización de la BD.
  • Un repo dedicado mejora la calidad de los datos ofrecidos (histórico, denominaciones en otros idiomas, etc.).
  • Puede ser que para alguna organización administrativa no existan geometrías.
  • Reduciendo el tamaño de los datasets (dentro de una clasificación lógica) podemos avanzar más deprisa y tener la sensación de ir cumpliendo objetivos.

Si pensamos en este dataset como un "Core Dataset", tiene sentido mantenerlo separado. Echadle un vistazo a http://data.okfn.org/roadmap/core-datasets.

Con respecto a la duplicidad de columnas, sigo pensando que el campo nombre se puede obviar en otros datasets, pues el código INE es suficiente para identificar el dato (geometría, dato de empleo, pib, etc.). Sin embargo, se acordó mantenerlo.

Si se elimina, podríamos crear una herramienta que combine datasets, y así tener la posibilidad de obtener, por ejemplo, el listado de geometrías con sus denominaciones en inglés.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/codeforspain/ds-organizacion-administrativa/issues/1#issuecomment-214840647

saleiva commented 8 years ago

A todo esto, otra idea es crear un dataset derivado de este y del de geometrías a parte y mantener este como parte del core que comentas. On Apr 26, 2016 8:57 PM, "Sergio Alvarez Leiva" saleiva@gmail.com wrote:

Si lo veis claro adelante, pero...

Por lo general, creo que hay que pensar en en quien va a tirar de estos datos y en que la mayor parte de la gente no se va a poder poner a hacer herramientas de merge de diferentes datasets.

Lo que comentas del código INE es cierto pero también te obliga a partir de ahí para todo. En muchos casos es meter una capa de complejidad enorme que se soluciona poniendo el nombre más común. On Apr 26, 2016 8:28 PM, "Iñigo Flores" notifications@github.com wrote:

Puede ser, aunque quizás no es mala idea mantenerlos separados.

Motivos:

  • Este repo "maestro" sirve de referencia a otros datasets. Permite validar los datos y comprobar si falta información. Esta fue la razón principal de su concepción: Ver codeforspain/datos#22 https://github.com/codeforspain/datos/issues/22.
  • Hay ocasiones en que no se necesitan geometrías.
  • Buenas prácticas: Separation of Concerns / Single Responsibility. Normalización de la BD.
  • Un repo dedicado mejora la calidad de los datos ofrecidos (histórico, denominaciones en otros idiomas, etc.).
  • Puede ser que para alguna organización administrativa no existan geometrías.
  • Reduciendo el tamaño de los datasets (dentro de una clasificación lógica) podemos avanzar más deprisa y tener la sensación de ir cumpliendo objetivos.

Si pensamos en este dataset como un "Core Dataset", tiene sentido mantenerlo separado. Echadle un vistazo a http://data.okfn.org/roadmap/core-datasets.

Con respecto a la duplicidad de columnas, sigo pensando que el campo nombre se puede obviar en otros datasets, pues el código INE es suficiente para identificar el dato (geometría, dato de empleo, pib, etc.). Sin embargo, se acordó mantenerlo.

Si se elimina, podríamos crear una herramienta que combine datasets, y así tener la posibilidad de obtener, por ejemplo, el listado de geometrías con sus denominaciones en inglés.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/codeforspain/ds-organizacion-administrativa/issues/1#issuecomment-214840647

saleiva commented 8 years ago

Puedo encargarme yo de eso On Apr 26, 2016 8:59 PM, saleiva@gmail.com wrote:

A todo esto, otra idea es crear un dataset derivado de este y del de geometrías a parte y mantener este como parte del core que comentas. On Apr 26, 2016 8:57 PM, "Sergio Alvarez Leiva" saleiva@gmail.com wrote:

Si lo veis claro adelante, pero...

  • ok, pero esa validación puede hacerse de dos fuentes.
  • hay otras tantas en las que si.
  • hacer los datos más accesibles debería servir como buena práctica.
  • no es mejorar la calidad meter columnas clave para los datos?
  • ok.

Por lo general, creo que hay que pensar en en quien va a tirar de estos datos y en que la mayor parte de la gente no se va a poder poner a hacer herramientas de merge de diferentes datasets.

Lo que comentas del código INE es cierto pero también te obliga a partir de ahí para todo. En muchos casos es meter una capa de complejidad enorme que se soluciona poniendo el nombre más común. On Apr 26, 2016 8:28 PM, "Iñigo Flores" notifications@github.com wrote:

Puede ser, aunque quizás no es mala idea mantenerlos separados.

Motivos:

  • Este repo "maestro" sirve de referencia a otros datasets. Permite validar los datos y comprobar si falta información. Esta fue la razón principal de su concepción: Ver codeforspain/datos#22 https://github.com/codeforspain/datos/issues/22.
  • Hay ocasiones en que no se necesitan geometrías.
  • Buenas prácticas: Separation of Concerns / Single Responsibility. Normalización de la BD.
  • Un repo dedicado mejora la calidad de los datos ofrecidos (histórico, denominaciones en otros idiomas, etc.).
  • Puede ser que para alguna organización administrativa no existan geometrías.
  • Reduciendo el tamaño de los datasets (dentro de una clasificación lógica) podemos avanzar más deprisa y tener la sensación de ir cumpliendo objetivos.

Si pensamos en este dataset como un "Core Dataset", tiene sentido mantenerlo separado. Echadle un vistazo a http://data.okfn.org/roadmap/core-datasets.

Con respecto a la duplicidad de columnas, sigo pensando que el campo nombre se puede obviar en otros datasets, pues el código INE es suficiente para identificar el dato (geometría, dato de empleo, pib, etc.). Sin embargo, se acordó mantenerlo.

Si se elimina, podríamos crear una herramienta que combine datasets, y así tener la posibilidad de obtener, por ejemplo, el listado de geometrías con sus denominaciones en inglés.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/codeforspain/ds-organizacion-administrativa/issues/1#issuecomment-214840647

inigoflores commented 8 years ago

Ejemplo de lo que digo:

More info about countries can be get from datapackage https://github.com/datasets/country-codes by a join on field ISO3166-1-Alpha-3

En geo-countries, además del código ISO se incluye el nombre (redundante, pero se ve que necesario).

@saleiva tu tienes infinitamente más experiencia que yo en estos temas, y conoces la problemática mejor que nadie.

Lo que decidáis me parecerá bien.

saleiva commented 8 years ago

Yo creo que lo mejor es lo que decías. Sigamos con este dataset como base, y si a caso preparemos una versión mergeada con geométrias y algunos datos más a-la-naturalearthdata

:)

On Tuesday, 26 April 2016, Iñigo Flores notifications@github.com wrote:

Ejemplo de lo que digo:

More info about countries can be get from datapackage https://github.com/datasets/country-codes by a join on field ISO3166-1-Alpha-3

En geo-countries, además del código ISO se incluye el nombre (redundante, pero se ve que necesario).

@saleiva https://github.com/saleiva tu tienes infinitamente más experiencia que yo en estos temas, y conoces la problemática mejor que nadie.

Lo que decidáis me parecerá bien.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/codeforspain/ds-organizacion-administrativa/issues/1#issuecomment-214853731

Sergio Alvarez Leiva

jalbertoroman commented 8 years ago

Yo creo que nos estamos desviando un poco de uno de los objetivos, hacer accesibles los datos. Seguir las mejores prácticas de tratamiento, normalización... desde mi punto de vista aleja a mucha gente del uso de los datos. Ya que estamos añadiendo capas de complejidad y reduciendo el alcance.

Lo que alguien no desarrollador quiere, es por ejemplo, pillar un geojson subirlo a CartoDB y empezar a ver cosas y jugar con ello... en este sentido estoy con @saleiva. Creo que esto es clave para que esta iniciativa llegue a profesiones como la periodística. (El datapackage es estupendo, pero lo que quiere la mayoría de la gente es un pantallazo de los campos del csv o de los polígonos)

Y creo que esto enlaza con uno de los problemas que a @fesja le están transmitiendo los responsables de datos de la admin públicas, no se usan los datos... creo que es porque, algunas veces hay que saber latín solo para abrir el archivo... ;)

fesja commented 8 years ago

Estoy de acuerdo con qué no debemos obligar a hacer merge. Los datasets deben tener todos los datos básicos (nombres municipios y código ine). El código INE para asegurar la calidad y poder unir datos y el nombre para hacerlo más cómodo.

Yo mantendría dos ficheros distintos, uno con el listado simplemente y otro además con geometrías. Pueden estar en el mismo repo o en separados. Igual en el mismo repo es suficiente...

@jalbertoroman si siguiéramos las mejores prácticas de tratamiento y normalización estaríamos haciendo RDF o linked data :P. Mientras no sea necesario hacer merge de datasets para hacer algo básico yo creo que no estamos añadiendo capas de complejidad.

El datapackage nos sirve sobre todo para nosotros y si metemos algo tipo ckan en el futuro. Para el periodista está claro que no servirá.

El problema de que no se usan los datos no es que los ficheros sean complicados, si no que no hay difusión, necesidad o suficientes datos interesantes. Pero los actuales excels o csvs no son complicados. Hoy uno me ha confirmado que nadie se baja los ficheros RDFs, esos si son complicados.

jalbertoroman commented 8 years ago

borrar una columna, siempre es más sencillo que añadirla.

inigoflores commented 8 years ago

@jalbertoroman no podemos dirigir nuestros esfuerzos a una sola audiencia y asumir que los datos solo los van a usar los no desarroladores. Esto iría en contra del principio nº4 del decálogo de principios de datos abiertos que nos recuerda @jpaulet en codeforspain/datos#7

4) Accesibles: Los datos están disponibles para la gama más amplia de usuarios para la más amplia gama de propósitos.

Así mismo, agrupar datasets puede ir en contra del 2º principio:

2) Primarios: Los datos se recogieron como en la fuente, con el más alto nivel posible de granularidad, no en formas agregadas o modificadas .

En mi caso (para el proyecto en el que estoy trabajando ahora) necesito tener los datos de los municipios con el mayor nivel de fiabilidad posible. También necesito esa información desglosada por años, pues no tener en cuenta un dato de segregación o agrupación de municipios puede suponer que un cliente acabe pagando casi el doble de impuestos. No veo de qué manera se facilita el acceso a esta información creando un gigantesco GeoJSON del cual hay que extraer el código INE y el nombre del municipio.

Me resulta mucho más fácil invocar lo siguiente:

inigo@XPS13:~/code/crm$ dpm install https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/datapackage.json
dpm http GET https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/municipios.csv
dpm http GET https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/municipios_historical.csv
dpm http GET https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/provincias.csv
dpm http GET https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/autonomias.csv
dpm http GET https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/municipios_islas.csv
dpm http GET https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/municipios_islas_historical.csv
dpm http GET https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/islas.csv
dpm http 200 https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/provincias.csv
dpm http 200 https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/autonomias.csv
dpm http 200 https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/municipios_islas.csv
dpm http 200 https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/municipios.csv
dpm http 200 https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/islas.csv
dpm http 200 https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/municipios_islas_historical.csv
dpm http 200 https://raw.githubusercontent.com/codeforspain/ds-organizacion-administrativa/master/data/municipios_historical.csv
.
└─┬ datapackages
  └─┬ ds-organizacion-administrativa
    ├── datapackage.json
    └─┬ data
      ├── municipios.csv
      ├── municipios_historical.csv
      ├── provincias.csv
      ├── autonomias.csv
      ├── municipios_islas.csv
      ├── municipios_islas_historical.csv
      └── islas.csv
inigo@XPS13:~/code/crm$  csvsql --insert --db mysql://user:pass@192.168.33.10/crm datapackages/ds-organizacion-administrativa/data/municipios.csv

dpm = Data Package Manager.

Ahora... entiendo perfectamente que esto no es para todo el mundo, y que gente con un perfil no técnico pueda necesitar la información de varios datasets ya fusionados en uno solo. Me parece genial lo que propone @saleiva de crear repos que ofrezcan datasets pre-empaquetados con aquellas columnas que más se usen, como hace Natural Earth Data, que añade un montón de campos junto con la geometría (ejemplo).

Podríamos incluso crear una utilidad de "empaquetado bajo demanda", alojada en www.codeforspain.org, que permitiera seleccionar columnas de varios datasets.

borrar una columna, siempre es más sencillo que añadirla.

Puede ser, pero hay herramientas muy potentes que facilitan enormemente el trabajo, como p.e. csvkit. Se pueden hacer cosas como:

csvjoin -c codigo_ine municipios.csv municipios_geometrias.csv > municipios_custom.csv

La columna codigo_ine debe existir en ambos datasets.

Es a modo de ejemplo, pues no sé si procede convertir las geometrías a CSV. Seguro que hay formas sencillas de combinar los datasets con independencia del formato.

fesja commented 8 years ago

@inigoflores @jalbertoroman @saleiva 

- data
   - listado
      - historico
         - municipios.csv/.json
      - autonomias.csv/.json
      - provincias.csv/.json
      - municipios.csv/.json
      - islas.csv/.json
   - geografias
      - autonomias.geojson
      - provincias.geojson
      - municipios.geojson
      - islas.geojson

¿Alguna otra duda que se me ha olvidado responder? ¿ok con todo o hay algo que chirría mucho? :)

inigoflores commented 8 years ago

Los datasets que toquemos deben estar listos para usarse directamente, tanto para desarrolladores como para no desarrolladores; por tanto habrá información duplicada en diversos repos (nombres).

No tengo ningún problema con esto. Pero en los “core” datasets reduciría a un mínimo la información a duplicar, e intentaría normalizar las tablas todo lo posible (dentro de unos margenes aceptables).

Para facilitar el uso de los datos a los usuarios finales no técnicos, haría lo que ha sugerido @saleiva. Podemos preparar uno o varios datasets que usan como dependencias los “core” datasets y se generan mediante joins. Esto es bastante sencillo. Un ejemplo es este experimento que he hecho para los códigos postales, donde el callejero del INE no proporciona el nombre del municipio, y no queda otra que hacer un merge con la lista de municipios de ds-organizacion-administrativa.

En este ejemplo, tener muchos campos duplicados significa tener que descargar archivos más grandes, y tener que andar eliminando columnas con csvcut .

¿por qué separas el código INE en diversos campos? Yo lo dejaría junto.

Hecho!

Sobre si incluir CSV y JSON en el datapackage creo que si deberían estar ambos, porque este archivo es leído por una máquina y dice a otros repos qué datasets y en qué formatos están disponibles.

Ok, incluido. Aunque echadle un vistazo a este issue codeforspain/datos#25

Los otros temas los he pasado a issues separados.

fesja commented 8 years ago

Ver https://github.com/codeforspain/datos/issues/26, propongo una pausa en estos debates

inigoflores commented 8 years ago

Ok. He cerrado todos los issues para no distraer la atención. Ya los reabrimos si procede.