Cloud PostGIS overview

Since not long ago I have been wondering about investigating a little bit the different cloud  PostgreSQL/PostGIS database providers (DBaaS) on the Internet.

Besides the interest for self-learning (say necesity), I was interested in the possibility of sharing test datasets for teaching/practicing purposes aimed at the students attending the geodatabase subject of the universitary master in information systems (MUSIGT) of the Public University of Navarre (UPNa).

My previous experience with HEROKU had been interesting but also limited to the provision of PostgreSQL instances, that is, without the PostGIS extension which can only be activated on the paying production plans, something off the limits of the current prospection.

In the past months I've been identifying several web pages that could be candidates to be considered and among them I found this entry in the OSGEO wiki which is specifically dedicated to this subject.

Among the different providers the one I have reviewed first is the Amazon RDS for PostgreSQL. All the Amazon's tech appeal in the form of a 12 month free trying period (if you don't overcome the level of service limits) will you let to test this service along others from the AWS platform... The thing is that I was not willing to acquire any type of commitment, not now nor after 12 months, and so, not without a bit of pity, I declined the proposal.

Next, I had a look to aiven, whose motto your database in the cloud, is pretty clarifying of where they are putting the focus on and of their specialization area. It looks good, with a variety of database paradigms represented by products as PosgreSQL (popular extensions included, among them PostGIS), Redis, InfluxDB, Apache Kafka, etc... deployed on the main platform service providers around the world (Google, Azure, DigitalOcean, UpCloud y Amazon AWS).

In this case there is not any free plan but you can take advantage of a 10$ bonus that you could spent in the more affordable plan called Hobbyist (1CPU, 1GB, 8GB storage, with a fee of aprox. 0.026 $/h, 19$ monthly estimate). Despite you don't have to give your credit card to have the test drive, I've left it aside by the moment for the already stated reasons.

There is another one that looks great: AcuGIS. I have nothing to say apart from the fact that I remains now in a high position of my task list. Maybe next time.

Last to be mentioned in this post and the one that I´ve been testing is QGIS Cloud.

QGIS Cloud

The name might suggest some kind of direct relation with the QGIS project but as far as I know this is an independent solution from the second. Leaving apart this little detail I must say that this is a solution that works and I have not found any problems during the test.

This provider offers a means of publishing your maps (QGIS made maps) through a web mapping application in the cloud. It also includes a data hosting service with PostgreSQL/PostGIS (preinstalled) databases (note that all the data used in the published maps should be first uploaded to this storage). The key aspect of this solution relies on the way all the map and data managament is done, based on the use of a QGIS plugin (that is, I think, the main explanation for the name of this product).

Once we have signed in the products page, and after installing the plugin we will be able to upload our maps and data through the plugin.

QGIS Cloud plugin for QGIS

As shown in the image, once logged we will be able to see the list of your DB instances, create new instances, know the used storage from the total available, upload  local data, manage maps, etc. Signing-in, installation and use are all quite easy and very clearly explained in the Quickstart page.

Along your data you will also have an instance of a OSM database ready to use in your maps.

At this moment two plans are offered: Free and Pro. With the Free plan you will be able to publish an unlimited number of maps (that will be publicly accessible to the world). Regarding to data storage: up to 5 PostGIS 2.0 DB instances, with a maximum total capacity of 50 MB and up to 10 concurrent DB connections. That is, a good set of features that are enough for experimental purposes.

QGIS Cloud as DBaaS

Perhaps we are not interested in the map publishing capacity and we would only like to use this service as a Cloud DB Service provider. This is perfectly possible. The only thing you will need to know is the DB connection details and use them from your favorite tool or application as you can read in this FAQ: PgAdmin, psql, QGIS... or any software that is able to connect to a PostgreSQL server.

We can find out the connection details from plugin's panel which shows the list of our database instances when you force the tooltip to appear (holding the mouse over each database name in the list).

It's worth to mention that when accessing from PgAdmin you  will have to specify the database name in the maintenance database parameter. It is also important to note thar in all cases SSL is required in the connection configuration. Have a look to this FAQ with examples.

Finally, I would like to say that I will not dare to evaluate the service's quality level as I can't manage all the aspects involved: the possible limitations of the Free plan or my own internet access. But I am sure that it will fulfill my current requirements.

PostGIS en la nuble

Hace tiempo que tenía apuntado investigar un poco sobre proveedores de servicios de bases de datos (DBaaS) PostgreSQL/PostGIS en la nube (o en el aire según cuño del filósofo Javier Echeverría Ezponda a quien reciéntemente tuvimos la oportunidad de disfrutar en el ciclo Diálogos mano a mano con el investigador de la Universidad Púbica de Navarra Humberto Bustince Sola).

Aparte del interés (necesidad) por aprender una solución de este tipo me serviría  para colgar juegos de datos de prueba para los alumnos de la asignatura de bases de datos geográficas (máster MUSIGT de la Universidad Pública de Navarra).

Mi experiencia previa con HEROKU había sido interesante pero se limitaba a la provisión de instancias de PostgreSQL, es decir, sin poder disfrutar de la extensión PostGIS al estar ésta última únicamente disponible en los planes (suscripciones) de producción, es decir, de pago, fuera del alcance de la prospección.

Llevo un tiempo identificando una serie de páginas que podrían ser interesantes entre las que cabe destacar la página de la wiki de OSGEO específicamente dedicada a este tema y que recoge las principales opciones existentes.

El primero de los dos proveedores que he revisado es Amazon RDS para PostgreSQL. Todo el tech appeal de Amazon en forma de una prueba gratuita de 12 meses (siempre que no se superen ciertos niveles de servicio) en la que poder probar este servicio y otros de la plataforma AWS... Como no me apetecía adquirir ningún compromiso, aunque éste fuese a 12 meses vista, con cierta pena, he declinado el ofrecimiento.
El siguiente proveedor que he estado consultando es aiven, cuyo lema your database in the cloud, es bastante clarificador de su enfoque y especialziación. Pinta muy bien, ofrece distintos servicios de bases de datos de los distintos paradigmas existentes, tales como PostgreSQL (incluidas las extensiones más populares, entre ellas PostGIS), Redis, InfluxDB, Apache Kafka, etc.., desplegados sobre distintos proveedores de servicios (Google, Azure, DigitalOcean, UpCloud y Amazon AWS).

En este caso no hay suscripción gratuita o de prueba pero sí un bono de 10$ de prueba que podríamos aplicar al plan más económico Hobbyist (1CPU, 1GB, 8GB de almacenamiento, con una tarifa rondando los 0.026 $/h, estimado mensual de 19$). Aunque para probar no piden "Visa", lo aparco.

Otro que también pinta muy bien es AcuGIS que por el momento pasa a engordar mi lista de tareas pendientes.

El último que voy a mencionar en este post y que he probado es QGIS Cloud. Así es, el nombre despista un poco, y la verdad que se podría decir que parece un poco oportunista...

QGIS Cloud

... y aun a riesgo de equivocarme yo diría que efectivamente lo es ya que no encuentro ninguna relación entre este proveedor y el proyecto QGIS. Dejando este detalle a un lado es una solución que funciona y he podido probar sin ningún problema.

El sistema ofrece un mecanismo para almacenar datos en la nube, así como para publicar mapas online que utilizan dichos datos (todos los datos de nuestros mapas que no sean servicios remotos deberemos subirlos al almacén PostGIS). La particularidad del sistema radica en el modo que se gestionan las operaciones, que no es de otra manera que a través de un plugin de QGIS (y entiendo que de ahí viene el nombre).

Una vez nos hayamos registrado en su página web y hayamos instalado el plugin en QGIS podremos subir nuestros mapas y datos mediante el plugin.

Plugin QGIS Cloud para QGIS

Como puede apreciarse en la imagen, una vez nos hemos autenticado podemos ver las BBDD que tenemos creadas, el espacio consumido, crear nuevas instancias de BD, subir datos, gestionar mapas, etc. El proceso de alta e instalación y uso es muy sencillo y está perfectamente explicado en el Quickstart. Mientras escribía este post he visto que hay un pequeño tutorial reciente en mappingGIS que explica lo mismo de manera más somera.

Actualmente se ofrecen dos planes Free y Pro. El plan Free permite la publicación ilimitada de mapas (públicos). En lo relativo a almacenamiento de datos: hasta 5 instancias de bases de datos PostGIS 2.0, con un espacio máximo total de 50MB y un número máximo de 10 conexiones concurrentes por base de datos. Lo cual, sobra decirlo, lo hace muy interesante para experimentar.

QGIS Cloud como DBaaS

Es posible, como sería mi caso en este momento, que no estemos interesados en publicar mapas y que lo único que nos interese es utilizar el servicio de bases de datos en la nube. Esto es perfectamente posible. Para ello basta con conocer los detalles de la conexión a nuestras bases de datos y utilizar la herramienta que deseemos tal y como se explica en las FAQ: PgAdmin, psql, QGIS... o cualquier software capaz de conectarse a un servidor PostgreSQL.

Los datos de conexión los podremos obtener del plugin, donde se muestra el nombre de la BD en el listado, que a su vez coincide con el nombre de usuario de la conexión. La contraseña la podremos ver en el tooltip que se muestra al posicionar el cursor sobre cada BD en el listado (algo incómodo pero no imposible). El host y puerto, los tenemos también en el tooltip y en las FAQ, así como un par de pantallazos de ejemplo para conectar desde QGIS y PgAdmin (debemos explicitar la instancia de BD en la conexión). En todos los casos es requerido el uso de SSL en la conexión.

Para terminar quiero comentar que no estoy en disposición de hacer valoraciones de calidad/nivel de servicio al no poder controlar todas las variables: limitaciones del plan gratuito, la velocidad de mi acceso a internet, etc., pero creo que para los fines que me proponía servirá. Espero que también para quien haya tenido a bien tragarse este ladrillo. ;)

Business Analytics con componente espacial

De manera general, en el mundo de la minería y análisis de datos (Business Intelligence, Business Analytics) se suele trabajar con colecciones de “individuos” sobre los que se tienen distintas observaciones (o variables). Por ejemplo, en un sistema de salud los individuos serían los pacientes y las variables todos los datos que sobre cada paciente sean relevantes para su historia clínica o más en especial la prevención o tratamiento de una determinada enfermedad. Con este tipo de técnicas de BI se pueden realizar clasificaciones (clusters), simulaciones, predecir una determinada variable (recaída en una determinada enfermedad, etc.) y tomar decisiones (prevención, etc.).

Análisis espacial
Cuando introducimos en el análisis la componente “espacial”, el “hecho” espacial, la localización de un fenómeno, pasa a convertirse en el “individuo” de la colección, ya que dicha localización es el elemento que permite que las distintas variables que se tengan sobre ella converjan sobre un mismo punto que permite relacionarlas.

Para ello, en primer lugar, se debe definir un “terreno de juego” común y conocido para todas las variables que se desean relacionar (correspondiente a un determinado territorio, puede ser toda la superficie de la tierra).

Es decir, toda la información deberá estar referida al mismo Sistema de Referencia Espacial (SRS). Un sistema de referencia muy conocido y aplicable a estos análisis cuando se trabaja a nivel global es el WGS 84 (EPSG:4326), dado que nos ofrece cobertura global y tiene una precisión suficiente que suele ser suficiente en este ámbito.

En segundo lugar, debemos considerar que los fenómenos que se producen sobre la superficie de la tierra y que aportan las variables pueden ser de dos tipos: discretos (el punto exacto donde se ha registrado un accidente de tráfico, por ejemplo) o continuos (por ejemplo la altura o elevación del terreno de un territorio).

Tipos de representación geográfica en GIS
Los sistemas de información geográfica (GIS) utilizan distintas aproximaciones a la hora de representar dichos fenómenos.

Así, para el primer tipo (fenómenos discretos), se utiliza la representación vectorial en la que los distintos “individuos” de una determinada variable (o capa, como en el caso del ejemplo el accidente de tráfico), se representan mediante puntos (un par de coordenadas X, Y), líneas o polígonos.

Para el segundo tipo (fenómenos continuos) se utilizan representaciones que permitan cubrir una superficie continua como por ejemplo las redes de triángulos irregulares (TINs, la base de los videojuegos actuales) o los rasters.

Un raster no es otra cosa que una malla regular de celdas (normalmente de forma cuadrada) que cubren completamente un espacio, que están referidos a un origen geográfico (debemos saber a qué punto de la realidad corresponde algún punto del raster, normalmente su esquina inferior izquierda)  y de cuyas celdas necesitamos conocer cuál es su resolución y extensión (es decir, cuál es el espacio geográfico abarcado por cada una de ellas y por todas ellas en conjunto).

Dentro de un raster, para cada celda conoceremos habitualmente:

• Un identificador de celda: normalmente un número secuencial que empieza en 1.
• El número de fila y el número de columna de cada celda: no es imprescindible ya que puede obtenerse si se conoce el identificador (posición) de la celda y el número de filas por celda.
• El valor de la variable representada.

Ejemplo de ráster: modelo digital de elevaciones.

En el ejemplo anterior, correspondiente a un modelo digital de elevaciones, el espacio objetivo está dividido en celdas, y para cada una de ellas se conoce el valor de la variable altura, que es representable en un mapa asignando un color distinto a cada uno de los valores (o rangos de valores) de altura.

Es decir, cada raster nos permite recoger el valor de una variable dentro de un espacio subdividido en celdas regulares, aportando cada celda el valor de la variable que se puede atribuir al espacio que delimita dicha celda.

Como puede deducirse, la precisión de la información estará condicionada por la resolución del raster (espacio real delimitado por cada celda) ya que todo el espacio comprendido dentro de una celda ha de asumir un mismo valor para la variable.

Asimismo, dependiendo de cuál sea el SRS elegido, las celdas podrán estar definidas en unidades de medida angulares (en sistemas de coordenadas geográficas) o en unidades lineales (en sistemas de coordenadas proyectadas).

Es frecuente el uso de rasters basados en celdas cuyo extensión se define en unidades de medida angular (esto equivale a realizar una proyección Plate Carrée en el raster resultante) ya que facilitan el trabajo a nivel global. Nótese que en ese caso debe asumirse la variabilidad de la resolución de las celdas dado que la distancia lineal de un grado de longitud en el Ecuador y en los Polos no es la misma (siendo cero en los Polos).

No obstante lo anterior, los raster permiten relacionar espacialmente distintas variables de manera directa e inmediata ya que, dadas dos variables referidas al mismo espacio (espacio definido por el raster, es decir, origen, extensión y resolución) la relación espacial de ambas la obtendremos a través del número de celda al que pertenecen, esto es, podemos decir que el número de celda nos define el “individuo” (que en este caso es la porción de espacio definida por la celda) y sobre él podremos agrupar y relacionar los distintos valores de las distintas variables que se tengan sobre él.

Por tanto, un raster puede reducirse a una colección de valores numéricos y literales (datos alfanuméricos), y un conjunto de rasters puede entenderse como una matriz o tabla, en la que cada fila se corresponde a cada una de las celdas (identificada mediante un número único que facilita los procesos posteriores) del raster y en la que cada columna representa cada una de las variables obtenidas de cada uno de los raster originales.

El identificador de celda, fila y columna los podemos considerar variables aportadas por un raster base que nos define el espacio o “terreno de juego”.

A partir de aquí,  se podrán aplicar técnicas de análisis tradicionales y las herramientas del ámbito del BI como pueden ser Stata o el lenguaje y herramientas de código abierto R (http://www.r-project.org) sobre dichas tablas o matrices de datos alfanuméricos.

Descripción del proceso
Se describe a continuación los pasos principales para realizar un análisis de distintas variables referidas al espacio con la aproximación raster:

1. Deberá definirse un “terreno de juego” común, es decir un raster base que abarque todo el espacio objetivo del análisis y que tenga la resolución necesaria. Al tratarse de un espacio geográfico su origen y tamaño de cada celda deberá estar referido a un determinado SRS. Necesitaremos también una representación vectorial de dicho raster para el tratamiento de la información vectorial de la que dispongamos: por cada celda de nuestro raster tendremos un polígono que delimite su extensión que tendrá como atributos (o campos temáticos) el identificador de la celda (y opcionalmente sus coordenadas de fila y columna).
2. Todas las fuentes de información deben estar referidas al mismo SRS que el raster base para lo cual se deberán realizar las transformaciones necesarias mediante el uso de herramientas GIS como QGIS.
3. La información vectorial deberá rasterizarse, es decir, deberemos obtener una capa raster por cada variable de las capas vectoriales que dispongamos. Esto puede hacerse mediante análisis espacial, concretamente por intersección de las capas vectoriales y la capa raster base representada en forma vectorial. Debemos tener en cuenta que un mismo fenómeno representado vectorialmente puede solapar con varias celdas de nuestro raster base. En este caso no es preciso que el raster resultante esté en un formato GIS, basta con tener el resultado alfanumérico que nos indique cuál es el valor que le corresponde a cada celda del raster, siendo inicialmente dos los valores posibles: que en dicha celda exista intersección con la capa vectorial o que no. Estos valores pueden incrementarse con los dos distintos valores de los atributos (campos temáticos) de la capa vectorial original.
4. La información raster que dispongamos puede requerir transformación en caso de que su resolución no sea la misma que la del raster base. En caso de que la resolución sea mayor que la del raster base se realizará un proceso de generalización. En caso de que sea menor se tendrá que asumir la resolución de la fuente original.
5. Una vez se tenga toda la información en formato raster y referida al mismo raster base se deberá exportar a un formato alfanumérico admitido por los programas de BI / análisis estadístico.
6. Se realiza el proceso de análisis estadístico multi-variable siguiendo las técnicas de análisis tradicionales.
7. El resultado del análisis, se podrá representar en un mapa. Ejemplo: si como resultado del análisis se ha predicho el valor de una nueva variable, dicha variable estará referida a una celda y podrá ser representado en un mapa en forma de raster. Para ello pueden utilizarse las capacidades de ploteo de los paquetes de BI mencionados o se podría exportar la variable a un formato raster o vectorial (raster vectorizado) comprensible por un GIS.

Inspección de datos GIS

Existen proyectos de implantación de nuevos sistemas informáticos en los que es necesario realizar una migración de datos existentes en sistemas anteriores. En estos procesos es posible que se tenga que contar también con nueva información resultante de un proyecto de actualización o mejora general del sistema.

Para ello tendremos que entender la naturaleza de los datos que tendremos que migrar o integrar en el nuevo sistema. Esto implica:

• Conocer el medio físico del que obtendremos los nuevos datos: bases de datos, ficheros, etc.
• Conocer el significado de la información y cómo se ha estructurado e implementado: entidades, tipos de datos y las relaciones lógicas entre las entidades.

Para ello, además de toda la documentación de la que podamos disponer, necesitaremos inspeccionar los datos, de manera que podamos asegurarnos de la validez de la documentación (si la hay) y resolver dudas concernientes a la realidad de los datos, su semántica y calidad.

Del resultado de la inspección se podrá obtener un conocimiento más preciso de los datos de partida que se traducirá en decisiones relacionadas con la estrategia de carga de los datos y con las acciones necesarias para la corrección, transformación y mejora de los datos para su correcto encaje en el nuevo sistema.

Para ello haremos uso de herramientas como clientes de consulta SQL para chequear la información existente en bases de datos, visores de hojas de cálculo, editores de texto o la herramienta que mejor se ajuste al medio en cada momento.

En el caso de un GIS (Sistema de Información Geográfica) la necesidad de inspeccionar los datos es la misma pero se han de utilizar técnicas y herramientas acordes a la naturaleza de la información que se maneja, esto es, la información geográfica.

Para ello es habitual el uso de herramientas de escritorio que permiten la consulta de diversos orígenes de datos como:

• Bases de datos geográficas: Oracle, SQL-Server, Postgres/PostGIS son ejemplos de bases de datos relacionales con soporte a tipos de datos espaciales.
• Ficheros con información geográfica: Shapefiles, KML/KMZ, etc.
• Servicios interoperables OGC: WMS, WFS,  etc.

Existen una amplia variedad de herramientas comerciales y de código abierto entre las que se encuentran:

•  QGIS: basado en C++, muy completo a día de hoy y sigue creciendo con una amplia base de desarrolladores.
• uDig GIS: basado en java, más sencillo pero funcional y muy recomendable para adentrarse en este mundo y para ser integrado en aplicaciones basadas en java.

Además de estas herramientas específicas del ámbito GIS seguirán siendo de utilidad las mismas herramientas para la inspección de los datos desde las perspectivas "relacionales" tradicionales.

Metadatos
Por último es importante recordar la importancia que en todo sistema de información deberían tener los metadatos, que en términos sencillos son: datos relativos a los datos. Más aún en el ámbito de la información geográfica en la que parámetros como la precisión, las técnicas de recolección, la frecuencia de actualización, etc., son aspectos clave a la hora de aplicar los datos a la hora de realizar cualquier implantación de sistemas o trabajos de análisis geoespacial (ver estándares de metadatos GIS).