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

Organización y nombes de los ficheros JSON #23

Closed
fesja opened this issue Apr 17, 2016 · 6 comments
Closed

Organización y nombes de los ficheros JSON #23

fesja opened this issue Apr 17, 2016 · 6 comments

Comments

@fesja
Copy link
Contributor

fesja commented Apr 17, 2016

Hola,

@jalbertoroman ya ha sacado los límites administrativos de España. Los podéis ver aquí https://github.com/codeforspain/ds-limites-administrativos/tree/master/data. Gracias alberto!!

De cara a homogeneizar la organización de la carpeta data en todos los repos con características parecidas, abro esta issue.

Una pregunta @jalbertoroman, ¿has separado Canarias del resto porque así estaba en la fuente original o por algo en concreto? Si se juntan porque no hay contras, podríamos necesitar solo 3 ficheros.

  • comunidades_autonomas.geojson
  • provincias.geojson
  • municipios.geojson

Sobre el nombre, también podemos poner limites-administrativos-provincias.geojson asi el propio nombre indica que es.

thoughts?

@jalbertoroman
Copy link
Member

NO lo separé, venía así. Pensé en hacer un merge pero por dejar los datos lo más parecido a los originales no lo hice.
Sobre el nombre, deje el nombre original sustituyendo shp por geojson. Podemos hacer lo que queráis, es un cambio en el script de un minuto. Lo del merge es más complejo....

@inigoflores
Copy link
Member

Mola! Buen trabajo @jalbertoroman!

Con respecto a la separación entre Canarias y la península, si esto refleja la estructura original de la fuente, supongo que hay que dejarlo así para no violar el 2º principio de datos abiertos que nos recuerda @jpaulet:

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

@fesja
Copy link
Contributor Author

fesja commented Apr 17, 2016

No tengo claro que juntar los datos de Canarias y el resto sea modificar la fuente y contradiga el principio 2. Lo que veo es que alguien que necesite ambos, acabará haciendo un script para juntarlos. Por tanto, ¿por qué no hacerlo ya nosotros?

Y mi pregunta va más pensando en fuentes que nos den los datos separados por provincias o comunidades. ¿Dejamos un archivo para cada una o se juntan?

Aparte de vosotros, a ver qué opinan otros de este tema antes de cambiar nada.

@esebastian
Copy link
Member

Yo también veo más útil unificar los datos del mismo tipo, ya que simplificará el uso. Uno de los problemas que tienen muchas veces los datos que provienen de las administraciones públicas es que éstos se encuentran fragmentados del mismo modo que las competencias de las administraciones que los proporcionan, y usualmente esa fragmentación no responde a criterios operativos sino políticos.

@jgsogo
Copy link

jgsogo commented Apr 18, 2016

Yo preferiría que estuvieran todos juntos o todos fragmentados. En este caso no veo razón para separar Canarias del resto (que la habrá), pero sí que vería razón para que estuvieran separados por Comunidades Autónomas.

Mi voto va en el sentido de que si hay una separación antiintuitiva (Canarias + el resto) mergearlos; pero si vienen separados en la fuente mejor mantenerlos separados, así si yo quiero hacer algo con los datos de Castilla y León no tengo que bajarme todos y preparar un script que los divida.

@fesja
Copy link
Contributor Author

fesja commented Apr 18, 2016

vale, entonces unificamos los ficheros en este caso. Me parece bien lo que propone @jgsogo, o todos juntos o todos separados. Lo añado al wiki.

@jalbertoroman apúntatelo. No ejecutes cambios hasta que no solucionemos #22 y #21 también.

@fesja fesja closed this as completed Apr 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants