Pregunta abierta al INE. ¿Por qué las geometrías de las secciones censales no son públicas?

Posted: febrero 22nd, 2014 | Author: | Filed under: Sin categoría | Tags: , , | 1 Comment »

Con motivo del Open Data Day, hemos intentado hacer una visualización para la que necesitábamos las geometrías de las secciones censales.

Al parecer por la política del INE respecto a estos datos no es posible obtenerlos así que les he escrito un correo. Actualizaré este artículo con lo que respondan.

 

Con motivo del Open Data Day [1] estamos intentando hacer una visualización para la que necesitamos las geometrías de los distritos censales.

He visto que es posible obtener información de las secciones censales a través de WMS [2] pero se especifica que no es posible obtener las geometrías a través de WFS [3].

Parece ser que esto es debido a la política del INE, que es el propietario de esta información [4].

Me gustaría que me informaran si esto es correcto y en caso de no serlo de donde puedo obtener dicha información.

En caso de que efectivamente exista una política de no publicación acerca de esos datos, me gustaría saber cual es el motivo de que la ciudadadanía no tenga acceso a ellos.

Les hago saber que he reproducido este mensaje en mi blog [5] y que con su permiso reproduciré también la respuesta que me den.

Muchas Gracias.

[1] http://opendataday.org/
[2] http://www.idee.es/wms/IDEE-Limite/IDEE-Limite
[3] http://www.cartociudad.es/portal/web/guest/directorio-de-servicios
[4] http://listserv.gva.es/pipermail/gvsig_usuarios/2012-February/021286.html
[5] http://conocimientoabierto.es/pregunta-abierta-al-ine-por-que-las-geometrias-de-las-secciones-censales-no-son-publicas/659/

 

Actualización 25/02/2014

El lunes por la mañana me llegó este correo de respuesta del INE:

Estimado Sr.Sra.: En relación con su consulta le informamos lo siguiente :

el INE facilita como petición a medida los Ficheros de Cartografía Digital, estos ficheros contienen la digitalización de los contornos georeferenciados de todos los municipios y de gran parte de las secciones censales, según coordenadas UTM, huso 28, 29, 30 y 31. Los ficheros tienen formato EXPORT de Arclnfo (e009) y SHAPE.

en la siguiente dirección puede consultar las secciones disponibles

http://www.ine.es

-productos y servicios

-información estadística

-información a medida y ficheros especiales

http://www.ine.es/ss/Satellite?L=es_ES&c=Page&cid=1254735550786&p=1254735550786&pagename=ProductosYServicios%2FPYSLayout

-estos ficheros tienen un coste dependiendo de si solo quiere uno o todos.

hay que solicitarlos como petición a medida

las peticiones a medida se pueden realizar mediante este medio o bien directamente al Area de Atención a Usuarios. Fax 91-5839158

en las peticiones de información a medida se indicará los datos de la persona de contacto (nombre, dirección postal, teléfono, fax y correo electrónico si dispone de él) y detallando lo mejor posible la información que se desea

-Atentamente

-Área de Difusión por Internet.

– CALIDAD DE LA INFORMACIÓN –
La presente información se ha obtenido siguiendo estrictos procedimientos de control de calidad; no obstante, pueden producirse errores involuntarios o de interpretación, por lo que las cifras ofrecidas pueden, en algún caso, no ser correctas o adecuadas a su petición.

NOTA: Por favor, no responda a este correo ya que los correos electrónicos recibidos en esta dirección se borran automáticamente. Si necesita volver a contactar con nosotros utilice un nuevo formulario de consulta http://www.ine.es/infoine indicando su número de referencia.

En resumen, que hay que pagar por los datos. La verdad es que les escribí inicialmente por curiosidad, no porque tenga ninguna necesidad de los datos y no querría alargar esto de forma indefinida, por lo que si alguien se anima a colaborar con una respuesta o dar alguna idea se lo agradecería. Estaba pensando en enviarles como respuesta un correo parecido al que escribo a continuación. ¿Qué opináis?. Para facilitar la colaboración he pegado este documento en un etherpad de libre modificación.

Hola,

Les escribo de nuevo con relación a la cuestión con número de referencia XXXX. Esta cuestión era relativo al acceso pública a las geometrías de las secciones censales.

Lo primero darles las gracias por su pronta respuesta y la claridad de la misma y notificarles de  nuevo que estoy copianda mis preguntas y sus respuestas de forma abierta en esta dirección de internet [1].

El motivo de solicitarles esta información en primer lugar, era para demostrar el poder que tiene el disponer de datos abiertos a la hora de la toma de decisiones y la participación ciudadana en un trabajo que estaba realizando junto a otra gente de forma voluntaria como motivo del Open Data Day.

No quiero alargar esto de forma indefinida, pero a la vista de su respuesta me surgen una serie de dudas que les manifiesto:

* ¿Por qué los costes de acceso a esta información no son claramente enunciados? A pesar de ser el INE un “organismo autónomo” entiendo que en el fondo tiene un carácter (¿y financiación?) público y por tanto sería interesante hacer un esfuerzo en detallarlos.

* Si bien creo que ni la LISIGE ni la Ley de Reutilización de la Información Pública obligan a la publicación gratuita de la información, el espíritu de estas normativas es el facilitar lo máximo posible el acceso. Si bien es difícil cuantificar [2] las ventajas de disponer de la  mayoría de información geográfica de forma gratuita, si que parece existir un consenso general de que ello favorece el desarrollo económico y social de un país. Con esto en cuenta, mi pregunta sería si los ingresos obtenidos por el instituto por la comercialización de esta información son lo suficientemente significativos como para que compense limitar el acceso a los mismos a las empresas y ciudadanía.

* Mi última cuestión de índole más práctica sería bajo que terminos o licencia de uso se distribuyen las geometrías de las secciones censales. En concreto, en caso de adquirirlas podría luego revenderlas o publicarlas de forma abierta en internet.

Por último, felicitarles por el trabajo que realizan, dado que somos muchos los que podemos realizar una labor comercial o investigadora gracias a los datos que publican.

Atentamente

[1] http://conocimientoabierto.es/pregunta-abierta-al-ine-por-que-las-geometrias-de-las-secciones-censales-no-son-publicas/659/

[2] http://blog-idee.blogspot.com.es/2011/11/que-valor-tiene-la-informacion.html

 


Charlas del FOSS4G 13

Posted: enero 5th, 2014 | Author: | Filed under: Sin categoría | Tags: , , , | No Comments »

Estoy viendo algunas (la mayoría) de las charlas del FOSS4G que hay en esta lista de youtube. Llevo las primeras 25, y comparto en dos grupos las que me han parecido más interesantes y otras que he visto con una mínima descripción.

Recomendables

  • TileServer. Buena introducción a que es WMTS y cuando usarlo. Así como una demo de lo fácil que es convertir un ráster a tiles y servirlo como tileserver-php. Recomendable si no sabes lo que es WMTS.
  • Leaflet: Past, Present, Future. Charla divertida donde cuentan la historia de leaflet y lo que esperan del futuro. Nada técnico pero interesante para estar al día del mundillo. De paso deja un par de lecciones de como conseguir que un proyecto de software libre triunfe.
  • OpenLayers 3: Under The Hood. Recomendable. Es interesante ver como han repensando la librería, y lo que hay alrededor de la misma, integración continua, como hacen los builds,…
  • Application Development With OpenLayers 3. Es un resumen de como usar la api de ol3 para hacer tus propias aplicaciones.

Otras


Plugin de análisis de redes en gvSIG 1.x

Posted: mayo 8th, 2013 | Author: | Filed under: Sin categoría | Tags: , , , , | No Comments »

Una pregunta habitual en las listas de correo de gvSIG es si hay alguna herramienta para realizar análisis de redes. En Cartolab hemos estado buscando enlaces a algunos recursos del plugin llamado “piloto de redes” que es el más empleado para estos análisis para poder compartirlos.

El plugin de piloto de redes (a veces también se lo llama “network extension“, “análisis de redes” o “extGraph“) es mantenido por Scolab y dispone de una página web en la forja de join-up, pero parece desactualizada.

 

Instalación

La última versión de este plugin es compatible con la versión 1.12 de gvSIG, y se puede instalar desde el administrador de complementos.

Herramientas -> Administrador de complementos -> Seleccionamos org.gvsig.graph y seguimos las instrucciones.

Resumen de uso

  1. Se carga una capa de líneas con los líneas conectadas, sin repetir y digitalizadas en el sentido de la circulación.
  2. Si queremos un análisis mas acertado deberíamos como mínimo un atributo donde esté definido el coste y otro en el que esté definido el sentido. El coste representa cuanto cuesta recorrer ese tramo en las unidades que nosotros queramos, distancia, tiempo,… En el campo sentido Asignamos un valor al sentido que se puede seguir por esa línea (el de la digitalización, ambos sentidos, contrario a la digitalización)
  3. A continuación vamos a Red->calcular topología de red que nos generará un fichero .net en el mismo direcotorio que la capa original con esa red. Aquí podemos decidir asignar cierta tolerancia a nuestra capa, por si los nodos no están perfectamente conectados,…
  4. En la siguiente pantalla, emparejamos los campos que nos solicitan. No es necesario rellenarlos todos. Si escogemos sentido le diremos que valor corresponde a de cada sentido posible.
  5. Cuando se carga la red nos preguntará por el campo que tiene un identificador para las geometrías, por ejemplo los nombres de las calles.
  6. Con la red cargada tenemos las opciones de introducir paradas, barreras o realizar los análisis. Las paradas se pueden administrar desde Red->Gestión de paradas. Son puntos de inicio, fin o de paso intermedio obligatorio de un cálculo de rutas. También se comportan como puntos a partir del cual determinar el equipamiento más cercano,… Las barreras son puntos por los que se impide el paso.
  7. Entre cálculo y cálculo recordar Red -> Borrar -> “Eliminar lo que nos interese”

Videotutoriales

  • Una serie de cuatro vídeos (unos 10, 15 minutos en total) con lo más básico del la extensión de redes para calcular rutas óptimas. Emplea la versión 1.1.2 de gvSIG pero permite ver lo más importante.
  • Vídeo de 6 minutos, demostrativo de varias de las funcionalidades de la extensión. . Cálculo de rutas. Matriz de distanticas y tiempos. Punto más cercano. Árbol de recubrimiento mínimo. Área de servicio. Está bien para de un vistazo saber todo lo que hace.

Manuales

Otros recursos

 


VII Jornadas de SIG Libre de Girona

Posted: marzo 26th, 2013 | Author: | Filed under: Sin categoría | Tags: , , , , , , , | 1 Comment »

Este año gracias a Cartolab he tenido la oportunidad de asistir de nuevo a las Jornadas de SIG Libre de Girona.

Como en años anteriores, el ambiente y la organización fueron magníficos. A pesar de que no había tanta gente como hace dos años, el compromiso de la comunidad geo con estas jornadas y el buen hacer del sigte hace que siempre merezca la pena ir.

Este año, desde cartolab, siguiendo la línea que tenemos para las jornadas de presentar contenidos formativos, análisis y cooperación para el desarrollo llevamos una comunicación sobre el Curso Online de SIG para Cooperación al Desarrollo , que ayudamos a elaborar el año pasado junto a Ingeniería Sin Fronteras, la empresa iCarto y el laboratorio de la USC, Laborate.

El eje de la presentación consistía en tratar de mostrar, como si bien las necesidades pueden ser iguales en los distintos territorios, las problemáticas que se daban en unos y en otros eran distintas. Por ejemplo la necesidad para la elaboración de un plan de ordenación territorial es igual en Galicia, que en Jinotega (Nicaragua), pero los problemas en Jinotega, donde sólo el 40% de las familias tiene una escritura de propiedad de la tierra, y sólo el 25% de las personas tiene algún tipo de ingreso , son distintos a los que nos encontraremos en Galicia. La presentación es algo minimalista pero si queréis más podéis anotaros al curso.


Integrando las correcciones de extCAD en OpenCADTools

Posted: enero 10th, 2013 | Author: | Filed under: Sin categoría | Tags: , , , , , | 2 Comments »

He estado trabajando en integrar todas las correcciones que se hicieron en la extensión oficial de CAD para gvSIG, desde el nacimiento de  OpenCADTools en las propias opencadtools. Este artículo describe:

  • Como se realizó el proceso de integración para ver de donde pueden venir errores futuros y la extraña apariencia que tiene el repositorio actual.
  • Contar el método seguido en sí por si resulta útil a gente que tenga que hacer algo parecido.

Debo agradecer al Cartolab el que me haya cedido horas de mi trabajo diario para poder escribir este artículo y realizar la integración en si misma. Además, debo agradecer a los organizadores del codesprint de Münich por financiar mi estancia allí y a los participantes por las aportaciones recibidas.

El problema

Tenemos tres repositorios svn con código parecido pero no igual:

  • gvSIG. Contiene entre otras muchas cosas el proyecto extCAD. Se trata del código base con commits desde 2005 hasta la actualidad
  • gisEIEL. A partir del año 2006 la Universidade da Coruña, a través de un convenio con la Diputación de A Coruña, realizó un fork de las herramientas de CAD de la versión 0.x de gvSIG. Este desarrollo fue asignado al Laboratorio de Bases de Datos de dicha universidad. En su repositorio actual sólo está el resultado final del fork, no los commits intermedios, porque lo que no se pueden comparar los logs para hacer una integración de código más ordenada.
  • OpenCADTools. A partir de 2009, con financiación de la Diputación de Pontevedra y en el marco de los trabajos de desarollo de gvSIG-EIEL Cartolab hizo una integración del código de gisEIEL con el de gvSIG adaptando todo ello primero a la versión 1.1.2 de gvSIG y luego a la 1.9. Se dispone de todo el historial desde el principio hasta la actualidad. Posteriormente Cartolab continuo el desarrollo de las OpenCADTools como un proyecto propio.

Lo que queremos ahora es:

  1. Obtener las mejoras realizadas en los tres proyectos desde que evolucionaron por separado para obtener una extensión de CAD mucho más potente. Nos concentraremos en el código de gvSIG y el de OpenCADTools por ser los que más desarrollo han tenido y estar ambos adaptados a la rama 1.9 de gvSIG, mientras que gisEIEL continua en versiones más antiguas. Emplearemos el proyecto de gisEIEL sólo para consultar dudas de autoría o Copyright.
  2. Es fundamental respetar lo máximo posible la historia de commits. Debemos saber cuando se integró un cambio, por qué, y quien lo hizo. Esto nos permitirá prevenir errores futuros.
  3. Es fundamental respetar lo máximo posible la autoría y el copyright de todas las modificaciones.
  4. Nuestra meta final es además que el código resultante pueda ser integrado en el proyecto gvSIG, por tanto nuestra base debe ser el código de extCAD, y las mejoras de OpenCADTools deben poder ser introducidas en forma de parches sobre extCAD.

Para ello necesitamos poder comparar de forma sencilla estos tres repositorios. Dada la cantidad de commits que ha habido y la divergencia existente resulta muy complicado comparar los logs o encontrar un punto común. Haremos por tanto un análisis inicial clase a clase que nos permita ver el grueso de las diferencias y tomar decisiones.

Análisis clase a clase

  • Montamos un repositorio local de git que contenga en ramas separadas el código de cada proyecto.
  • Obtenemos un fichero de texto all_files.txt con todas los ficheros que hay (sin repetir) estén en una rama u otra. Haremos el listado de ficheros de cada rama mediante tree, y compararemos los ficheros con meld para incluír rapidamente los ficheros que están en una y no en otra en el fichero all_files.txt
    git checkout heads/extcad
    tree -fi --noreport > extcad_files.txt
    git checkout heads/opencadtools
    tree -fi --noreport > opencadtools_files.txt
    cp opencadtools_files.txt all_files.txt
  • Hacemos un script muy sencillo que mete un carácter = antes de cada línea de un fichero checked_files.txt para todos aquellos ficheros que no hayan variado.
  • Sobre el fichero checked_files.txt marcamos con una x aquellos ficheros que sabemos que no es necesario que comprobemos, por ejemplo el directorio install de OpenCADTools que con el nuevo sistema de paquetes de gvSIG está obsoleta. Algunos de estos ficheros serán eliminados a posteriori
  • Los ficheros distintos los revisaremos uno a uno con algo como esto:
    fileToCheck=./src/com/iver/cit/gvsig/CADExtension.java
    git diff master:$fileToCheck refs/heads/opencadtools:$fileToCheck

    La variable fileToCheck la rellenamos con un copy&paste desde checked_files.txt. Y vamos marcando en el fichero de checked_files.txt con una m aquellos en las que la “versión más correcta” sea la del trunk de gvSIG. A veces el cambio es simplemente una cabecera, indentado, …

Este proceso aunque algo tedioso nos permite hacernos una imagen mental del estado de los repositorios lo que aumentará nuestra capacidad para tomar decisiones.

Primera fase de la de integración

En el caso de OpenCADTools fue sencillo encontrar el punto en que se completo la migración de las herramientas desde la versión 1.1.2 de gvSIG a la 1.9. Perder el histórico de la migración no era grave y nos permitía simplificar el proceso, así que lo que se decidió fue escoger el commit en que esa migración se consideraba finalizaday volcar todo el repo de OpenCADTools en ese punto sobre el de extCAD.

# En un repo con sólo OpenCADTools, hacemos
$ git checkout -b ultimoMigracion
# 0f517d66 = commit de interés, del 14 de Septiembre con mensaje "Updated StartEditing from gvSIG 1.9"
$ git reset --hard 0f517d66
# y sobre nuestro repo de trabajo:
cp -r $repoOpenCadTools .

A continuación vamos descartando todos los ficheros en los que sepamos que el contenido del master es más válido, los marcados como m en la fase anterior:

git checkout -- los_ficheros_donde_prefiramos_el_master

Nuestros lectores más hábiles en el uso de git se habrán dado cuenta, de que podríamos hacer el análisis de los ficheros tipo m directamente en este paso, pero como ya comentamos, hacerlo del otro modo nos permite afianzar nuestro conocimiento de los repositorios.

Segunda fase de la integración

Ahora tendremos en nuestro repo ficheros nuevos y ficheros modificados.

Los ficheros nuevos son todos ellos nuevas herramientas cuyas clases pueden ser agrupadas. Así que vamos comiteándolos aprovechando para revisar las cabeceras y las autorías. Resulta sencillo identificar si una de estas nuevas clases fue desarrollada inicialmente por el Laboratorio de Bases de Datos y adaptada con posterioridad por Cartolab, o fue creada directamente por Cartolab. Basta comprobar si existe o no en el repositorio de gisEIEL. En general los autores concretos de cada clase o quienes la adaptaron están también idendificados en el código fuente, cuando esto no es así lo que se ha hecho ha sido poner de forma genérica “Laboratorio de Bases de Datos” y/o “Cartolab”. La autoría se ha reflejado mediante anotaciones @author en el código fuente de las clases

De este modo vamos haciendo commits para las herramientas y dado que es git empleamos la opción –author para reflejar quien hizo el commit original en el repo de OpenCADTools (al menos de forma aproximada)

Los ficheros modificados en este caso son pocos, por lo que permite tomar decisiones de forma individual.

Tercera fase de la integración

Probablemete la fase más complicada. Nos toca integrar los 143 commits que hubo en OpenCADTools desde el que tomamos como referencia hasta el último commit previo a la integración.

Tras varias pruebas y sin encontrar una forma rápida y segura de integrar esos commits se optó por generar parches e ir integrándolos uno. En algunos casos hubo que retocar los parches o los ficheros a mano puesto que no se integraban correctamente.

Cuarta fase de la integración

Toca limar algunas aspectos, por ejemplo:

  • El nombre de los commiters, para lo que se emplea este script
  • Comprobar que podemos exportar lo que tenemos a un repositorio vacio de git (pasos 7 a 9)

Además se hace testeo funcional de las herramientas de CAD para encontrar posibles problemas en la integración y resolver los bugs que se deriven de ella.

Conclusiones

Dada la disparidad de la evolución de los repositorios el proceso fue tedioso. Pero ahora tenemos un repositorio git actualizado a los últimos cambios de las herramientas por defecto de gvSIG y de las opencadtools. Esto nos permite trazar el origen de algunos bugs, y realizar integración de parches en ambos sentidos, así que merece la pena.


Taller de gvSIG-EIEL en Valencia. Método 2

Posted: noviembre 29th, 2011 | Author: | Filed under: General | Tags: , , , , | 5 Comments »

Como comentábamos en la anterior entrada hemos creado un fichero .iso que podéis “quemar” en un pendrive de al menos 4GB para seguir el taller de gvSIG-EIEL. Podéis descargar el .iso desde este enlace.

Tras quemarla podréis arrancar vuestro ordenador desde el PC configurando en la BIOS que arranque en primer lugar desde ahí. Se trata de una versión de ubuntu con gvSIG-EIEL y una base de datos PostGIS con datos de prueba, todo preinstalado.

Para quemar el pendrive podéis seguir estas instrucciones. para linux o para windows.

El usuario por defecto es “custom” sin clave. Para conectar a la base de datos usaremos:

  • servidor: localhost
  • usuario: user
  • clave: user
  • puerto: 5432
  • esquema: eiel_map_municipal
El fichero .iso también debería poder ser ejecutado desde una máquina virtual.
Si tenéis algún problema dejad un comentario o comentádnoslo antes del taller. Estaremos todos los días por las jornadas.

Taller de gvSIG-EIEL en Valencia. Método 1.

Posted: noviembre 28th, 2011 | Author: | Filed under: General | Tags: , , , , | 1 Comment »

El jueves por la tarde en las Jornadas de gvSIG, Gonzalo y yo estaremos por parte de Cartolab impartiendo el taller sobre gvSIG-EIEL.

El taller está pensado para que los que acudan puedan seguir los ejemplos con su portátil. Dado que gvSIG-EIEL hace uso de una base de datos PostGIS para funcionar vamos a explicar dos formas distintas de poder seguir el taller.

La primera de ellas es que instaleis directamente en vuestro portátil la base de datos. Desde Ubuntu es tan sencillo como hacer:

sudo apt-get install postgresql-8.4-postgis pgadmin3

Y luego crear un template para postgis.

su postgres
createdb postgistemplate
createlang plpgsql postgistemplate
psql -d postgistemplate -f /usr/share/postgis/lwpostgis.sql
psql -d postgistemplate -f /usr/share/postgis/spatial_ref_sys.sql

Y en windows bajándose este pack y acordándose de seleccionar en el momento adecuado que también instale postgis.

Con motivo del taller vamos a proporcionar un nuevo set de datos que os podéis descargar desde este enlace. Aunque con los publicados en la página web es suficiente para hacer la mayoría de los ejemplos.

Desde la interfaz de pgAdmin3 se crea una nueva base de datos usando como template “template_postgis” y luego se emplea el set de datos que proporcionamos sobre la base de datos que acabamos de crear. En caso de que hayamos llamado gvsig-eiel a la base de datos hariamos:

psql -U postgres -p 5432 -h localhost -f gvsig-eiel.sql -d gvsig-eiel

En caso de duda este artículo puede ayudaros. Si tenéis alguna duda dejad un comentario en el blog o escribidme a fpuga ARROBA cartolab.es. Es importante que si vais a seguir el taller de forma activa traigais todo configurado.

gvSIG-EIEL podéis descargarlo de la propia página. Con motivo del taller hemos dispuesto un servidor alternativo por si hubiera problemas.

Mañana publicaré el segundo método. Vamos a distribuir un fichero que podreis volcar a un USB (mínimo 4GB y se perderán los datos que tuvierais en ellos) que actuará como sistema operativo completo con todo instalado que podéis ejecutar directamente desde el USB sin necesidad de tocar nada en el ordenador (aunque funciona considerablemente más lento)


Comentario sobre el diseño de bases de datos PostGIS

Posted: junio 17th, 2011 | Author: | Filed under: General | Tags: , , , , | 2 Comments »

Un par de comentarios muy rápidso sobre una práctica que considero acertada a la hora del diseño con bases de datos PostGIS.

No uses el esquema public

PostGIS emplea de forma intensiva el esquema public para crear funciones, tipos de datos etc… Si tu también empleas ese esquema cuando vuelques tu base de datos ese esquema tendrá que ser incluído y no sólo irán tus datos si no también toda la parte de PostGIS lo que incrementará el tamaño del dump y el tiempo de restauración.

Además si el usuario quiere restaurar la bd sobre una ya existente con PostGIS saldrán un montón de errores de que las funciones ya existen, con lo que se hace difícil depurar otros posibles errores. También se pueden producir errores si tu dump corresponde a una versión de PostGIS distinta a la que tiene el usuario.

Cuando vuelques tu base de datos excluye el esquema public del volcado

Por lo ya explicado en el punto 1. Hacer esto es tan sencillo como:

pg_dump --no-owner -N public -h servidor -U usuario -f /tmp/base_de_datos.sql base_de_datos

Vuelca también la tabla geometry_columns

Los únicos datos que estarán en el esquema público que te hacen falta serán los de la tabla geometry_columns. Vuelca por tanto esos datos (no hace falta la estructura) a otro fichero sql.

pg_dump --no-owner -a -t geometry_columns -h servidor -U usuario -f /tmp/geometry_columns.sql base_de_datos

Teniendo en cuenta estos consejos apenas tendrás trabajo extra y harás la vida mucho más fácil a quien tenga que restaurar la base de datos (que puede que seas tu mismo)

Actualización 17/Febrero/2013. Acabo de encontarme por primera vez desde que escribí esto con alguien que también declara en un post lo importante de no usar el schema public cuando se trabaja con postgis.


SigLibre2011: Taller Linked Data

Posted: abril 4th, 2011 | Author: | Filed under: General | Tags: , , , , , , | No Comments »

Hace poco CartoLab me dió la oportunidad de asistir a las V Jornadas de SIG Libre de Girona. El primer día, y a pesar de los temores de Gonzalo, llegamos a la sede de los talleres sin perdernos, aunque es de recibo decir que caimos de nuevo en el error del año pasado de intentar aparcar en el campus de la Facultat de Letres, lo que roza lo imposible, por lo que al final aparcamos en la ciudad y subimos andando (en realidad son apenas 10 minutitos de caminata).

El taller al que fuí por la mañana iba sobre Linked Data. Para mi gusto el taller acabo siendo más bien una clase teórica, por lo que por ahora para mi se queda en el cajón de “una esas tecnologías que habría que probar un día”.

LinkedData viene siendo un avance de cara a la web semántica, que se podría explicar diciendo algo así como que el objetivo es las webs no tengan datos si no información. Y esta información pueda estar enlazada y ser enlazable, no sólo en un formato entendible por los humanos, si no en un formato apto para que las máquinas puedan relacionarse entre sí. Ese lenguaje común que las máquinas podrían interpretar y en que se asienta el linked data es el RDF. La página de preguntas frecuentes de la web de Linked Data lo deja más claro de como lo puedo hacer yo.

Un ejemplo de las posibilidades sería por ejemplo que el IGN publicara un nomenclator en RDF. Cada uno de estos ficheritos RDF podría incluir el nombre del lugar y sus coordenadas geográficas. El INE en lugar de permitir bajarte csv podría publicar ficheros en RDF donde las estadísticas estuvieran enlazadas a los RDF que publica el nomeclator, lo que aportaría componente geográfica a los datos del INE sin que el INE se tuviera que preocupar de esta componente, sólo tendrían que enlazar una fuente fiable. Un tercero podría tomar ambos datos y proporcionar un servicio con ellos, por ejemplo rastrear las ofertas de trabajo de infojobs mezcladas con los datos del paro del INE y mostrar en un mapa que tipos de trabajo se ofrecen en los sitios donde hay más paro.

Me quedo con una de las frases del ponente que decía más o menos así:

Lo bueno o lo malo de LinkedData es que el producir la información es muy costoso pero el consumirla es relativamente sencillo.

La verdad es que es una tecnología con muy buena pinta, por ejemplo ya existen herramientas que permiten servir la información de una base de datos relacional en formato RDF, e interrogar a la BD mediante SPARQL.

Para saber más:

  • Linked Data.
  • CKAN. The data hub. Ejemplos de gente usando Linked Data, a los que podríamos enlazar nuestra propia información.
  • http://geosparql.appspot.com/

Un blog sobre Economía y Desarrollo

Posted: octubre 11th, 2010 | Author: | Filed under: General | Tags: , , , , , , | No Comments »

Aviso, esto era originalmente un correo-e, que viendo el resultado final decidí convertir en artículo, así que disculpen si presenta cierta incoherencia.

Llevo algún tiempo leyendo un blog cuyo editor principal es William Easterly, economista e importante teórico sobre el desarrollo. Se trata de un pensador heterodoxo, alejado de la corriente mayoritaria que representa Sachs, sus discusiones han sido sonadas [pdf].

Es crítico con la utilidad real de perdonar la deuda externa o los argumentos que se usan para condonarla , y Amartya Sen también ha criticado algunas de sus ideas pero tiene un blog que me encanta. Escribe de forma demasiado regular para poder leerlo todo pero de vez en cuando te encuentras con algunas joyitas o artículos que te obligan a pensar, acompañados generalmente de buenas infografías.  Por ejemplo: