Vinko Vrsalovic Centro de Estudios en Percepcion Remota y SIG. Santiago, Region Metropolitana, Chile

Vinko, por que empezaste a usar PostgreSQL ?

Empecé a usar PostgreSQL porque necesitaba de bases de datos 'espaciales'. Previamente había utilizado Oracle, MSSQL y MySQL, la primera y la segunda por obligación, la tercera simplemente por ser la más conocida en esa época.
Ahora que ya llevo un tiempo usando PostgreSQL, me costaría dejar de usarla

Que resultado te ha dado su uso ?

Satisfactorio hasta el momento.
Lo único que ha sido un poco molesto es la migración de bases de datos entre versiones, que es levemente engorrosa.

Recomendarias el uso de PostgreSQL a otros programadores ?

Claro que sí.
Su flexibilidad, relativa facilidad de uso (la mantención es un poco más complicada), excelente documentación y robustez la hacen una buena elección en múltiples escenarios, y eso sin siquiera entrar en temas filosóficos y enunciar los beneficios que tiene que sea Open Source.

Sabemos que trabajas con PostGIS.
Podrias explicarnos que es precisamente PostGIS y de que forma potencia a PostgreSQL?

La forma tradicional de almacenar información espacial Digitalmente es utilizar algún formato de los programas SIG 'de escritorio' como ArcView, MapInfo o GRASS.

En general estos formatos son poco flexibles y bastante anticuados, típicamente son un conjunto de archivos que almacenan la información sobre las coordenadas, proyección espacial y los datos asociados a cada elemento.

El formato más común utiliza archivos DBF para almacenar los datos, el que presenta muchas limitaciones que parecen totalmente arbitrarias en el día de hoy como por ejemplo nombres de campos limitados a 10 caracteres, 3 ó 4 tipos de
datos, entre otras.

En cambio, PostGIS (y en general cualquier extensión espacial a un RDBMS) soluciona estos problemas y además, permite una mucho mayor flexibilidad porque hace posible realizar operaciones espaciales en la fuente de datos misma, lo que trae varias ventajas, entre ellas:

- Alivia la vida del programador, puesto que evita el tener que implementar esas operaciones en la aplicación (intersección, búsqueda por cajas, proyección geografica de los datos, etc.).

Ademas se puede optar por desarrollar partes de la lógica de la aplicación vía procedimientos almacenados, o generar nuevos conjuntos de datos a partir de los existentes de manera mucho mas fácil a través de vistas, subselects, joins o
tablas temporales.

- Permite un mayor control sobre la aplicación, al separar los datos del lugar donde se encuentra la aplicación (y no tener necesariamente que compartir archivos vía un sistema de archivos distribuido si queremos separar los datos de la aplicación).
Este control presenta beneficios en varios niveles, como el de poder distribuir la carga hacia el RDBMS, o a la aplicación, según el tipo de aplicación y sus características, o correr en máquinas distintas el servidor espacial (de haberlo) y el
RDBMS.

PostGIS es simplemente una extensión a PostgreSQL, que define nuevos tipos de datos, crea dos tablas con información relevante al sistema (proyección de los datos y columna que posee la información geográfica) y define también las funciones de manejo de información como procedimientos almacenados.
Además trae interfaces para servir de fuente de datos a MapServer, y a herramientas que utilizan OGR
(http://gdal.velocet.ca/projects/opengis/), cuyo soporte está en alpha en estos momentos.

PostgreSQL + PostGis podria llegar a competir con sistemas como Oracle Spatial Extension?

No he tenido la oportunidad de usar Oracle Spatial ni ArcSDE, pero según los planes de desarrollo, para la versión 1.0 debiera ser más o menos equivalente en capacidades a las alternativas comerciales.
Además de implementar la "Simple Features Specification for SQL"
(http://www.opengis.org/techno/specs/99-049.pdf)
de manera completa al llegar a 1.0, se va a tener un conjunto relativamente grande de interfaces para la interacción con PostGIS.
Sin embargo, con la funcionalidad del día de hoy (0.7.3), para las aplicaciones que me ha tocado desarrollar, basta y sobra.

Cual es el visualizador (viewer) que graficamente despliega la informacion espacial, o cual sugieres ?

En estos momentos la única interfaz que funciona sin problemas es la interfaz hacia MapServer, que está diseñado para presentar la información espacial vía WWW.

Sin embargo, hay varias otras interfaces que con un poco más de trabajo pueden hacerse funcionar y, por último, siempre puedes implementar tu propia interfaz hacia el programa que quieras, usando libpq. Dependiendo del programa, esto puede ser desde algo trivial hasta algo super complicado.

(continua en la columna der.)

(viene de la columna izq.)

Cuales son los pasos para dejar operativo a PostgreSQL con PostGis ? (a "Grosso Modo")

Instalar PostgreSQL, si se instala desde paquetes, instalar el paquete devel.
Luego copiar PostGIS al directorio contrib, correr make y luego correr unos scripts SQL en la base de datos que se va a usar, que generan los tipos de datos y las tablas necesarias para su funcionamiento.
Luego se deben poblar las tablas, hay utilidades para importar y exportar del formato más común, y también hay procedimientos que permiten el ingreso 'manual' de datos; si son muchos se debe hacer un script "ad hoc".

Tienes algunas lineas de codigo de PostgreSQL y PostGIS, a modo de ejemplo ?

Este ejemplo es un query generado automáticamente por una de las aplicaciones que estoy desarrollando, que genera una clasificación dinámica de las comunas de una región basado en un valor arbitrario, en este caso, por la suma de la población de Aymaras, Rapa Nui y Mapuche en la segunda región.
Esto me permite pintar de distintos colores las distintas comunas según un cierto criterio, como la cantidad de población, o el número de camas por habitante, o el índice de criminalidad, etc.

A Mapserver le digo simplemente que pinte de color X las comunas que tengan valor 0 en la columna MYEXP, de color Y las que tengan valor 1 en MYEXP, etc.
Esto, sin PostGIS, significaría acceder a la base de datos con datos de población, abrir el archivo de datos, leerlo registro por registro, compararlo con los datos traídos de la base y generar otro archivo con los datos para la clasificación y luego desplegar ese archivo

select the_geom from
(select map.the_geom, map.nombre, map.oid , case
when data.value >= 14 and data.value <= 14 then '0'
when data.value >= 45 and data.value <= 45 then '1'
when data.value >= 78 and data.value <= 78 then '2'
when data.value >= 283 and data.value <= 283 then '3'
when data.value >= 303 and data.value <= 303 then '4'
when data.value >= 464 and data.value <= 464 then '5'
when data.value >= 785 and data.value <= 785 then '6'
when data.value >= 4630 and data.value <= 4630 then '7'
when data.value >= 10032 and data.value <= 10032 then '8'
else 'resto' end as MYEXP from chile_poly as map,
data_temp as data
where map.cod_ine = data.cod_ine) as expqry

El siguiente ejemplo es un ejemplo de uso de las funciones espaciales en sentencias SQL, también generado de manera automática:

SELECT c.region, c.provincia, c.comuna, d.value as atributo
FROM chile_poly c, data_temp d
WHERE c.cod_ine = d.cod_ine
AND
GeometryFromText('BOX3D(294290.4863388 6265788.7355191, 294290.4863388
6265788.7355191)::box3d',-1) && the_geom
AND
truly_inside(the_geom,'BOX3D(294290.4863388 6265788.7355191,
294290.4863388 6265788.7355191)::box3d')

Aquí vemos el uso de dos funciones y un operador PostGIS.

La función GeometryFromText genera un 'string espacial' a partir de las coordenadas y el tipo de datos que recibe, en este caso es una caja (que en realidad representa un punto) elegida por el usuario, luego eso se compara con la columna de datos espaciales the_geom mediante el operador &&, que determina si la caja que contiene a A (GeometryFromText(...)) se intersecta en algún punto con la que contiene a B (the_geom).

Luego necesitamos determinar si la caja seleccionada por el usuario está realmente dentro del objeto geométrico, para esto se usa la función truly_inside(), que compara vértice con vértice y no solo las cajas que contienen al objeto.

Si se fijan, bastaría sólo con utilizar truly_inside() pero debido a razones de rendimiento, es aconsejable primero acotar el espacio de búsqueda mediante los operadores que trabajen sobre las cajas que contienen a los objetos, como &&, ya que ese tipo de operaciones aprovechan los índices, para luego comparar vértice a vértice la menor cantidad de datos posible.

Este query obtiene los datos que existen en la base asociados a un cierto objeto seleccionado por el usuario, que, en el caso presentado, son la región, provincia, comuna y el valor arbitrario que se usa en el primer query que muestro.

Que sitios visitas habitualmente para apoyar tu labor de desarrollo ?

Principalmente obtengo información de las listas de correo relevantes (mapserver-users, postgis-users, etc).
Además uso los manuales de www.postgresql.org/idocs y, por supuesto, Google.

Que otras bases de datos manejas y como puedes compararlas con PostgreSQL ?

Manejé un tiempo Oracle y después de conocer Postgres me parece que trae demasiadas complicaciones innecesarias para gran parte de los casos, partiendo por el parto que es la instalación en Linux.
He usado MySQL y también MS Sql Server.

MS Sql Server y su política de la 'lotería de la muerte' lo hace bastante desagradable para el programador o el usuario final.

A MySQL aun le falta mucho.

En resumen, PostgreSQL la lleva :-)

Algo mas que quisieras agregar ?

Si algo no quedó claro, o están interesados en conocer más sobre SIG y sus aplicaciones, no duden en contactarme.

Gracias por el espacio.

Gracias a ti,Vinko.