Restaurar copia de seguridad de base de datos geoespacial con PostgreSQL y PostGIS

¡Buenas de nuevo!

Como ya comenté en la entrada donde se explicaba cómo realizar una copia de seguridad de una base de datos geoespacial con PostgreSQL y PostGIS, el siguiente paso sería explicar cómo restaurar esta copia que hemos realizado para poder trabajar con ella.

Al igual que ocurre con las instrucciones explicadas para realizar la copia de seguridad, me imagino que estas instrucciones servirán para cualquier tipo de base de datos de PostgreSQL, pero en mi caso sólo las he usado para bases de datos espaciales, con las cuales os puedo asegurar que funcionan correctamente.

Una vez hemos realizado la copia o dump de la base de datos, tendremos dos ficheros, uno para el esquema de la misma y otro con los datos que hubieran almacenados, así que vamos a ver qué pasos debemos seguir para restaurar ambos ficheros.

- Lo primero será crear la base de datos de tipo espacial a la cual vamos a importar el esquema y los datos. Este paso lo llevaremos a cabo a través de pgAdmin y siguiendo las instrucciones que podéis encontrar aquí.

- Una vez la tenemos creada, restauramos el esquema de la base de datos a través de la siguiente instrucción:

 inmi@inmi-laptop:~/Escritorio$ psql -U postgres -h localhost prueba_postgis2 < dump_esquema.sql

Las opciones que usamos son:

-u Para autenticarnos mediante una clave asociada al nombre de usuario que indiquemos, que será el que tengamos para pgAdmin.

-h huésped Especifica el nombre o dirección IP del servidor donde está alojada la base de datos a la que vamos a importar el esquema.

En caso de que ya exista alguna tabla dentro de la base de datos con el mismo nombre nos dará errores de duplicado, el error generado por la existencia de la tabla spatial_ref_sys nos va a dar seguro, ya que al hacer la base de datos de tipo espacial, esta tabla se genera sola automáticamente.

- Una vez importado el esquema, importaremos los datos con la instrucción:

inmi@inmi-laptop:~/Escritorio$ pg_restore -U postgres -h localhost -a -v -e -Fc -O --disable-triggers -d prueba_postgis2 dump_datos.sql

Las opciones nuevas que usamos en esta instrucción son:

-a  Hace copia sólo de los datos y no del esquema.

-v Epecifica el modo verbose, es decir, en vez de dar un resumen da la salida del proceso completo..

-e  Para forzar la salida en caso de que se encuentre un error mientras se ejecutan las consultas SQL en la base de datos. Por defecto muestra el total de errores al final de la restauración.

-Fc  Permite especificar el formato de la salida del dump, en nuestro caso, usaremos un formato de salida customizable el cual viene comprimido por defecto.

-o Copia los identificadores de objetos (OIDs) para cada tabla de la base de datos.

–disable-triggers es útil para evitar problemas a la hora de hacer la restauración.

-d Copia los identificadores de objetos (OIDs) para cada tabla de la base de datos.

Una vez terminado el proceso, ya podemos comprobar en pgAdmin, cómo se ha restaurado correctamente el esquema y los datos que tuviéramos en la copia de seguridad de nuestra base de datos.

Espero que os haya sido útil :)

¡Un saludo!

Hacer copia de seguridad de base de datos geoespacial con PostgreSQL y PostGIS

¡Buenas a tod@s!

Esta vez vamos a explicar los pasos a seguir para hacer una copia de seguridad de una base de datos de tipo geoespacial a través de la línea de comandos. En la siguiente entrada hablaremos de cómo restaurarla.

Supongo que estas mismas instrucciones son las que usaremos con cualquier tipo de base de datos PostgreSQL, pero en mi caso, sólo lo he comprobado con bases de datos espaciales, para las cuales os puedo asegurar que funcionan a la perfección.

Para realizar una copia de seguridad o dump de la base de datos abrimos la consola y nos situamos en la carpeta en la que vamos a almacenarla, en mi caso me situaré en el Escritorio, y escribimos las siguientes instrucciones:

- Primero hacemos una copia del esquema de la base de datos:

inmi@inmi-laptop:~/Escritorio$ pg_dump -U postgres -h localhost -sv prueba_postgis -O > dump_esquema.sql

Las opciones que usamos son:

-u Para autenticarnos mediante una clave asociada al nombre de usuario que indiquemos.

-h huésped Especifica el nombre o dirección IP del servidor donde está alojada la base de datos.

-s Copia solo el esquema (las definiciones), no los datos.

-v Epecifica el modo verbose, es decir, en vez de dar un resumen da la salida del proceso completo.

-o Copia los identificadores de objetos (OIDs) para cada tabla de la base de datos.

La clave que os va a solicitar que introduzcáis es la misma que tengáis para pgAdmin. Una vez introducida vemos que la copia se ha generado correctamente en el Escritorio con el nombre que le habíamos indicado, en mi caso,  dump_esquema.sql

- El siguiente paso será hacer una copia de los datos que hay almacenados dentro de la base de datos cuyo esquema acabamos de copiar:

inmi@inmi-laptop:~/Escritorio$ pg_dump -U postgres -h localhost -Fc -f dump_datos.sql -a --disable-triggers prueba_postgis

Las opciones nuevas que usamos en esta instrucción son:

-Fc  Permite especificar el formato de la salida del dump, en nuestro caso, usaremos un formato de salida customizable el cual viene comprimido por defecto.

-f <archivo> Para indicar el nombre del archivo en el que realizaremos la copia.

-a  Hace copia sólo de los datos y no del esquema.

–disable-triggers es útil para evitar problemas a la hora de hacer la restauración.

Igualmente nos solicitará la clave y una vez introducida podremos comprobar que efectivamente se ha guardado en nuestro escritorio con el nombre que hemos indicado, en mi caso, dump_datos.sql

Espero que os haya sido de utilidad, como he comentado anteriormente, en la próxima entrada explicaré cómo restaurar esta copia que hemos creado.

¡Saludos!

Almacenamiento y tratamiento de datos geolocalizados en PostgreSQL con PostGIS

¡Buenas a tod@s!

Hoy voy a explicar una operación básica pero necesaria para almacenar y  tratar con datos geolocalizados. Siguiendo un poco el hilo del tutorial, ya tenemos nuestra base de datos PostgreSQL con el módulo PotGIS creada, así como creada nuestra tabla con el tipo de dato espacial haciendo uso del SRID 4326, por lo que ahora vamos a ver cómo se almacena un punto, definido por su longitud y su latitud, en ella.

Lo más importante que debemos saber y que no debemos confundir, es que tanto para almacenar un punto en la base de datos como para recuperarlo, debemos tener presente que estos se almacenan definidos por el par (longitud latitud) y que no debemos alterar ese orden. Cuando explicamos cómo añadir un tipo de dato espacial, pudimos observar que en nuestra tabla, este dato aparecía como un único objeto almacenado en una única columna. Bien, veamos ahora la consulta SQL necesaria para almacenar un punto geográfico:

INSERT INTO puntos(punto)
VALUES (ST_GeomFromText('POINT(37.884466 -4.779536)',4326))

Por otro lado, para recuperar un punto almacenado en la base de datos, tenemos dos formas distintas, que usaremos según necesitemos en cada caso:

  • Recuperación del punto definido por el par (longitud latitud)
SELECT ST_AsTEXT(punto)
from puntos
consulta SQL select ST_AsTEXT
  • Recuperación de la longitud y de la latitud del punto de forma independiente para poder trabajar con cada una de ellas. Para la longitud tendremos
SELECT ST_X(punto)
from puntos
consulta SQL select ST_X
Y para la latitud

SELECT ST_Y(punto)
from puntos
consulta SQL select ST_Y

Una vez obtenida la longitud y la latitud por cualquiera de los métodos anteriores, ya podremos trabajar con este formato o incluso representarlo de forma visual en un mapa.

Espero que os haya sido útil :)

¡Un saludo!

Base de datos espacial con PostgreSQL-PostGIS: spatial_ref_sys y SRID

Buenas!

Como ya comenté, tenía pendiente una entrada para hablar sobre dos conceptos que han aparecido y que resultan de gran interés para escribir sobre ellos. Hablamos de la tabla spatial_ref_sys y de SRID.

Comencemos por la tabla spatial_ref_sys que como ya vimos , se genera automáticamente en nuestra base de datos cuando la hacemos de tipo espacial. El formato de esta tabla es el siguiente:

tabla spatial_ref_sys pgAdmin

Las columnas que aparecen dentro de la misma son:

  • SRID: Es un identificador del sistema de referencia espacial (SRS - Spatial Referencing System), y es usado para identificar de forma única el sistema de coordenadas que vamos a usar en nuestra base de datos.
  • AUTH_NAME: Es el nombre del estándar para el sistema de referencia. Por ejemplo: EPSG.
  • AUTH_SRID: El identificador según el estándar AUTH_NAME. En el ejemplo anterior es el código según EPSG.
  • SRTEXT: Una Well-Know text representación para el sistema de referencia especial. Para un listado proyecciones EPSG y su correspondiente representación WKT, podemos acceder a la página http://www.opengeospatial.org/
  • PROJ4TEXT: Proj4 es una librería que usa PostGIS para transformar coordenadas. Esta columna contiene una cadena con definición de las coordenadas de Proj4 para un SRID dado.

Algunos de los valores de SRID de la EPGS  más conocidos son: 4326- WGS 84 Long Lat que es el sistema que habitualmente usan los GPS, o 3857 – WGS84 usado por Google Maps u OpenStreetMap. Lo más importante es trabajar siempre con el mismo SRID, ya que si realizamos operaciones con objetos que tienen diferente SRID, el resultado será erróneo.

En mi caso, sólo puedo hablaros del SRID 4326, que es el que he usado para el cálculo de distancias entre puntos, definidos por su longitud y su latitud, y funciona perfectamente, si este es vuestro propósito, ya sabéis que ese valor da resultados correctos.

srid 4326 tabla_spatial_ref_sys pgAdmin

Estaría genial si aportáis otros SRID con los que hayáis trabajado, por qué lo habéis hecho y qué ventajas o inconvenientes habéis sacado de la experiencia :)

¡Un saludo!

Cómo crear una tabla con datos geoespaciales en Postgis y PostgreSQL

Buenas a tod@s :)

Siguiendo un poco el hilo de los posts anteriores, ya tenemos instaladas todas las tecnologías que vamos a necesitar y ya hemos creado una base de datos de tipo espacial . Ahora, se trata de poder almacenar puntos geolocalizados dentro de nuestra base de datos.

¿Cuál es el siguiente paso que debemos dar?

Lo primero será crear una tabla en nuestra base de datos, que será la tabla que albergará el tipo de dato geolocalizado. Para ello, basta con hacer clic derecho en el Explorador de objetos en la zona de nuestra base de datos creada, y darle a Nueva tabla. En las siguientes imágenes vemos la información que será necesario rellenar sobre la propiedad y definición, que como podréis observar es la misma que indicábamos al crear la base de datos.

pgAdmin-Crear tablapgAdmin- Crear tabla postGISEn la pestaña Columnas podemos definir todas aquellas columnas que vaya a tener nuestra tabla y que no sean de tipo geoespacial. Para añadir un tipo de dato espacial, que llamaremos ‘punto’, tendremos que hacerlo mediante la siguiente sentencia SQL:

SELECT AddGeometryColumn ( 'nombre_tabla', 'nombre_columna', 4326, 'POINT', 2);

En la siguiente imagen se muestra la consulta para nuestro caso, con la salida que debe darnos si se ha creado de forma correcta.

pgAdmin-consulta SQL-dato espacial

Una vez creadas la tabla ‘puntos’ y el tipo de dato ‘punto’, si la seleccionamos en el Explorador de objetos podremos ver las sentencias SQL que internamente se han ejecutado para crearlos.

pgAdmin-Sentencias SQL creación tabla espacialComo siempre, ¡espero que esta entrada os haya sido de utilidad!

Un saludo :)

Instalación de PostGIS para PostgreSQL

Cada vez son más las aplicaciones que hacen uso de localizaciones dentro de su funcionamiento y que además, necesitan almacenarlas de alguna forma dentro de su base de datos. Es entonces cuando PostgreSQL toma ventaja frente a MySQL gracias a la existencia de PostGis.
PostGIS

PostGis es un software libre, tiene licencia GNU General Public License (GPL), convierte nuestra base de datos PostgreSQL en una base de datos espacial capacitada para almacenar y trabajar con datos espaciales.

La instalación es muy sencilla, esta que indico aquí es la que usé en local y en un servidor en producción con Ubuntu 12.04, supongo que en versiones posteriores será similar con algún cambio en las versiones de paquetes pero diría que la mecánica es la misma, pero si tenéis alguna duda preguntad en comentarios y lo vemos entre todos.

Instalamos los paquetes:

sudo apt-get install python-software-properties
sudo apt-add-repository ppa:ubuntugis/ppa
sudo apt-get update
sudo apt-get install postgresql-9.1-postgis
sudo apt-get install build-essential postgresql-9.1 postgresql-server-dev-9.1 libxml2-dev proj libjson0-dev xsltproc docbook-xsl docbook-mathml gettext postgresql-contrib-9.1 pgadmin3
sudo apt-get install python-software-properties
sudo apt-add-repository ppa:olivier-berten/geo
sudo apt-get update
sudo apt-get install libgdal-dev

Una vez realizadas estas instalaciones, verficamos la versión de libGDAL, que debe ser 1.9.0

$ gdal-config --version
1.9.0

También verificamos la de libGEOS

$ geos-config --version
3.3.2

Ahora debemos actualizar la versión de libGEOS a la 3.3.3, para ello realizamos los siguientes pasos:

sudo apt-get install g++ ruby ruby1.8-dev swig swig2.0 ''--- added to other instructions, not installed by default in 12.04 & required for this make
wget http://download.osgeo.org/geos/geos-3.3.3.tar.bz2
tar xvfj geos-3.3.3.tar.bz2
cd geos-3.3.3
./configure --enable-ruby --prefix=/usr

Al final del proceso de configuración debe aparecer lo siguiente:

Swig: true
Python bindings: false
Ruby bindings: true
PHP bindings: false

Finalmente, compilamos:

make
sudo make install
cd ..

y comprobamos nuevamente la version, que ya si debe ser la 3.3.3:

$ geos-config --version
3.3.3

 

Continuamos con la instalación de PostGis:

wget http://postgis.refractions.net/download/postgis-2.0.6.tar.gz
tar xfvz postgis-2.0.6.tar.gz
cd postgis-2.0.6
./configure --with-gui

El final de esta instalación debe decir algo así:

PostGIS is now configured for i686-pc-linux-gnu
-------------- Compiler Info -------------
C compiler: gcc -g -O2
C++ compiler: g++ -g -O2
-------------- Dependencies --------------
GEOS config: /usr/bin/geos-config
GEOS version: 3.3.3
GDAL config: /usr/bin/gdal-config
GDAL version: 1.9.0
PostgreSQL config: /usr/bin/pg_config
PostgreSQL version: PostgreSQL 9.1.3
PROJ4 version: 47
Libxml2 config: /usr/bin/xml2-config
Libxml2 version: 2.7.8
JSON-C support: yes
PostGIS debug level: 0
Perl: /usr/bin/perl
--------------- Extensions ---------------
PostGIS Raster: enabled
PostGIS Topology: enabled
-------- Documentation Generation --------
xsltproc: /usr/bin/xsltproc
xsl style sheets: /usr/share/xml/docbook/stylesheet/nwalsh
dblatex:
convert:
mathml2.dtd: /usr/share/xml/schema/w3c/mathml/dtd/mathml2.dtd

para finalizar la instalación, compilamos:

make
sudo make install
sudo ldconfig
sudo make comments-install

una vez terminados estos pasos, creamos el usuario de postgres:

sudo apt-get install postgresql-client
sudo -u postgres createuser --superuser $USER
sudo -u postgres psql
postgres=# password postgres (la password que he puesto es postgres)

Finalmente, creamos la plantilla template_postgis, que es la clave para la creación de una base de datos de tipo espacial.

sudo su postgres
sudo createdb template _postgis
sudo createlang plpgsql template_postgis
sudo psql -d template_postgis -f /usr/share/postgresql/9.1/contrib/postgis-2.0/postgis.sql
sudo psql -d template_postgis -f /usr/share/postgresql/9.1/contrib/postgis-2.0/spatial_ref_sys.sql
sudo psql -d template_postgis -c "SELECT postgis_full_version();"

Estas instrucciones son una adaptación mía de la guía que seguí: http://trac.osgeo.org/postgis/wiki/UsersWikiPostGIS20Ubuntu1204

Espero que no os haya aburrido con este extenso primer post que escribo en LH :) .En próximas entradas ahondaremos más sobre bases de datos espaciales como esta que acabo de crear.

Rubyrep (replicación de base de datos que no lastima)

Hola, quería aportar contenido sobre una interesante herramienta para implementar replicación de base de datos (para postgres y mysql). Me tope con ésta herramienta hace unos días, cuando estaba buscado información/soporte para utilizar Slony-I (herramienta de replicación para PostgreSQL). Resulta ser una solución muy buena, fácil de implementar y relativamente simple. (en comparación con Slony-I). Está escrita en JRuby, lo cual la hace independiente de la plataforma (donde corra Java, lo hará ésta herramienta).

Características principales:

  • open-source
  • Replicación asincrónica, Master-Maste, Master-Slave.
  • Muy fácil de utilizar y configurar (a través de archivos .conf muy sencillos de entender).
  • Independiente del motor de base de datos (actualmente soporta Postgresql y MySql).
  • Puede escanear dos bases de datos en busca de diferencias.
  • Puede sincronizar dos bases de datos.
  • Puede replicar continuamente entre dos bases de datos.

En fin, dejo el link hacía la página web de la herramienta. Estaría muy bueno que se pueda compartir, es un proyecto open-source, y por lo tanto, es LIBRE y necesita la colaboración de todos.

http://www.rubyrep.org

Saludos, Matias Miguez

Aspecto interfaz MonoDevelop

Curso ADO.NET con Mono y MySQL – Creación del proyecto

Nos dirigimos a MonoDevelop y creamos una solución nueva, en C#, para consola. Elegís el nombre, el que le he puesto para el ejemplo es: ejemplo_mono_ado. Os aparecerá en pantalla un fichero de nombre: Main.cs junto a un árbol a la izquierda con características de la solución. Una de ellas, las referencias es donde importaremos el ensamblado.

Antes de seguir sería conveniente que copiarais al directorio del proyecto el fichero “mysql.data.dll” que venía dentro del paquete comprimido del conector. Os dirigís a referencias y haciendo clic sobre el mismo título “Referencias”, elegís “Editar referencias...”. De las tres pestañas que aparecen en el diálogo elegís “Ensamblado .NET” y os dirigís al directorio del proyecto o donde tengáis guardado el fichero. Lo elegís y lo añadís.

Aspecto interfaz MonoDevelop

Desde este momento tenéis referenciado el conector dentro de vuestro programa. Ahora el siguiente paso es importarlo al fichero Main.cs. Para ello escribís debajo de “using System; ”, “using MySql.Data.MySqlClient;”. El archivo quedaría así:

using System;
using MySql.Data.MySqlClient; 

namespace ejemplo_mono_ado
{
	class MainClass
	{
		public static void Main(string[] args)
		{
			Console.WriteLine("¡Hola Mundo!");
// Hola Mundo inicial creado por el IDE
		}
	}
}

Con ésto ya tendríamos el espacio de nombres del conector MySQL disponible en nuestro código por lo que a partir de ahora sí que podríamos tratar con las clases del mismo.

Curso ADO.NET con Mono y MySQL – Preparación e instalación

Pasado más de un mes desde la entrada que anunciaba este curso, volvemos a la carga, veamos.

Antes de nada, de forma básica, vamos a revisar qué necesitamos, cómo obtenerlo y en caso necesario, cómo configurarlo. En este momento ,creo conveniente señalar que utilizaremos MonoDevelop,el entorno de desarrollo integrado para Mono más popular, en lugar de utilizar directamente el compilador, mcs; para centrarnos directamente en el desarrollo con ADO y dejar de lado los detalles que no son necesarios.

Logo MonoDevelop

Mono y MonoDevelop

En función de la distribución que utilicéis, las circunstancias particulares cambiaran, pero básicamente os comento dos alternativas que probablemente os sirvan prácticamente a todos. La primera es dirigiros a vuestro gestor de paquetes y buscar los paquetes correspondientes. Como monodevelop, que será más o menos así el nombre del paquete, depende de Mono, si elegís éste se os seleccionaran los demás paquetes necesarios para desarrollar y ejecutar programas con Mono. Es decir, básicamente instalando MonoDevelop a través del paquete homónimo, tendréis todo preparado. Además, es más que probable que tengáis instalado Mono en vuestro equipo por defecto. Por ejemplo, el entorno de escritorio Gnome utiliza esta tecnología ampliamente.

La segunda solución, la más larga y menos recomendable es instalar Mono compilando el código fuente. Necesitaremos tener instalados: cmpilador de C (gcc), Bison y las librerías de desarrollo para glib. Descargaremos el código fuente desde la sección de descargas del Proyecto Mono (pondrá algo así como Mono el número de la versión seguido de “sources”). Utilizaremos el directorio “/opt” para evitar problemas. Más o menos el proceso de instalación sería:

  1. Descomprimimos y desempaquetamos el código fuente, gráficamente o mediante la consola: $ tar zxvf mono-X.XX.tar.gz
  2. Configuramos los archivos para realizar el make: $ ./configure --prefix=/opt/mono
  3. Ejecutamos make para ejecutar el código fuente: $ make
  4. Finalmente instalamos: $ sudo make install

Tras la instalación deberemos configurar debidamente las variables de entorno. Para ello ejecutamos desde la terminal:

$ export PATH=$PATH:/opt/mono/bin
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/mono/lib
$ export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/mono/lib/pkgconfig
$ export MONO_PATH=/opt/mono/lib

Una vez ya tenemos instalado Mono, pasamos a instalar MonoDevelop de una forma análoga. Accedemos al sitio de MonoDevelop, descargamos el código fuente y:

  1. Desempaquetamos el código fuente y lo descomprimimos: $ tar zxvf monodevelop-X.X.tar.bz2
  2. Configuramos para crear el make: ./configure --prefix=`pkg-config --variable=prefix mono`
  3. Compilamos: $ make
  4. Instalamos: $ make install

Ya tendríamos esta parte lista, pero como dije antes, mucho mejor utilizar el sistema gestor de paquetes para evitar problemas derivados de no poder actualizar tan fácilmente o por ejemplo, las dependencias insatisfechas.

Logo MySQL

MySQL

De igual manera instalaremos el servidor MySQL al que nos conectaremos desde nuestra aplicación con C#. Dado que hay gran cantidad de tutoriales y manuales en la red, voy a ser bastante breve. Básicamente deberéis buscar en vuestro gestor de repositorios el paquete mysql-server y ya tendréis el servidor de base de datos instalado.

Conector

Finalmente, descargaremos el fichero con el conector de MySQL para .NET y Mono. Es un fichero con extensión .dll, que es la extensión con que suelen ser almacenados los ensamblados, como es el caso de .NET/Mono. Si queréis saber más sobre ensamblados, el CLI, o cualquier otro detalle más técnico propio de .NET/Mono, podéis visitar la Wikipedia (preferiblemente en inglés) o la MSDN (antes también Mono-Hispano pero ahora mismo parece que no está accesible). Aunque no sea el objetivo de este artículo definiré brevemente dichos conceptos para que quede algo más claro. Podríamos decir que un ensamblado en Mono es un conjunto de clases implementadas junto con sus metadatos correspondientes para ser utilizados, recogidos en un fichero que puede ser llamado desde un proyecto Mono.

En el caso que nos ocupa utilizaremos una implementación de la arquitectura ADO.NET creada por el propio proyecto MySQL para posibilitar una comunicación lo más nativa e integrada posible entre aplicaciones desarrolladas con .NET/Mono y MySQL. El conector, que así se llama, podéis encontrarlo en la web de MySQL (http://dev.mysql.com/downloads/connector/net/).

Una vez nos encontremos en el sitio, descargamos los ficheros para Windows sin instalador (un fichero .zip con varios ensamblados), lo descomprimimos y ya tendremos todo preparado para comenzar el proyecto.

Antes de continuar un detalle importante. Microsoft Windows no es case sensitive, sensible a mayúsculas/minúsculas, en cuanto a rutas, pero GNU/Linux sí lo es, por lo que deberéis renombrar los ficheros dll que utilicemos conforme se llaman en el programa que será: “MySql.Data” en lugar de “mysql.data” como vienen nombrados por defectos (los demás también de manera análoga).