Gestión de la Información.

Una gestión de la información adecuada, no solo desde el punto de vista de la gestión de activos, sino desde una perspectiva más general, es siempre beneficiosa para nuestro negocio y nos permitirá tomar medidas  adecuadas a nuestras necesidades, por supuesto la información geoespacial no es una excepción.

Sin embargo, una buena estrategia de gestión de la información, no significa necesariamente, que tengamos que poseer un conocimiento exhaustivo del total de nuestros activos, de hecho, ésto es muy poco habitual, y por lo general, el coste económico para alcanzar este objetivo, está fuera del alcance de cualquier empresa, y por lo general se podría considerar una mala práctica para el negocio.

Por ejemplo, imaginemos que nuestra compañía se dedica a la distribución de agua para consumo humano. Tenemos una planta desaladora y dos localidades a las que abastecer. La primera está junto a la desaladora y la segunda, a unos 50 km. Sabemos que la información almacenada en nuestro GIS de la localidad más cercana es bastante completa y precisa. Sin embargo, la otra localidad, incluyendo la línea de conexión no está registrada en nuestro sistema. En total se estima que representa un 70% del total de nuestra red.

A primera vista se podría decir que el conocimiento de nuestra red es bastante pobre, y realmente lo es, pero si en lugar de aplicar un enfoque clásico, lo hacemos desde el punto de vista de la gestión de activos físicos, hay más factores a tener en cuenta que los meramente estadísticos.

Estudiando más a fondo el ejemplo, la localidad más alejada resulta ser una zona de viviendas unifamiliares, usadas mayormente durante fines de semana y vacaciones. Por el contrario la ciudad cercana a la planta, está compuesta por edificios de varias alturas, y su ocupación es elevada a lo largo de todo el año.
Es aquí donde entran en juego la criticidad, la priorización, el análisis de riesgos y el análisis de coste-beneficio.

Lo primero que nos tendremos que preguntar ante una situación como la descrita arriba, es, si la falta de información realmente supone una gran pérdida, en el sentido más amplio de la palabra, para la compañía, o si por el contrario es ¨algo¨ con lo que podemos vivir. Para ello, y aplicando una buena estrategia de gestión de activos, tendremos que analizar y clasificar los elementos de nuestra red, teniendo en cuenta diversos factores, para establecer así que activos son más "importantes" (priorización) basándonos en las consecuencias ocasionadas por una falta de suministro (análisis de riesgo y criticidad).

En base a lo anterior, es momento ahora de plantearse si la falta de información en nuestro sistema, necesita ser solucionada, y si el coste económico de hacerlo aporta beneficios suficientes (del tipo que sean), o por el contrario, podemos asumir el riesgo de no hacerlo.

Siguiendo con el ejemplo anterior, imaginemos ahora que en la localidad más alejada, se está construyendo un hospital que estará conectado a nuestra red de abastecimiento, en este caso nos tendremos que replantear nuevamente nuestra estrategia, ya que en este caso la criticidad de nuestro activos se verá afectada, y por lo tanto la priorización de los activos tendrá que ser revisada.

Así pues la falta de información, no es necesariamente algo que tengamos que subsanar inmediatamente, primero tendremos que evaluar si realmente la necesitamos para gestionar de una manera eficiente nuestros activos.

Modelos con FME

Siguiendo con la entrada anterior, me gustaría introducir en este caso un Software que complementa, y en muchas ocasiones aporta nuevas funcionalidades a ArcGIS (no en vano, éste, está integrado dentro de la extensión Data Interoperability del Software de la casa ESRI).

Este programa se engloba dentro de los procesos conocidos como ETL (Extract, Transform and Load o extraer, transformar y cargar), que permiten exportar, importar, analizar y limpiar datos entre distintos formatos y/o plataformas.

FME, software desarrollado por la casa Safe Software, es una fantástica herramienta ETL mayormente centrada en la manipulación de información geoespacial. Aparte de la multitud de formatos admitidos y transformadores que posee el programa, otro gran punto a su favor es la facilidad a la hora de crear modelos o herramientas, en parte gracias a su interface sencilla e intuitiva.

Así pues, es posible crear modelos como el que presentamos anteriormente en Model Builder sin la necesidad del uso de ArcGIS. Igual que comparábamos ModelBuilder con  una especie de lenguaje programación a alto nivel, FME permite aún más funcionalidades que el módulo de ArcGIS, y siguiendo con la analogía, se podría decir que tiene muchas más clases y métodos con los que implementar nuestro programa, ofreciéndonos así   una gama mucho más amplia de posibilidades.

A grandes rasgos el funcionamiento del programa es el siguiente: Tenemos un dato (o conjunto de datos) de entrada, a los cuales les aplicaremos uno (o varios) procesos, llamados transformadores, que arrojaran como resultado uno o varios ficheros de salida. Así por ejemplo, teniendo un fichero en formato DWG de líneas que representan el contorno de las fincas rústicas de un municipio, necesitamos como resultado un fichero en formato SHP poligonal. En el programa indicaremos el fichero de entrada “Reader” que será el fichero en formato DWG, el transformador apropiado, en este caso “AreaBuilder” y por último definiremos el formato del fichero de salida o “Writer”

Otra gran ventaja del programa es que permite manejar una amplia multitud de formatos tanto GIS y CAD como otros formatos tabulares, archivos Excel y Bases de Datos por ejemplo. Así pues podremos realizar uniones entre tablas de una base de datos Oracle y un shapefile de una manera muy sencilla y eficiente.

En futuras entradas se presentaran varios ejemplos desarrollados, tanto en ArcGIS como en FME, y se intentará evaluar cuál de los dos métodos es más eficiente, tanto en el proceso de elaboración, como a los resultados arrojados.

Crear modelos en ArcGIS. Model Builder.

En esta ocasión voy a rescatar una de las entradas de mi antiguo No-Blog. Como ya mencioné, las entradas desarrolladas en aquella ocasión eran más técnicas, y 100% relacionadas con los Sistemas de Información Geográfica. En este caso la entrada trata sobre Model Builder, una utilidad incluida dentro de ArcGIS que nos permite la automatización de tareas de una manera intuitiva y más o menos sencilla. Se podría decir (pido perdón de antemano a los desarrolladores informáticos) que es una especie de programación a muy alto nivel, en la cual de hecho, cuantos más conocimientos se tengan de programación, mejores y más completos modelos se podrán crear.

Cuando trabajamos con datos geoespaciales en muchas ocasiones nos encontramos con que estos están divididos geográficamente por una gran diversidad de factores: límites administrativos, barreras geográficas, cambios de usos de suelos… En estos casos es posible que la información la tengamos segmentadas en distintos ficheros, y por diversas razones no podamos (o queramos) unificarlos en uno solo. El problema se nos presenta cuando necesitamos realizar uno o varios procesos sobre estos ficheros, ya que tendríamos que procesarlos de manera individual, con la pérdida de tiempo que ello supone, y la posible pérdida de precisión de los datos.

Para solventar este problema tenemos, principalmente, dos posibilidades: la primera es la creación de scripts o programas que automaticen estos procesos para lo cual evidentemente tendremos que saber programar en algún lenguaje, lo cual no suele estar al alcance de los que nos dedicamos a los GIS, en una perspectiva más aplicada al análisis de información, y a la gestión de datos geoespaciales. Por otro lado ArcGIS nos ofrece la oportunidad de crear modelos para encadenar subrutinas y herramientas implementadas dentro del propio programa (o incluso externas), utilizando datos de muy diversas fuentes y formatos. En definitiva Model Builder (asi se llama esta utilidad de ArcGIS), nos permite automatizar procesos y crear modelos que nos evitarán tener que repetir una y otra vez sobre toda la colección de datos los mismos procesos rutinarios. Es evidente que tiene sus limitaciones y no nos da tanta flexibilidad como lo haría la programación en Python u otros lenguajes, pero bien aplicado es una herramienta muy potente que nos ahorrará muchas horas de trabajo.

Por ejemplo supongamos que tenemos una serie de ficheros en formato .dwg de AutoCad del parcelario rustico de un determinado termino municipal. Supongamos también que el fichero está compuesto por líneas y textos, las líneas delimitan las parcelas y los textos indican el uso rustico de las mismas. Si el objetivo del trabajo que nos encomendasen fuese calcular la superficie total de cada cultivo en concreto necesitaríamos realizar una serie de procesos que pasarían por la importación de los datos a formato .shp (u otro operativo dentro de ArcGIS), y después toda la serie de procesos para crear las superficies, identificarlas a través de sus etiquetas y por ultimo calcular las superficies de cada uso.

Para alguien familiarizado con ArcGIS el proceso no es muy complicado en sí, pero si por ejemplo en lugar de un único termino municipal, son varios, el tiempo en realizar todos los procesos se ve significativamente incrementado. Como hemos dicho antes, para este tipo de situaciones existe ModelBuilder. Es posible que cuando abramos por primera vez está utilidad nos planteemos si realmente nos va a suponer un ahorro real de tiempo, ya que la creación del modelo nos llevará, en sí,  cierto tiempo, para ello debemos valorar el volumen de datos a procesar, y cuantificar el tiempo efectivo del procesado de los datos, frente al tiempo de creación del modelo. En nuestro ejemplo hemos cuantificado que realmente el volumen de datos es suficientemente grande como para “perder” tiempo en la creación del modelo.

El primer paso será crear un Toolbox vacía que almacenará nuestro modelo, para ello dentro de ArcCatalog en la carpeta deseada pulsaremos el botón derecho del ratón y añadiremos la caja de herramientas , y nuevamente con el botón derecho sobre esta, añadiremos un nuevo modelo.

Esto nos abre el interfaz de desarrollo para crear el modelo desde cero. Como vemos existen diferentes opciones, y herramientas para implementar nuestro modelo. Además podemos arrastrar sobre este las distintas herramientas de ArcToolbox, o datos del catálogo, para añadir nuevas utilidades a nuestro modelo. Así pues y después de varias pruebas el modelo quedaría de la siguiente manera. La forma de realizar el modelo, es arrastrar los distintos elementos que lo van a componer y definir los distintos parámetros de cada herramienta.

 

Los pasos que sigue el modelo son en resumidas cuentas los siguientes:

1. Trasformación de las líneas en polígonos.

2. Join espacial de los polígonos creados y la capa de etiquetas.

3. Añadimos un campo que almacenará las superficies.

4. Calculamos las superficies de cada polígono y lo añadimos al campo anterior.

5. Creamos la tabla de salida con los sumatorios de las superficies de cada cultivo en concreto

Así pues partiendo de los datos en formato CAD de las líneas del parcelario (topológicamente conectadas) y de las etiquetas de los usos rústicos conseguimos un resumen de las superficies de cada tipo de uso.

 

La importancia de los GIS en la Gestión de Activos

Me gustaría aclarar en este punto que un SIG no tiene por qué ser, y normalmente no lo es, el único componente de un sistema de Gestión de la Información dentro de una compañía que se dedique a la gestión de activos físicos. Suele ser, por el contrario, un componente más, dentro de este sistema que lo engloba, junto con otros, por ejemplo: gestión de incidencias, sistemas de adquisición de datos en tiempo real, BBDD, etc.

A pesar de ser una parte integrante de un conjunto que puede ser muy amplio, es (y en este caso es mi opinión personal), en la mayoría de los casos, el que más relevancia tiene, al ser la componente geoespacial, un factor determinante en la mayoría de las industrias o negocios de este tipo, y aunque mucha información relacionada con un activo físico no dependa de su localización de una manera directa, ésta es determinante en muchos aspectos.

Por ejemplo en una red de saneamiento una sección de tubería con unas determinadas características (por ejemplo diámetro, pendiente y material) teóricamente cumplirá su función de transportar un caudal determinado de agua, sin importar su localización espacial, ya que éste está determinado por las dimensiones de la tubería y la velocidad del agua. 

Sin embargo a parte de las características físicas, e hidrodinámicas de la tubería, hay otros factores a tener en cuenta, sobre todo desde el punto de vista de la gestión de activos, que vienen determinados por su localización espacial, y su relación con otros elementos de la red y del entorno, por ejemplo los componentes geoquímicos del suelo. Evidentemente todos estos factores pueden ser considerados sin la utilización de un SIG, pero la manera más óptima de realizarlo es con herramientas que permitan realizar un análisis geoespacial, sobre todo cuando el volumen de datos es considerablemente grande.

Otro factor que hace necesario el uso de un GIS en la gestión de activos físicos, es que estos han  de ser operados y mantenidos, y para que estas actividades sean eficientes, la localización de estos ha de ser perfectamente conocida para, por ejemplo, minimizar el tiempo de respuesta ante una incidencia y reducir así el posible impacto por una interrupción en el servicio.

En definitiva la Gestión de Activos es una cuestión compleja, en la cual hay muchos factores a tener en cuenta, pero sin duda uno de los más importantes es la localización espacial del activo, y su relación con otros elementos, sean estos parte del negocio, o no.