REINGENIERÍA Y OPTIMIZACIÓN: SISTEMA DE MAPEO DIGITAL … · Universidad de Chile Facultad de...
75
Universidad de Chile Facultad de Ciencias Físicas y Matemáticas Departamento de Ciencias de la Computación REINGENIERÍA Y OPTIMIZACIÓN: SISTEMA DE MAPEO DIGITAL Tesis para optar al grado de Magíster en Tecnología de la Información JOSE MIGUEL RODRIGO BASUALTO PROFESORA GUÍA: Nancy Hitschfeld Kahler MIEMBROS DE LA COMISIÓN: Carlos Hurtado Larrain Cecilia Rivara Zúñiga Andrea Rodríguez Taste Santiago de Chile Marzo 2007
Transcript of REINGENIERÍA Y OPTIMIZACIÓN: SISTEMA DE MAPEO DIGITAL … · Universidad de Chile Facultad de...
Universidad de Chile Facultad de Ciencias Físicas y Matemáticas
Departamento de Ciencias de la Computación
REINGENIERÍA Y OPTIMIZACIÓN: SISTEMA DE MAPEO DIGITAL
Tesis para optar al grado de
Magíster en Tecnología de la Información
JOSE MIGUEL RODRIGO BASUALTO
PROFESORA GUÍA: Nancy Hitschfeld Kahler
MIEMBROS DE LA COMISIÓN:
Carlos Hurtado Larrain Cecilia Rivara Zúñiga
Andrea Rodríguez Taste
Santiago de Chile Marzo 2007
2
Universidad de Chile Facultad de Ciencias Físicas y Matemáticas
Departamento de Ciencias de la Computación
REINGENIERÍA Y OPTIMIZACIÓN: SISTEMA DE MAPEO DIGITAL
Tesis para optar al grado de
Magíster en Tecnología de la Información
JOSE MIGUEL RODRIGO BASUALTO
PROFESORA GUÍA: Nancy Hitschfeld Kahler
MIEMBROS DE LA COMISIÓN:
Carlos Hurtado Larrain Cecilia Rivara Zúñiga
Andrea Rodríguez Taste
Santiago de Chile Marzo 2007
3
RESUMEN La información geológica constituye uno de los eslabones estratégicos fundamentales para la explotación minera. La División El Teniente cuenta con una inmensa cantidad de información geológica que ha sido levantada desde hace 50 años. A partir del año 2000, el autor comienza a innovar en la Superintendencia Geología de la División El Teniente, desarrollando e implementando un sistema digital de mapeo estructural. Luego participa en el desarrollo de la versión 3.1 del software GVMapper. A partir de este último software, desarrolla una serie de cambios destinados a conseguir la compatibilidad con una base de datos Oracle, entre otros objetivos. Así se llegó al denominado Mapeador Digital, que adolece de una serie de falencias arquitectónicas y técnicas que son abordadas en esta tesis. El producto de esta reingeniería es denominado en este documento como Sistema de Mapeo Digital o SMD.
El SMD es un sistema de software que permite la creación e implementación de un código de mapeo estándar, el cual es distribuido automáticamente a los usuarios mediante interfaces gráficas que apoyan el mapeo en terreno tanto de sondajes como de mapas. Este sistema además sincroniza la información creada y/o modificada localmente por los usuarios, con una base de datos central Oracle 9i.
En esta tesis se hizo una revisión crítica de la implementación actual del SMD en términos del modelo de datos subyacente, de la arquitectura del software que actualmente está funcionando y de la plataforma de desarrollo utilizada, desde el punto de vista del escalamiento y la interoperabilidad. A partir de esta revisión se estableció un plan de acción, parte del cual fue llevado a cabo en este trabajo.
Los cambios realizados se han traducido en diversas mejoras en términos de normalización de la estructura de datos, así como en el rendimiento de la aplicación de despliegue gráfico. Dichos cambios ya se encuentran en producción.
La mayor normalización de la base de datos ha permitido el acceso a la información por usuarios no familiarizados con el uso del SMD. El reemplazo de los campos binarios por campos numéricos ha permitido acceder a la información contenida en ellos por vía de simple SQL, disminuyendo drásticamente la dependencia del SMD por parte de la Superintendencia Geología.
Para hacer posible el escalamiento del SMD, se ha definido a Visual Studio 2005 y, en particular, al lenguaje C# como la plataforma de desarrollo futuro, en caso de seguir contando con los mismos recursos físicos y humanos hasta ahora disponibles.
El éxito que ha tenido el mapeo digital durante sus seis años de funcionamiento y evolución se ha debido fundamentalmente a que su desarrollo ha estado siempre ligado estrechamente con el negocio al que apoya, en este caso la Geología.
El desarrollo histórico del SMD, incluyendo esta tesis, se ha llevado a cabo mediante una estrategia poco convencional, sin equipo de diseño, desarrollo y pruebas bien definidos. El diseño y desarrollo han estado a cargo del autor, mientras que las pruebas, en general, son realizadas por los usuarios más experimentados.
4
AGRADECIMIENTOS Agradezco a mi esposa Annabella quien me motivó a seguir este magíster y me apoyó durante el arduo desarrollo del trabajo que significó el SMD, durante estos últimos cuatro años, el que incluyó muchos fines de semana.
El autor desea agradecer además a todos los miembros de la Superintendencia Geología de la División El Teniente, quienes han colaborado constantemente mediante el uso del Sistema de Mapeo Digital y sus constantes contribuciones para depurarlo y mejorarlo.
5
TABLA DE CONTENIDO
RESUMEN 3
AGRADECIMIENTOS 4
1. INTRODUCCIÓN 7
1.1 SISTEMA DE MAPEO DIGITAL 8 1.2 HISTORIA DEL SMD 13 1.3 MODELO CONCEPTUAL DEL SMD 15 1.4 OBJETIVO GENERAL 17 1.5 OBJETIVOS ESPECÍFICOS 17 1.6 APORTE DE ESTA TESIS 17 1.7 LIMITACIONES 18 1.8 METODOLOGÍA 18
2. ESTADO DEL ARTE EN EL MERCADO 20
2.1 ENCOM DISCOVER 6.1 20 2.2 GEOROVER 20 2.3 OASIS MONTAJ 20 2.4 ARCINFO 21 2.5 GVMAPPER 21
3. ANÁLISIS Y MODIFICACIONES AL MODELO DE DATOS 24
3.1 MODELO ENTIDAD-RELACIÓN 25 3.2 SOPORTES DE INFORMACIÓN 27 3.3 TEMAS Y REGLAS DE MAPEO 29 3.4 INFORMACIÓN DE MAPEO 33 3.5 TABLAS DE ELEMENTOS MAPEABLES 37 3.6 ESTILOS DE MAPEO 40 3.7 CONCURRENCIA 40 3.8 REPOSITORIO LOCAL DE INFORMACIÓN 41
4. REPROGRAMACIÓN DEL SMD 43
4.1 PLAN DE ACCIÓN 43 4.2 LENGUAJE DE PROGRAMACIÓN 45 4.3 ARQUITECTURA PROPUESTA 47 4.4 REPROGRAMACIÓN DE APLICACIONES EN VISUAL BASIC 6.0 48 4.4.1 PROCESADOR DE SOLICITUDES 48 4.4.2 CONFIGURADOR 49 4.4.3 MAPEADOR DE MAPAS 54
6
4.4.4 MAPEADOR DE SONDAJES 57 4.4.5 MAPEADOR: UNIFICACIÓN DE SONDAJES Y MAPAS 58 4.4.6 IMPORTADOR DE VECTORES 59 4.5. PROTOTIPO DEL MAPEADOR DE ELEMENTOS 2D 60 4.5.1 ACCESO A LA BASE DE DATOS LOCAL 61 4.5.2 INTERFAZ GRÁFICA DE USUARIO 62
5. CONCLUSIONES Y RECOMENDACIONES 66
5.1 CONCLUSIONES 66 5.2 RECOMENDACIONES 67 5.2.1 ACCESO A DATOS 67 5.2.2 PROTOCOLO DE COMUNICACIÓN Y TRANSMISIÓN DE DATOS 68 5.2.3 ASPECTOS ADMINISTRATIVOS 68
6. BIBLIOGRAFÍA 69
ANEXO A: GLOSARIO 70
ANEXO B: DESCRIPCIÓN GLOBAL DEL SMD Y SUS COMPONENTES 72
B.1 CONFIGURADOR 72 B.1.1 CREACIÓN DE CUENTAS DE USUARIO Y PERFILES 72 B.1.2 CREACIÓN DE TEMAS DE MAPEO 72 B.1.3 CONSULTA DE INFORMACIÓN 73 B.1.4 CREACIÓN Y EDICIÓN DE ELEMENTOS MAPEABLES 73 B.1.5 IMPORTACIÓN DE IMÁGENES Y PLANOS VECTORIALES 73 B.1.6 CREACIÓN DE PROGRAMAS DE SONDAJES 74 B.1.7 ADMINISTRACIÓN DE PARÁMETROS CRÍTICOS 74 B.2 SERVIDOR Y PROCESADOR 74 B.2.1 SERVIDOR 74 B.2.2 PROCESADOR 75 B.3 CLIENTE DEL SMD 75 B.4 MAPEADOR 75 B.4.1 MAPEADOR DE SONDAJES 75 B.4.2 MAPEADOR DE MAPAS 75
7
Figura 1: Hoja de mapeo clásica, utilizada hasta 2002.
1. INTRODUCCIÓN
Los geólogos tenemos varias misiones estratégicas para el negocio minero, dentro de las
cuales se pueden destacar:
• Buscar yacimientos, identificando blancos para exploración distrital y regional.
• Levantar la información básica relativa a las rocas, estructuras (fallas, fracturas, diaclasas y
vetillas), mineralización y otros temas relevantes para el yacimiento en explotación.
• Evaluar cuantitativa y cualitativamente los recursos presentes en el yacimiento.
• Emitir informes técnicos relativos a variadas materias relacionadas con la explotación
minera.
• Emitir informes técnicos relativos a materias relacionadas con el medio ambiente
(deslizamientos, acopios de material estéril y relaves, etc.).
Esta tesis tratará fundamentalmente de aplicar técnicas informáticas para proponer mejoras al
sistema de mapeo que apoya al área de geología de la División El Teniente de CODELCO
CHILE, denominado aquí Sistema de Mapeo Digital y abreviado SMD.
Al final de este documento se incluye un glosario de términos que puede ayudar al lector con
algunos conceptos específicos aquí mencionados.
La información geológica básica se obtiene del mapeo de
sondajes y mapas. Ésta consiste en datos geográficos
(puntos, polilíneas, polígonos y tramos de sondajes) a los
cuales se asocian datos relativos a distintos temas, a
saber: litología (tipos de roca), estructuras (fallas, vetillas,
fracturas, etc.), leyes (presencia de determinados
elementos de interés minero), mineralización (presencia
de minerales que en su composición contienen elementos
de interés, tanto favorables como perjudiciales para la
explotación minera) y otros temas que, según las
características propias del yacimiento, puede ser relevante
reconocer en terreno para su posterior análisis.
El proceso de levantamiento de esta información ha sido tradicionalmente manual, dibujando las
características reconocidas y anotando sus atributos en hojas de papel (figura 1). En el caso de
los mapas, parte del contenido de dichas hojas se traspasaba a un plano oficial, calcando a
8
Figura 2: Operación en terreno del SMD.
mano los rasgos reconocidos en terreno. La mayoría de los atributos observados pocas veces
eran traspasados a algún medio de almacenamiento electrónico que permitiera su análisis
conjunto. El traspaso sistemático de información a un medio de almacenamiento digital se hacía
sólo para la información obtenida a partir del mapeo de sondajes.
La información durante décadas, ha sido almacenada en forma parcializada de diversas formas:
papel (planos, hojas de mapeo, cartillas de mapeo de sondajes, etc.), planillas de cálculo,
archivos planos y, sólo algunos datos, en bases de datos relacionales. En consecuencia, no
existía un repositorio común para los datos geológicos reconocidos en terreno, siendo ellos de
tanta relevancia estratégica. Además, la aplicación de un estándar de mapeo se hacía
realmente difícil dada la carencia de una instancia de validación común para todos los datos
ingresados.
A fines del año 1999, en la División El Teniente, el autor comenzó a desarrollar en Visual Basic
6.0, un software muy simple que permitía almacenar los datos geológicos en forma digital.
Dicha iniciativa ha pasado por varias etapas, habiendo participado otros actores en el proceso
(Geovectra S.A. con el producto GVMapper) y llegando en la actualidad a ser el medio estándar
de levantamiento y almacenamiento de información geológica de la división.
1.1 Sistema de Mapeo Digital
El Sistema de Mapeo Digital (SMD) tiene por
objetivo facilitar el levantamiento de
información en terreno (figura 2), sobre la
base de un código de mapeo estándar
contenido en una base de datos central. Los
geólogos y profesionales afines pueden
acceder a la información almacenada para
verla y/o modificarla en forma ordenada y
administrada a través de perfiles de usuario.
Una descripción más detallada de los
distintos módulos que componen el SMD se
puede ver en el Anexo B de este documento.
9
Figura 3.1: Arquitectura física del SMD.
Figura 3.2: Arquitectura dinámica del SMD.
La arquitectura del sistema (figuras 3.1 y 3.2), consiste básicamente en un servidor de base de
datos, un servidor de aplicaciones y una serie de equipos portátiles y/o equipos de escritorio
con sistema operativo Windows 2000 o posterior.
10
Figura 4: Vista del mapeador de mapas del Sistema de Mapeo Digital.
Figura 5: Mapa del proceso de levantamiento de información geológica mediante un sistema digital.
1. REQUERIMIENTO DE INFORMACIÓN
2. BAJADA DEL PLANO A MAPEAR, AL EQUIPO PORTATIL
3. ARRIBO AL SECTOR Y PREPARACIÓN DEL TÚNEL
A MAPEAR
5. DE VUELTA EN LA OFICINA SE SUBE EL PLANO MODIFICADO, LO QUE ACTUALIZA AUTOMATICAMENTE LA BASE DE DATOS CENTRAL
6. SE PUEDEN OBTENER: REPORTES EN EXCEL O TEXTO, EXPORTACION A AUTOCAD, ANALISIS Y FILTROS DE LOS DATOS MAPEADOS, ETC.
4. SE INGRESA MANUALMENTE A UN EQUIPO PORTATIL, LA INFORMACION DE LOS ELEMENTOS A MAPEAR
La principal característica del SMD (que además lo diferencia del resto de los sistemas de
mapeo geológico existentes en el mercado), es su orientación a la creación de un código
estándar de mapeo que es distribuido a los clientes en forma automática. Dicho código es
creado por los geólogos administradores del SMD, a través de una aplicación de configuración.
De esta forma, cada aplicación cliente obtiene los datos de configuración del código central de
mapeo y genera en forma dinámica las interfaces necesarias para el ingreso de los datos de
cada tema, reemplazando a la hoja de mapeo tradicional por una digital (figura 4).
Durante el procedimiento de mapeo (figura 5), cada geólogo levanta la información en un
computador portátil, tipo hand held o tablet PC, en el cual corre la aplicación de mapeo.
11
Figura 6: Ficha de un corte transparente.
La generalidad de este enfoque hace que el sistema sea aplicable al resto de las áreas de la
minería que requieren del levantamiento de información en terreno (geotécnia, geomecánica,
etc.). De hecho, en el SMD existen actualmente temas tan especializados como la descripción
de cortes transparentes de roca (figura 6).
Al conectarse a la red, el sistema es capaz de sincronizar la base de datos central con las
modificaciones hechas durante la sesión de mapeo, quedando éstas a la vista de todos los
interesados en forma inmediata.
Todo este sistema ha sido desarrollado en Visual Basic 6.0 y, por lo tanto, está absolutamente
restringido a plataformas Windows por ahora.
El modelo de datos asociado a las características gráficas como los puntos, polilíneas y
polígonos adolece de falencias técnicas que no permiten una consulta óptima de dichos datos.
El éxito que ha tenido este sistema ha hecho que aumenten los interesados en utilizarlo, por lo
que se hace urgente una revisión de las herramientas y técnicas de desarrollo subyacentes, así
como del modelo de datos que permite almacenar la información.
12
El SMD está compuesto por diez aplicaciones, algunas de las cuales se describen brevemente
en la tabla 1.
Módulo Función
Mapeador de Mapas Permite al usuario ingresar información a un mapa (superficie, planta o sección).
Mapeador de Sondajes Permite al usuario ingresar información a un sondaje.
Cliente Está instalado en los equipos portátiles y/o de escritorio, permitiendo la conexión con el Módulo Servidor y el acceso, a través de él, a la información contenida en el sistema.
Permite al usuario obtener y editar la información de los elementos (mapas y sondajes).
Ingreso Canales y Sondajes
Está instalado en equipos de escritorio. Permite la creación de nuevos sondajes y canales mediante una interfaz especialmente diseñada para el efecto.
Importador de vectores Permite importar archivos vectoriales tales como dxf.
Importador de imágenes Permite importar y georreferenciar imágenes de diversos formatos (jpg, tiff, gif, etc.).
Servidor Escucha las solicitudes de los clientes. Autoriza usuarios según su perfil y da curso a sus solicitudes según corresponda.
Cuenta con conexión constante a la base de datos central.
Administra los Procesadores de Solicitud.
Procesadores de Solicitud
Procesan los requerimientos de usuarios como obtener y actualizar elementos. Cuentan con conexión a la base de datos central.
Exportador a AutoCAD Permite la exportación directa a formato dwg, mediante el uso de un ActiveX proporcionado por la versión AutoCAD 2002. Requiere de AutoCAD 2002 Full instalado.
Configurador
Es la interfaz de usuario para el administrador del Sistema de Mapeo Digital. Administra la base de datos del sistema permitiendo la creación de elementos y temas de mapeo, así como la administración de cuentas de usuario, perfiles, etc.
Tabla 1: Aplicaciones que componen el Sistema de Mapeo Digital.
13
Figura 8: Arquitectura actual del SMD.
Figura 7: Desarrollo histórico del SMD, a partir de GVMapper (Geovectra S.A.) y el Mapeador Estructural desarrollado en la Superintendencia Geología (SGL).
1.2 Historia del SMD
A continuación se hace una breve reseña histórica y técnica de lo que ha sido el desarrollo de
las distintas aplicaciones que llevaron al SMD que funciona en la actualidad (figura 7).
El año 2002 se libera la versión 3.1 de GVMapper. Dicho software fue el resultado de la
experiencia acumulada por Geovectra S.A. en su desarrollo del mapeador GVMapper versión
1.0, orientado a sondajes (Geovectra, 2003) y de la experiencia del autor en el desarrollo de
una aplicación de mapeo para túneles en la División El Teniente de CODELCO CHILE.
Este desarrollo se llevó a cabo entre los años 2000 y 2002, terminando con la liberación de la
versión 3.1 de GVMapper aquí mencionada. La arquitectura esquemática de este software se
muestra en la figura 8.
14
Figura 9: Arquitectura actual del SMD.
Tal como se aprecia en la figura 8, la arquitectura muestra un altísimo grado de acoplamiento
entre las distintas capas a nivel de modelo de datos, uso intensivo de Microsoft Access y el uso
de los campos BLOB para el almacenamiento de los vértices. Además, se distinguen problemas
serios de seguridad como el uso de carpetas compartidas para todos los usuarios, de tal forma
que puedan tener acceso a la base de datos central. El motivo de esto último es que la
aplicación cliente abre directamente la base de datos central Access ubicada en el servidor y,
mediante vinculación de tablas, procede a la sincronización de la base de datos central con los
nuevos elementos registrados en la base de datos local. De este modo, el sistema está
expuesto constantemente a la corrupción o pérdida de la base de datos central a manos de un
usuario descuidado o mal intencionado.
El autor desarrolló e implementó, a partir del año 2003, una organización en capas, donde la
lógica de mapeo reside en el cliente (en celeste), la lógica de sincronización con la base de
datos central lo hace en el servidor de aplicaciones (en verde), mientras que la base de datos
reside en un conjunto de servidores (en amarillo). En términos generales, la arquitectura actual
del SMD se resume gráficamente en la figura 9.
Sin embargo, existen aún tres temas transversales a las capas antes definidas, que las acoplan
y reducen en gran medida la escalabilidad y mantenibilidad del SMD. Estos temas son:
1. Modelo de Datos: El modelo diseñado es compartido por todas las capas, incluyendo la
base de datos local que usan las aplicaciones de mapeo. Esto se traduce en el hecho
que un cambio en el modelo de datos central origine efectos en casi todas las
aplicaciones aguas abajo.
15
Figura 10: Diagrama UML Nivel 0. Generalidades del SMD.
2. Microsoft Access '97: El uso de esta "base de datos" es intensivo, cumpliendo el rol de
repositorio de datos local, medio de transporte para la información entre cliente y
servidor de aplicaciones, y medio de conexión entre los datos mapeados y la base de
datos central, a través de la vinculación de tablas.
3. Uso de BLOB's para almacenar vértices: Para ser guardados y recuperados se
requiere la ejecución de un algoritmo específico que fue programado en C++ y
compilado como una dll que es llamada desde el código Visual Basic. Este ha sido uno
de los temas que más ha incidido en el hecho de no poder separar el modelo de datos
central y local, debido a que la transferencia de BLOB's es mucho más eficiente al tener
tablas vinculadas y hacer operaciones de inserción del tipo "INSERT INTO
TABLA_ORIGEN SELECT * FROM TABLA_DESTINO", para evitar tener que
descomprimir los vértices almacenados en cada campo BLOB.
De los puntos anteriormente mencionados, terminar con el uso de los BLOB's se considera
prioritario para flexibilizar al SMD y facilitar el logro de los objetivos de esta tesis.
1.3 Modelo Conceptual del SMD
Para esquematizar en forma general los actores y las funcionalidades relacionadas con el SMD,
a continuación se presentan algunos diagramas UML en tres distintos niveles aumentando la
profundidad del enfoque (figuras 10, 11 y 12).
16
Figura 11: Diagrama UML Nivel 1.
Figura 12: Diagrama UML Nivel 2.
Los diagramas antes mostrados sólo pretenden aclarar gráficamente los actores involucrados
en el SMD y sus relaciones fundamentales, así como enunciar los casos de uso más relevantes.
Para una descripción más detallada del SMD, se puede referir al Anexo B, donde se describen
las funcionalidades que este sistema provee.
17
1.4 Objetivo General
Mejorar el diseño, escalabilidad y eficiencia del Sistema de Mapeo Digital que opera en la
División El Teniente de CODELCO CHILE.
1.5 Objetivos Específicos
1. Realizar una revisión general del SMD y decidir los puntos críticos a abordar.
2. Diseñar modificaciones en el modelo de datos vigente, de tal forma de facilitar la realización
de consultas geográficas (e.g. por proximidad).
3. Diseñar modificaciones en el modelo de datos vigente de tal forma que las tablas de datos
sean legibles por otros sistemas o usuarios de la base de datos.
4. Revisar la continuidad de MS Access '97 como repositorio de datos local para el SMD.
5. Elegir un lenguaje de programación para reimplementar los distintos módulos del SMD.
6. Implementar los cambios de diseño básicos en el SMD que actualmente está en producción.
7. Diseñar un plan para la migración del SMD actualmente en producción (Visual Basic 6.0), a
la nueva plataforma de programación elegida.
8. Desarrollo de un pequeño prototipo en el lenguaje de programación elegido, con la interfaz
básica del mapeador de elementos 2D (mapas).
9. Identificar mejoras a futuro.
1.6 Aporte de esta tesis
El principal aporte de esta tesis será el de proveer a la Superintendencia Geología de la División
El Teniente, de la implementación de las modificaciones básicas al SMD, para poder llevar a
cabo una estrategia (propuesta en este documento) para obtener un software para
levantamiento geológico totalmente compatible con el sistema que actualmente está en uso,
pero escalable, siendo desarrollado en una plataforma más actualizada.
Además, los cambios en el modelo de datos permitirán hacer consultas geográficas en forma
eficiente en comparación con las herramientas actualmente en uso, facilitando además la
interoperabilidad del SMD con otros sistemas que se puedan conectar a su misma base de
datos.
En términos de escalabilidad y mantenibilidad, los cambios propuestos en esta tesis permitirán
aumentar la independencia entre el modelo de datos y la aplicación propiamente tal. De esta
18
forma, se posibilita un eventual cambio de software en cualquier capa (cliente o servicio) sin
necesidad de hacer cambios en los datos.
1.7 Limitaciones
1. La base de datos central es Oracle 9i por imposición estándar de CODELCO, por lo que no
se puede considerar un cambio en este SGDB. Además, no existe la posibilidad de agregar
componentes como un Motor Geométrico o similares dentro del presupuesto considerado
para este trabajo.
2. La base de datos central es administrada por la GCTIC (Gerencia Corporativa de
Tecnologías de la Información y Comunicaciones), por lo que se les debe consultar en caso
de requerir la creación de nuevos usuarios o la modificación de los permisos ya existentes.
3. El éxito del SMD se ha basado en los aportes de sus usuarios y el respeto a su opinión. Por
esto, cualquier cambio originado por los resultados de esta tesis debe ser puesto en práctica
procurando alterar lo menos posible el trabajo de los clientes actuales.
4. Actualmente, el SMD cuenta en la práctica con sólo un diseñador y programador (el autor).
Todas las decisiones y recomendaciones que se informen en esta tesis deben tener esto en
consideración.
1.8 Metodología
El SMD al interior de la Superintendencia Geología ha sido desarrollado mediante una
estrategia de desarrollo "poco convencional", sin equipo de diseño, desarrollo y pruebas bien
definidos. El diseño y desarrollo han estado a cargo del autor, mientras que las pruebas en
general son realizadas por los usuarios más experimentados. Dado que hasta el momento esta
estrategia ha sido exitosa, la misma se aplicará para el desarrollo de esta tesis.
Para llevar a cabo este trabajo de forma ordenada, se procederá a una revisión de la estructura
de datos actual, de tal forma de aportar mayor flexibilidad para el desarrollo de herramientas de
análisis, así como para las funcionalidades propias del SMD (estilos de despliegue,
sincronización de datos entre clientes y servidor, etc.). Se procurará dar mayor claridad a la
información contenida en la base de datos y a los nombres de tablas y campos, la que
actualmente aparece bastante críptica para cualquier persona o aplicación externa que visualice
las tablas. Este cambio aumentará la posibilidad de conectar otros softwares a la misma base
de datos, aumentando la interoperabilidad del sistema y la posibilidad de compartir la
información almacenada.
19
Sobre la base de la nueva estructura de datos, se harán las modificaciones necesarias en el
SMD actualmente en funcionamiento para adaptarlo a la misma. Esto implica desarrollo y
mantenimiento de código en Visual Basic 6.0. Si bien esta plataforma de desarrollo está
descontinuada, ya existe una experiencia exitosa de desarrollo, pruebas y puesta en producción
en el lenguaje Visual Basic 6.0. Por esto, se considera conveniente aproximar, en términos de
estructura de datos y herramientas básicas, al SMD actual con el que será desarrollado en el
futuro próximo, de tal forma de propiciar una migración gradual y poco "traumática" para los
usuarios del sistema actual.
En forma paralela al desarrollo y mantenimiento del SMD, se considera la elección de la
plataforma de desarrollo más adecuada, teniendo en consideración las condiciones de
desarrollo y recursos disponibles actualmente. Para probar la efectividad de la plataforma de
desarrollo elegida, se considera la programación de un pequeño prototipo de la aplicación de
mapeo de elementos 2D (mapas). Las funcionalidades a reproducir se detallan en la sección
correspondiente.
Para llevar a cabo todas las modificaciones propuestas en esta tesis, será necesario hacer
mantenimiento a prácticamente todos los módulos ejecutables del SMD.
20
2. ESTADO DEL ARTE EN EL MERCADO
En los últimos cinco años se han desarrollado varias aplicaciones orientadas a la visualización,
mapeo y análisis de información relativa a las "geociencias", especialmente a la geología. A
continuación se hace una breve descripción de algunos sistemas de mapeo geológico que se
encuentran actualmente en el mercado. Es necesario enfatizar que, desde la perspectiva del
negocio, sólo GVMapper 3.3 (Geovectra, 2006) tiene una funcionalidad comparable a la del
SMD.
2.1 Encom Discover 6.1
Está orientado a los usuarios de MapInfo (software para manejo de información geográfica
conocido a nivel mundial). Permite el mapeo, visualización y análisis de datos espaciales
orientados a las geociencias. Posee características como control y agrupamiento de capas,
herramientas de edición de objetos, leyendas y simbología estándar para creación de mapas.
Presenta además una amplia gama de herramientas de graficación y análisis de datos, así
como la posibilidad de desplegar sondajes. Posee un módulo 3D opcional (Encom, 2006).
2.2 GeoRover
Es una aplicación orientada específicamente a geólogos, incluyendo conexión para GPS,
visualización de imágenes y compatibilidad con PDA's (Windows CE). Su base de datos
consiste en un archivo ASCII (.dbf), teniendo además posibilidad de utilizar ODBC para
conectarse a bases de datos que soporten este protocolo (GAF, 2006).
2.3 Oasis Montaj
Es una herramienta de análisis y mapeo de información asociada a la exploración de minerales,
petróleo y gas. También posee extensiones para proceso de información geofísica y
geoquímica. Tiene una base de datos capaz de almacenar más de dos billones de puntos de
información por canal. Sobre esta información se pueden ejecutar filtros y procesos. Maneja la
proyección de los puntos en más de 2000 datums y proyecciones. Permite también
visualización en tres dimensiones para múltiples superficies, cada una con sus propios
contenidos (Geosoft, 2006).
21
2.4 ArcInfo
Incluye las funcionalidades de ArcView y ArcEditor (dos aplicaciones de la misma empresa).
Está orientado al almacenamiento de datos, su análisis y modelamiento, además del despliegue
de mapas. En cuanto al manejo de los datos, ArcInfo permite crear bases de datos, definir su
esquema y administrar su integridad (Esri, 2006).
Las diferencias entre las aplicaciones antes descritas y el SMD, se basan en que este último es
un sistema que distribuye e implementa un código de mapeo estándar en todos los equipos que
se conectan con una aplicación cliente al servidor del sistema. Además, implementa el manejo
de usuarios y perfiles lo que significa un gran aporte al negocio desde el punto de vista
administrativo.
Los softwares revisados hasta aquí poseen siempre un repositorio de datos local como única
fuente de información o, a lo sumo, la capacidad de conectarse vía ODBC a un repositorio
externo. Sin embargo, esto no garantiza la seguridad de los datos, la estandarización de la
información y, sobre todo, no se ocupan de la administración de las transacciones hechas por
los usuarios.
Por lo antes expuesto, se considera que el SMD satisface las necesidades de la
Superintendencia Geología en forma mucho más cercana a su realidad que los softwares hasta
aquí revisados.
2.5 GVMapper
El único software comercial que se considera comparable al SMD, es la versión 3.3 de
GVMapper (Geovectra S.A., 2006). Tal como se mencionó en la introducción, el autor fue uno
de los dos programadores de GVMapper versión 3.1. El desarrollo encaminado hacia el SMD se
separó de este software a partir del año 2003 debido a falencias de seguridad y escalabilidad,
entre otras, de las que adolecía GVMapper en ese momento.
Según la empresa que lo desarrolla, GVMapper es una suite de aplicaciones de software para
la captura y administración de información geológica. Su utilidad está en la captura de
información geológica en terreno (exploración, bancos, túneles) y mapeo de sondajes.
Su interfaz se describe como ergonómica para su utilización con pen tablets. Además, ofrece
herramientas para la importación de información histórica, herramientas de cálculo incorporadas
y capacidad de exportar datos a los formatos de los sistemas de información geográfica (SIG) y
aplicaciones de modelamiento 3D, de mayor presencia en el mercado.
22
Figura 13: Arquitectura de GVMapper-GVServer.
Hasta la fecha, GVMapper conserva las siguientes características de la versión 3.1 en la cual se
separó el desarrollo hacia el SMD:
• Las bases de datos central y local están construidas con archivos Access.
• La base de datos central se accede mediante una carpeta compartida en el servidor.
• Es GVMapper (instalado en el cliente), quien realiza las transacciones con la base de
datos.
En este sentido, GVMapper como tal, sigue contando con las mismas falencias a las que se
debió el inicio del desarrollo del SMD por el autor. Sin embargo, Geovectra ha desarrollado el
módulo GVServer (figura 13), el cual funciona como un servicio en un servidor.
GVServer está encargado de:
• Administrar las bases de datos de GVMapper.
• Realizar todas las transacciones de datos entre la base de datos central y los
mapeadores o clientes.
• Incorporar niveles de seguridad y de acceso a los datos.
• Permitir la integración entre distintos sistemas.
• Permitir la interconexión entre la base de datos de GVMapper con otras bases de datos
y aplicaciones mineras.
De este modo, el sistema de mapeo ofrecido por Geovectra distribuye los distintos módulos en
capas.
23
Con el uso de GVServer se ofrecen una serie de ventajas, entre las cuales se mencionan las
siguientes:
• GVMapper puede interactuar simultáneamente con varios GVServer dentro de una
misma red corporativa.
• Todos los clientes GVMapper de una red corporativa pueden obtener sus elementos de
apoyo de una única base de datos geoespacial.
• GVServer funciona con un esquema de licencias orientado al equipo.
El módulo GVServer está programado en C, lo que lo hace muy interesante desde el punto de
vista de su eventual portabilidad a sistemas operativos como Linux o similares. Sin embargo,
hace uso de algunas API de Windows que evitan su portabilidad inmediata, por lo que esta
posibilidad podría ser evaluada y encomendada como un proyecto a la empresa desarrolladora.
La compatibilidad con varios SGDB como SQL Server y Oracle resulta muy deseable en caso
de un eventual cambio de gestor de base de datos en la Corporación. Sin embargo, GVServer
sólo ha sido utilizado con Access y SQL Server hasta el momento.
La base de datos tanto local como central, aún almacena los vértices en campos de tipo BLOB,
lo que constituye una limitación bastante importante desde el punto de vista de la normalización
del esquema de datos, así como de la legibilidad de los mismos usando SQL estándar. Este
tema es desarrollado en profundidad en esta tesis.
Para lograr una estructura de datos similar a la que se tiene actualmente, habría que generar
una base de datos paralela, la cual sea actualizada desde los daemons que ofrece Geovectra.
Esto significaría, entre otros puntos:
• Redundancia de la información
• Alta dependencia de la fiabilidad de los procesos de actualización
• Aumento de la carga de procesos en el servidor de aplicaciones
En resumen, GVMapper sin el módulo adicional GVServer es muy inferior, desde el punto de
vista de la seguridad de los datos y estabilidad del servicio, a lo que proporciona actualmente el
SMD. La eventual adición del módulo GVServer resulta una mejora importante y digna de ser
evaluada, sin embargo, será necesario para su implementación el desarrollo de varios cambios
a nivel de la estructura de datos para que la información sea legible. Además, GVServer sólo ha
sido utilizado a partir de julio de 2006, por lo que tiene muy poco tiempo de uso y depuración,
en comparación con los tres años que tiene el SMD usando Oracle. Esto último constituye un
riesgo adicional.
24
3. ANÁLISIS Y MODIFICACIONES AL MODELO DE DATOS
La base de datos central del SMD es administrada con Oracle 9i. El mismo está instalado en un
conjunto de servidores administrado por la GCTIC de CODELCO CHILE. El autor, como
desarrollador y usuario de esta base de datos, tiene privilegios para crear, consultar, eliminar y
alterar tablas. El módulo Servidor, los módulos Procesadores de Solicitudes y el Configurador
se conectan a la base de datos central con el mismo usuario de Oracle.
La estructura actual de la base de datos adolece de varios problemas en términos de eficiencia
y normalización. Además, muchos de los campos no tienen bien definido su tamaño (e.g.
Varchar2, Number), por lo que generalmente ocupan mucho más espacio del que requieren en
realidad. Muchas tablas cuentan con un campo denominado ID, el cual en algunos casos no es
utilizado. Dicho campo es usualmente autonumérico, lo que implica la existencia de una
secuencia y un trigger para llevar a cabo el autoincremento de su valor cada vez que se agrega
un registro. En caso de no ser utilizado el campo ID, esta tesis contempla su eliminación de la
tabla correspondiente, así como la eliminación de la secuencia y el trigger asociados. Estos
defectos son comunes a muchas tablas, por lo que sin ser mencionados en cada caso, serán
abordados para todas ellas.
Los cambios en la base de datos fueron hechos mediante la ejecución directa de sentencias
SQL a través de la aplicación PL/SQL para el caso de los cambios en las tablas de meta datos.
En el caso de las tablas de datos, los cambios de estructura y la migración de datos se hizo
mediante la programación de funciones en Visual Basic 6.0. Para probar el funcionamiento de
dichas aplicaciones, se copió todo el contenido de la base de datos oficial en una base de datos
de desarrollo. Sobre esta última se ejecutaron todos los cambios en forma previa, verificando
que no se produjeran errores durante la ejecución, los cuales, en caso de ocurrir, eran
almacenados en un archivo de texto (.log). Una vez que se logró la ejecución de todas las
funciones de cambio de estructura y migración de datos sin errores en la base de datos de
desarrollo, se procedió a respaldar la base de datos oficial (de producción) y a ejecutar dichas
funciones sobre la misma.
En esta sección se explicarán los rasgos fundamentales del modelo inicial de la base de datos
del SMD en términos de la utilidad que presenta cada tabla para el mismo. Para un mejor
entendimiento del modelo de datos, se explicarán las tablas según el contexto al que
pertenecen: soportes de información, temas de mapeo, administración de usuarios. En cada
contexto, luego de explicar brevemente cada tabla, se indicará cuando corresponda, la
modificación realizada en esta tesis y los motivos que la justifican. Algunas tablas de menor
relevancia, no serán mencionadas en este documento.
25
Figura 14: Diagrama E-R de los datos del SMD.
3.1 Modelo Entidad-Relación
Para explicar en forma general las principales entidades involucradas en el modelo de datos del
SMD, se utilizarán dos diagramas entidad-relación. El primero de ellos (figura 14) muestra las
entidades que contienen la información del negocio, tales como usuarios del sistema, soportes
mapeados, datos asociados a los soportes, etc.
En la figura 14 se puede ver que la entidad central en el SMD es el soporte, que es cualquier
ubicación en el espacio (punto, polilínea, polígono o tramo de sondaje), al cual un usuario del
SMD le ha asignado información en alguno de los temas configurados. Al soporte se le asocia
entonces información en cuanto a datos temáticos, por ejemplo litología y, en caso que
corresponda, se le puede asociar también información espacial extra, tal como lo es una
observación de rumbo y manteo (disposición de un plano en el espacio).
Un soporte, a su vez, pertenece a un usuario quien posee uno o varios perfiles en el SMD.
Dichos perfiles describen las características y autorizaciones que posee el usuario. Cada
soporte es creado sobre un elemento mapeable, por ejemplo un mapa o un sondaje. Los
elementos mapeables tienen también perfiles asociados, los que permiten definir los temas que
pueden ser levantados en cada uno de ellos.
El segundo diagrama (figura 15) muestra los meta datos contenidos en la base de datos del
SMD. Esta información consiste en la definición de los temas que pueden ser mapeados por los
26
Figura 15: Diagrama E-R de los meta datos del SMD.
usuarios del SMD, los atributos que los componen, los valores que dichos atributos pueden
asumir (dominios) y las reglas de validación que se deben verificar al momento del mapeo de
cada uno de los temas.
Dentro de las funcionalidades del SMD está la posibilidad de vincular unos temas con otros, por
ejemplo el tema Litología que describe en términos generales la roca observada, con el tema
Descripción de Fenocristales, que contiene una descripción detallada de los cristales que
componen una roca porfídica. A su vez, es posible vincular los atributos dentro de un tema para
permitir, por ejemplo, que cuando seleccionamos un grupo de rocas, tal como las rocas
intrusivas, se nos ofrezcan tipos de rocas coherentes con dicha elección, es decir, granito,
granodiorita, etc. En el caso de atributos de uso común en más de un tema, como podría ser el
color, para evitar tener que digitar en la configuración de cada tema que contiene este campo
todos los colores autorizados, se cuenta con una entidad independiente denominada campo la
cual es referenciada por el atributo del tema. Así, un cambio en la entidad campo se verá
reflejada en todos los atributos de los temas que "apunten hacia él". Esto facilita la
mantenibilidad del código de mapeo y agiliza mucho el proceso de configuración de los temas.
27
Figura 16: Tabla GSYSSOPORTES original.
3.2 Soportes de Información
Recordemos que el SMD permite configurar un número indefinido de temas de mapeo, los que
pueden ser reconocidos en sondajes o en mapas.
Tabla GSYSSOPORTES: Tal como se explicó en la
introducción, este sistema provee la capacidad de
almacenar información recopilada en terreno. Por ejemplo,
en el tema Litología, un área determinada puede ser
calificada como un Granito en el campo Tipo. Está área
podría ser un punto, una polilínea, un polígono o un tramo
de un sondaje.
Todas las áreas (o porciones del espacio) caracterizadas
en el SMD son denominadas soportes y son almacenadas
en una única tabla denominada GSYSSOPORTES (figura
16). Cada soporte está identificado en forma única en el
SMD por el campo IDSOPORTE, que es autonumérico.
Un soporte, en el caso de los mapas, está conformado por
una sucesión ordenada de vértices, los cuales son
almacenados en campos de tipo BLOB (Binary Large
Object) denominados VERTICES y EXTRADATA. Para
almacenar y obtener los vértices es necesario ejecutar
ciertos algoritmos específicos, lo que los hace lentos de
obtener y sumamente complejos de consultar. En el caso de los sondajes, los soportes
corresponden a tramos caracterizados por los campos DESDE y HASTA (numéricos), por lo
que carecen de información en los campos de tipo BLOB antes mencionados. El hecho que los
campos VERTICES, EXTRADATA, DESDE y HASTA coexistan en la misma tabla implica un
desperdicio de espacio considerable. Esto es más grave aún teniendo en cuenta que esta tabla
tiene más de 950.000 registros en la actualidad.
A partir de lo expuesto anteriormente, como primera medida se elimina la característica auto
numérica del campo IDSOPORTE. Dicho campo pasará además a ser de tipo texto, con una
longitud de 25 caracteres. El valor del identificador de cada nuevo soporte (IDSOPORTE), será
construido en forma local como la concatenación de los datos: IDUSUARIO-IDPROCESO-
CORRELATIVO_DE_LA_SESION. El valor IDPROCESO es único en el SMD y es asignado
cada vez que se baja información. Cada equipo maneja localmente un correlativo de los
soportes generados en cada sesión. El IDUSUARIO es un número único para cada usuario,
28
Figura 17: Nueva estructura para el almacenamiento de soportes.
manejado internamente por el SMD. Todo esto garantiza la unicidad del IDSOPORTE al
momento de su asignación durante el mapeo.
Se decide separar la tabla GSYSSOPORTES en tres tablas denominadas: GSYSSOPORTES,
TTEVERTICES y TTETRAMOS, cuyas estructuras se muestran en la figura 17. Esto nos
permitirá obtener dos ventajas fundamentales:
1. Se evita el desperdicio de espacio producto del almacenamiento conjunto de los
soportes de sondajes y mapas.
2. Se almacenan los datos de vértices en un formato accesible directamente (sin necesidad
de procesos externos al SGDB). Esto permite realizar consultas directas sobre la base
de datos y obtener resultados en un tiempo mucho menor, utilizando SQL estándar.
Adicionalmente, se eliminarán campos calculados (o derivados) a partir de otros como lo era el
campo denominado SOPORTE, calculado a partir de la resta: (HASTA - DESDE).
En el caso de la tabla TTEVERTICES, se ha optado por dejar como clave principal a los
campos IDSOPORTE y ORDEN. El orden representa justamente la secuencia correcta de los
vértices de cada soporte. La posibilidad de generar una tabla de vértices que fueran únicos (con
coordenadas irrepetibles) y una tabla de nexos entre soportes y vértices se descartó ya que
haciendo una prueba se observó que el ahorro de espacio no superaba el 2%, mientras que la
merma en rendimiento era bastante relevante, especialmente en lo que se refiere a la inserción
de soportes en la base de datos.
29
Figura 18: Tablas originales para almacenamiento de metadatos de temas configurados en el SMD.
3.3 Temas y Reglas de Mapeo
Un tema de mapeo es un tópico técnico acerca del cual queremos recopilar información. En el
SMD todos los temas son genéricos, ya que se deben adaptar a tópicos muy diversos. Por
ejemplo, un tema genérico puede ser el Estado de los Túneles en una mina subterránea. Para
lograr el funcionamiento de los teas genéricos, existe un conjunto de tablas de meta datos,
algunas de las cuales son descritas a continuación.
Tabla GSYSTABLAS: Los registros de esta tabla corresponden a cada uno de los temas
definidos en el SMD (figura 18). Esta tabla posee como clave principal un identificador numérico
autoincrementable (con el uso de una secuencia y un trigger) denominado ID. Además, el
campo Nombre, es una clave única. Para dar más flexibilidad al SMD, es posible vincular unos
temas con otros. Así, por ejemplo, el tema Estado de los Túneles podría tener vinculado un
tema específico para descripción de la filtración de agua, que incluyera una medición de pH,
caudal, ubicación, etc. Para hacer efectiva esta vinculación, desde el punto de vista de la base
30
de datos, la tabla GSYSTABLAS cuenta con el campo Vinculado, el cual es cero en caso de no
ser un tema vinculado y, en caso contrario, contiene el ID del tema al cual se vincula.
Para la denominación de cada tabla asociada a cada uno de los temas definidos (registros de
GSYSTABLAS), se concatena la cadena "DATGTABLA" con el identificador numérico (ID) que
le haya correspondido. Así, por ejemplo, el tema Estado de la Fortificación puede tener un ID =
21. Por lo tanto, la tabla con la información asociada a este tema se denominará
DATGTABLA21.
Con el fin de mejorar la legibilidad del modelo de datos, la denominación de las tablas
asociadas a cada tema será reemplazada por la concatenación de la cadena "D_" con el
nombre real del tema, procesado de tal forma que todos sus caracteres estén en mayúscula,
que comience con una letra y que no posea espacios o caracteres especiales. De esta forma, la
tabla asociada al tema Estado de los Túneles, se denominará
D_ESTADO_DE_LOS_TUNELES. Se asignará un máximo de 28 caracteres al nombre de los
temas, de tal forma de cumplir con la restricción de largo de nombre de tablas de Oracle 9i, que
parece ser uno de los más restrictivos en este aspecto (SQL Server 2000 admite hasta 128
caracteres).
Tabla GSYSNEXOTABCAM: Al mapear cada tema debemos asignar valores a distintos rasgos,
denominados campos. En el ejemplo Estado de los Túneles, los campos podrían ser Estado de
la fortificación, Escurrimiento de agua, Levantamiento del piso, Distancia al frente, Fecha. Esta
tabla (figura 18) contiene los vínculos entre cada tema y sus campos, especificando eventuales
reglas de validación específicas, orden de aparición, estilo para su despliegue en sondajes y
mapas, etc. A cada campo le es asignado un identificador, ID, que en adelante denominaremos
IDNEXO. De esta forma, los campos de las tablas de información se denominan concatenando
la cadena "CAMPO" con el IDNEXO asociado al campo en la tabla GSYSNEXOTABCAM. El
nombre del campo se guarda en la tabla GSYSNOMBRES y el ID asignado en dicha tabla es
guardado en el campo IDNOMBRE de la tabla GSYSNEXOTABCAM. Por esto, para obtener el
nombre real del campo, es necesario consultar la tabla GSYSNOMBRES.
Además, es posible vincular campos de la misma o de distintas tablas de tal forma de ingresar
sólo una vez los atributos que se le deben asignar. Por ejemplo, si el Estado de la Fortificación
está presente en más de un tema, basta con vincular ambos campos y así ingresar sólo en uno
de los temas valores tales como bueno, regular o malo. Esto evita el tedioso ingreso de los
distintos atributos y conserva la integridad entre conceptos relacionados.
Cada campo puede ser caracterizado con un tipo de dato específico, según su forma de
medición u observación. En el caso del Estado de la fortificación, el campo sólo debería ser
31
Figura 19: Tablas para almacenamiento de perfiles y metadatos de temas.
descrito con uno de los tres valores definidos y no con otros creados por el usuario. Para esto el
sistema considera un tipo de dato denominado Texto Fijo en el SMD. Para este tipo de dato es
necesario, al momento de la creación o edición del tema, generar una lista de valores
aceptables para cada campo de este tipo. De este modo, el SMD ofrecerá en forma automática
sólo esta lista, evitando el ingreso de datos inconsistentes con el estándar de mapeo definido.
En esta tabla se almacena el "estilo" (color, abreviatura, histograma, etc.) con el que se debe
desplegar cada campo, tanto en el mapeador de mapas como en el de sondajes.
Una vez más, para contribuir a la legibilidad de la estructura de datos, se propone agregar los
campos: NOMBRE y NOMBRE_COLUMNA ambos de tipo VarChar(30). El campo NOMBRE
almacenará el nombre real asignado por el usuario al campo, prescindiendo del uso de la tabla
GSYSNOMBRES para tal efecto. En tanto, el campo NOMBRE_COLUMNA almacenará el
nombre de la columna asignada a este campo en la tabla de información asociada al tema al
que pertenece (figura 19). El nombre de la columna será obtenido procesando el nombre real
del campo en forma análoga a lo que se hará con el nombre de las tablas asociadas a los
temas de mapeo. De esta forma, lo que antes era: DATGTABLA21: CAMPO233
...ahora será: D_ESTADO_DE_LOS_TUNELES: ESTADO_DE_LA_FORTIFICACION
Esto facilitará la interoperabilidad de la base de datos del SMD con otros usuarios de la misma y
con eventuales aplicaciones cliente que en el futuro se conecten a esta base de datos.
32
Figura 20: Tabla GSYSNOMBRES.
Figura 21: Tabla GSYSNEXOATT.
Figura 22: Tabla GSYSRELNEXOS.
Figura 23: Tabla GSYSNEXOATAT.
Tabla GSYSNOMBRES: Los distintos atributos que
caracterizan a cada campo de tipo texto fijo son
almacenados en esta tabla (figura 20). El campo ID
contiene un identificador numérico único de cada
nombre del sistema, mientras que el nombre
propiamente tal, es almacenado en el campo
denominado NOMBRE. En esta tesis se harán los
cambios necesarios para prescindir de esta tabla.
Tabla GSYSNEXOATT: Almacena los vínculos entre los
campos de tipo texto fijo del sistema y los atributos
que les pueden ser asignados (figura 21). Además,
posee el campo ENABLED que permite deshabilitar o
descontinuar algún atributo si ya no es necesario o no
aplica en el campo en cuestión. El estilo particular de
cada atributo es indicado en esta tabla. Se propone
almacenar directamente el nombre de los valores en
lugar del ID asignado en la tabla GSYSNOMBRES.
Tabla GSYSRELTABLAS: Mediante cada registro de
esta tabla se le indica al SMD que dos temas están
relacionados al momento de su mapeo, siendo
posible condicionar dicha relación mediante el valor
que asuma un campo de la tabla "padre" (figura 19). En el ejemplo de Estado de la Fortificación,
el campo Escurrimiento de Agua podría condicionar la relación con un tema denominado Agua,
que tuviera campos como pH, color, etc.
Tabla GSYSRELNEXOS: Así como es posible relacionar dos temas,
es posible hacer lo mismo con dos campos de tipo texto fijo del mismo
tema. Para esto cada registro de esta tabla indica la relación entre dos
campos de un tema mediante su IDNEXO, explicado anteriormente
(figura 22).
Tabla GSYSNEXOATAT: Cuando dos campos de tipo texto fijo están
relacionados, los valores que el hijo puede asumir son función del
valor que haya asumido el padre. Dichas relaciones se especifican
mediante esta tabla (figura 23). De este modo, si tenemos un campo
33
Figura 25: Ejemplo del cambio en la metodología de almacenamiento de datos genéricos. Tema de Litología: ex tabla DATGTABLA51, actual tabla D_LITOLOGIA.
Figura 24: Esquema para almacenamiento de soportes y datos asociados. Modelo original.
denominado PAÍS y otro denominado CIUDAD, esta tabla permite generar las relaciones
existentes entre los países y las ciudades que les pertenecen.
3.4 Información de Mapeo
Tablas DATGTABLAn: Estas son las tablas que almacenan la información de los temas del
SMD. Su nombre es estándar y consiste en "DATGTABLA" seguido por el ID que se le asigna
en el campo homónimo de la tabla GSYSTABLAS, tal como se indicó anteriormente. Cada una
de estas tablas es generada con un campo denominado IDSOPORTE, vinculado a un soporte
registrado en la tabla GSYSSOPORTES. El resto de la columnas tienen nombres codificados
como "CAMPO" seguidos de un identificador numérico dado por el campo ID asignado en la
tabla GSYSNEXOTABCAM (IDNEXO). Esta forma de codificar los nombres de tablas y campos
le dan gran flexibilidad al sistema en términos de poder modificar el nombre "conceptual" de los
mismos, sin afectar su nombre real dentro de la base de datos. Además, se imponen muchas
menos restricciones con respecto a los nombres que pueden adoptar temas y campos, los
cuales se ven muy restringidos en los SGDB. Para los campos de tipo texto fijo descritos
anteriormente, se almacena el ID asignado en la tabla GSYSNOMBRES, en lugar del valor
mapeado literalmente. El modelo original se aprecia en la figura 24.
Gran parte de lo descrito en el párrafo anterior se cambiará como parte de esta tesis, ya que
hace demasiado ilegible la información de la base de datos en caso que se desee cambiar el
34
Figura 25: Ejemplo del cambio en la forma de almacenamiento de datos genéricos. Tema: Litología, ex tabla DATGTABLA51, actual tabla D_LITOLOGIA.
software que la lee o maneja y, además, hace que la información contenida en las tablas de
información sea muy dependiente de cualquier error en la tabla GSYSNOMBRES, lo que es un
riesgo no deseado. Por lo tanto, los campos de texto fijo serán llenados con la información literal
mapeada. De esta forma, la tabla GSYSNOMBRES podrá ser eliminada del sistema con el
consiguiente ahorro de espacio, administración y código fuente. Tal como se dijo al describir la
tabla GSYSTABLAS, la denominación de las tablas temáticas ("DATGTABLAn") será cambiada
por una mucho más entendible por un usuario común. Lo mismo se hará con la denominación
de los campos. Así se llega a una estructura como la mostrada en la figura 25.
Tablas DATSTABLAn: Estas tablas son exclusivas para la información externa (como análisis
de laboratorio) relativa a los sondajes. Por esto en lugar de contar con un campo IDSOPORTE,
tienen los campos: IDSONDAJE, DESDE, HASTA como clave principal (ver tabla
DATSTABLA71 en figura 24). Para estas tablas existen importadores de datos externos
especialmente diseñados.
Sin embargo, en esta tesis se considera necesario eliminar estas tablas y dejar su información
en temas genéricos. Se considera el desarrollo de un módulo de importación de datos que sea
capaz de ajustarse a la configuración de cualquier tema. Esto le dará mucha más
interoperabilidad al SMD, siendo posible importar datos desde otras fuentes, fijando
previamente un formato adecuado. El módulo de importación debe considerar la validación de
las reglas impuestas durante la configuración de cada tema. Para la migración de los datos
35
Figura 26: Tabla GSYSGRUPOSSOP.
desde las tablas "DATSTABLA" a sus equivalentes genéricas, fue necesario programar una
pequeña aplicación que generó los registros necesarios en la tabla GSYSSOPORTES,
obteniendo un IDSOPORTE y luego alimentó los registros definitivos en la tabla del tema en
cuestión.
Tabla DATESTR: Esta tabla contiene información relativa al único tema no configurable del
sistema: Estructuras. Dicho tema fue codificado directamente debido a que en sus inicios los
temas genéricos no tenían la capacidad para satisfacer los requerimientos de este concepto
geológico. Sin embargo, actualmente los temas genéricos ya pueden almacenar información
estructural. Por esto se considera la eliminación de esta tabla y el almacenamiento de su
información en un tema configurado especialmente para este efecto. Esto no fue abordado en
esta tesis.
Tabla DATCOMPONENTES: Esta tabla (figura 24) está relacionada con DATESTR y su
objetivo es almacenar la información del relleno de cada estructura. Una vez reemplazada la
tabla DATESTR, esta tabla también será reemplazada por un tema genérico equivalente,
vinculado al nuevo tema de "Estructuras".
El reemplazo de las tablas DATESTR y DATCOMPONENTES, será relativamente simple ya
que la codificación de sus campos responde al mismo concepto que los temas genéricos.
Tabla GSYSGRUPOSSOP: En el caso de los soportes
mapeados en plantas y secciones, éstos pueden ser
agrupados con el objetivo de hacer análisis conjuntos de
características similares reconocidas en distintos sectores.
Un ejemplo de esto puede ser una falla que es observada
en tres túneles distintos. Bajo ciertas circunstancias, se
podría concluir que las tres observaciones corresponden a
la misma falla, por lo que resulta de importancia tener la posibilidad de agrupar estos soportes
sin que pierdan la individualidad en su reconocimiento. Este es el papel que juega la tabla
GSYSGRUPOSSOP (figura 26). Esta tabla permite, adicionalmente, ingresar una descripción
de cada grupo de soportes.
36
Figura 27: Esquema para almacenamiento de soportes y datos asociados. Modelo propuesto.
Al realizar los cambios mencionados en los párrafos anteriores, se llega al modelo propuesto en
la figura 27.
La tabla DATRUMBOS, cumple la función de almacenar la información relativa a la orientación
espacial de los soportes planares (e.g. un plano estructural como una falla), reconocidos en el
sistema. A dichos soportes se les suele asociar una medición de rumbo (ángulo con respecto al
Norte) y manteo (inclinación con respecto a la horizontal). Los campos DIP y DIPDIR cumplen la
función de almacenar los datos de rumbo y manteo en un formato alternativo que no viene al
caso explicar en este documento.
Las leyes de los distintos elementos de interés, como Cu (cobre) y Mo (molibdeno), son
almacenadas en el tema LeyesCuMo, cuya información es almacenada, según el nuevo
formato, en la tabla D_LEYESCUMO.
Desde luego hay muchas otras tablas genéricas (tipo D_xxxx), pero todas comparten el mismo
esquema de relación con GSYSSOPORTES por lo que no tiene sentido mostrar el modelo de
datos completo.
37
Figura 28: Tabla DATSSONDAJES original.
Figura 29: Tabla DATSMAPAS original.
3.5 Tablas de Elementos Mapeables
En este documento se entiende por elemento mapeable a toda entidad espacial de una
dimensión o dos dimensiones, a la cual se le pueden asignar valores en los distintos temas
configurados en el sistema. El sistema en la actualidad cuenta con los siguientes tipos de
elementos mapeables preconfigurados: Sondajes (una dimensión), Plantas (planos horizontales
de dos dimensiones), Secciones (planos verticales de dos dimensiones) y Superficie (mapas de
dos dimensiones no necesariamente planos). Para
almacenar información de cada unos de estos tipos de
elementos, se cuenta con dos tablas en el sistema, las
cuales son descritas a continuación.
Tabla DATSSONDAJES: Esta tabla almacena los
sondajes configurados en el sistema (figura 28). La
información espacial de cada sondaje es actualmente
almacenada en los campos de tipo BLOB: VERTICES y
EXTRADATA, en forma análoga a lo que se hace en la
tabla GSYSSOPORTES. Por esto, en esta tesis se
reemplazó este método de almacenamiento por un
almacenamiento vía GSYSSOPORTES y TTEVERTICES,
de la misma forma que se hace con todos los soportes del
sistema, utilizando como IDSOPORTE el identificador del
sondaje (IDSONDAJE). De esta forma, esta tabla deberá
contener un campo IDSOPORTE en lugar de
IDSONDAJE, tendiendo a convertir la tabla
DATSSONDAJES en un tema genérico más, con algún
atributo especial (tipo de tema) que indique que se trata
de una tabla de elementos mapeables de una dimensión.
Esto además hará que las características atribuibles a los
elementos mapeables sean flexibles y configurables por
los administradores del sistema, sin necesidad de cambiar
código fuente como ocurre actualmente.
Tabla DATSMAPAS: Esta tabla almacena los mapas
configurados en el sistema: plantas, secciones y superficie
(figura 29). Hasta el momento los mapas han sido
restringidos a ser planos rectangulares. Por esto, su información espacial se almacena dentro
38
Figura 31: Tabla DATSTRAYECTORIAS original.
Figura 30: Tablas DATSSONDAJES y DATSMAPAS, modelo desarrollado en esta tesis.
de esta tabla en los campos: P1X, P1Y, P1Z, P3X, P3Y y P3Z, que corresponden a los vértices
opuestos del rectángulo que representaría al mapa en un plano horizontal (superficie o planta) o
vertical (sección). En este trabajo, se considera hacer en esta tabla los mismos cambios
mencionados para DATSSONDAJES, dándole también la misma flexibilidad y permitiendo la
creación de mapas poligonales.
De esta forma, el sistema se dejará mucho más flexible teniendo la posibilidad de agregar
nuevos tipos de elementos de una o dos dimensiones a medida que sea requerido por el
administrador del sistema. Las características de cada tipo de elemento serán totalmente
flexibles y configurables, al igual que todo el resto de los temas del SMD. En la figura 30 se
muestran los cambios que se alcanzaron a hacer durante el desarrollo de esta tesis para las
tablas de elementos mapeables.
Tabla DATSTRAYECTORIAS: Los sondajes están
planeados para seguir una trayectoria recta a medida que
son perforados. Sin embargo, debido a las características
del medio rocoso que atraviesan, así como a las
características propias del método de perforación, éstos
se van desviando. Para obtener una noción lo más exacta posible de la trayectoria seguida por
el pozo, se realiza una medición de azimut e inclinación en varias estaciones al interior del
39
Figura 32: Tabla DATSTRAYECTORIAS. Modelo propuesto.
mismo. Dichas mediciones, junto con otros parámetros son actualmente almacenados en la
tabla DATSTRAYECTORIAS (figura 31).
Durante el desarrollo de esta tesis se detectó que la estructura de esta tabla tiene un problema
conceptual con relación al método de captura de la información de trayectorias. Por esto, el
autor realizó un levantamiento de la práctica de medición de trayectorias en la Superintendencia
Geología para terminar finalmente en la redacción de un procedimiento (Rodrigo, 2005) el cual
es oficial actualmente. Los cambios necesarios dicen relación con el hecho que cada medición
de trayectoria se hace en un punto, siendo que la tabla actual considera un DESDE, HASTA.
Además, la orientación medida (mal llamada RUMBO en esta tabla) considera una corrección
por declinación magnética. Por lo tanto, muchas veces el dato que existe en la base de datos
no coincide con el que aparece en el certificado emitido por la empresa que realizó la medición.
Esto trae problemas de auditabilidad asociados.
Producto de lo expuesto anteriormente, se efectuaron
varios cambios en la estructura de la tabla
DATSTRAYECTORIAS, llegando a la que se muestra
en la figura 32. Los más importantes son la eliminación
del campo HASTA, la incorporación del campo
AZIMUT_CORREGIDO que corresponde a la
aplicación de la declinación magnética al campo
RUMBO (cuyo nombre se conserva por ahora), el cual siempre tiene el dato tal como se
encuentra en el certificado emitido por la empresa que haya realizado la medición.
Esta tabla tiene una estructura fija, lo que ha obligado a hacer cambios en el código a medida
que se han requerido cambios en los parámetros asociados a este concepto. Por esto, se
considera necesario dejar también esta tabla como un tema genérico de un tipo especial, que
pueda ser asociado al concepto de trayectoria pero que a la vez tenga la flexibilidad requerida.
40
Figura 33: Tabla GSYSESTILOSNUMERICORANGOS
original.
3.6 Estilos de Mapeo
El SMD maneja la información y el estilo (color, textura, abreviaciones) con el que la misma es
desplegada en sondajes y mapas. Para esto cuenta con varias tablas especialmente dedicadas
a este efecto y algunos campos en otras tablas de sistema.
Tabla GSYSESTILOSNUMERICORANGOS: Para el caso
de los campos numéricos, el estilo viene dado por el
intervalo en el que se encuentra el valor a desplegar. Dicha
información es almacenada en esta tabla (figura 33).
Se cambiará el nombre de esta tabla por uno más corto:
GSYSRANGOS.
Tabla GSYSECARACT: Ciertas características de la
descripción del tema "Estructuras" han requerido ser
configuradas aparte, por ejemplo, dado un tipo de estructura, qué campos son pertinentes. Esa
funcionalidad ha sido almacenada en esta tabla. Sin embargo, una vez que la tabla DATESTR
sea convertida en un tema genérico, esta funcionalidad estará presente en forma directa. Por
este motivo, se considera la eliminación de esta tabla configurando, en su reemplazo, las reglas
equivalentes para el nuevo tema "Estructuras".
Tabla GSYSNOMBRES: En esta tabla residen también los estilos de despliegue de cada
nombre del sistema. Este hecho hace que para cada nombre, por ejemplo "Baja" que podría ser
utilizado en un campo denominado "Intensidad", el estilo de despliegue es único, digamos azul.
Sin embargo, esto puede ser indeseable ya que varios temas pueden tener campos con el
atributo "Baja" entre los atributos admisibles, quedando todos restringidos a exhibir el mismo
estilo. Por esto, se recomienda trasladar los campos relativos al estilo de cada valor desde la
tabla GSYSNOMBRES hacia la tabla GSYSNEXOATT. De esta forma, la elección de los estilos
será independiente para cada campo de cada tema configurado. Además, producto de la
eliminación de la tabla GSYSNOMBRES, los estilos deberán ser trasladados de todas formas.
3.7 Concurrencia
Si bien los gestores de bases de datos como Oracle 9i incorporan un tratamiento adecuado
para la realización de transacciones concurrentes, el SMD considera también una
administración de este concepto a nivel de la aplicación. Esto lo hace estableciendo la reserva
de un tema (e.g. Litología) de un mapa o sondaje (e.g. Esmeralda Hundimiento) por, a lo sumo,
un usuario a la vez. Esto evita que dos usuarios modifiquen la información de la misma área o
41
tramos de sondaje al mismo tiempo. Recordemos que el mapeo se lleva a cabo en terreno,
donde no hay conexión a la red y, por lo tanto, no hay posibilidad de que un usuario vea los
cambios que realiza otro en tiempo real. Esta restricción es implementada y validada por la
aplicación de servicio (Servidor.exe y Procesador.exe).
Dada la restricción anterior, la concurrencia a nivel de bajada o subida de datos desde o hacia
la base de datos central (cuando varios usuarios desean hacer transacciones al mismo tiempo),
se resuelve ejecutando tantos hilos de ejecución de los procesadores de solicitud
(Procesador.exe) como transacciones simultáneas se estén llevando a cabo. Desde luego,
existe un parámetro que permite indicar el número máximo de transacciones simultáneas que
estamos dispuestos a admitir, entre otros parámetros administrativos de bajo nivel.
3.8 Repositorio Local de Información
Para comenzar a tratar este tema, hay que examinar la necesidad de contar con un SGDB a
nivel local en el SMD. La posibilidad de almacenar los datos en archivos de tipo XML o ASCII
puede ser una alternativa interesante. El tamaño de los mismos podría ser una desventaja, sin
embargo, resulta de gran interés estudiar esta posibilidad antes de tomar cualquier decisión.
El uso de Access a nivel local surgió del hecho que en la aplicación de mapeo original se utiliza
SQL intensivamente, leyendo datos desde el disco duro a través de dicha "base de datos".
Además, se cuenta con una muy utilizada herramienta de filtro de información que se ejecuta
por la misma vía del SQL en Access.
Sin embargo, la capacidad de memoria RAM de los computadores usados actualmente, hacen
posible la carga masiva de gran cantidad de datos en memoria. De esta forma, se elimina el
acceso constante a disco (acelerando de forma considerable el rendimiento), siendo necesario
replantear la forma de ejecutar los filtros de información.
El hecho de usar un repositorio propietario, tal como Access, trae riesgos asociados a
eventuales cambios no avisados en los protocolos de comunicación con la base de datos,
licenciamiento, entre otros.
Debido a la magnitud de los cambios que se propone efectuar en esta tesis, se considera más
prudente postergar cualquier decisión de cambio en el repositorio local de información. En
consecuencia, una vez elegido el lenguaje de programación y desarrollado un prototipo de
mapeador, se puede hacer un estudio con mejores antecedentes para evaluar el mejor
repositorio local.
42
Debido a las condiciones intensivas de uso del sistema, el autor considera conveniente realizar
las modificaciones parte por parte, priorizando los cambios sobre la base de datos central.
43
4. REPROGRAMACIÓN DEL SMD
En este capítulo se describirán las proposiciones y cambios efectuados en términos de las
aplicaciones que conforman el SMD. Para realizar estas acciones en forma ordenada y
minimizar el impacto sobre el funcionamiento actual del SMD, se confeccionó un plan de acción
que es descrito en la siguiente sección.
4.1 Plan de Acción
En este capítulo se detallan en forma ordenada cada una de las actividades técnicas que se
consideran necesarias para lograr los objetivos propuestos en esta tesis.
1. Para lograr una migración exitosa se considera necesario, dados los recursos y
limitaciones actuales, realizar todo los ajustes en la estructura de la base de datos
central y, paralelamente, las correcciones en el software actual (Visual Basic 6.0), de tal
forma de mantener la operatividad del sistema. Esto debido a que el costo de realizar
modificaciones al software actual es muy bajo en términos de tiempo. De esta forma, se
espera dejar funcionando el software actual modificado, con la nueva estructura de
datos. El orden recomendado para las modificaciones en la base de datos es el
siguiente:
• Traspaso de temas externos a temas genéricos.
• Eliminación de temas externos, tanto de la base de datos como del código de las
aplicaciones
• Cambio de ubicación de estilos de despliegue desde GSYSNOMBRES a
GSYSNEXOATT.
• Modificación del código de las aplicaciones que usan los estilos.
• Cambio en la denominación de las tablas asociadas a los temas genéricos.
• Modificación del código de los mapeadores y el configurador para responder al
cambio de denominación de tablas
• Cambio en la denominación de los campos de las tablas antes mencionadas
• Modificación de las aplicaciones de mapeo y configurador
• Reemplazo de los nombres codificados en las tablas de datos, por los nombres
originales.
• Eliminación de la tabla GSYSNOMBRES.
44
• Modificación de las aplicaciones de mapeo y configurador
• Programación de módulo para poblamiento de tablas de vértices
• Creación y poblamiento de las tablas de vértices y tramos, a partir de la información
contenida en GSYSOPORTES.
• Cambio en el código de aplicaciones de mapeo, configurador y procesador,
afectados por el cambio en la ubicación de los vértices y tramos del SMD
2. Una vez llevados a cabo todos los cambios en la base de datos central, se considera la
programación de las aplicaciones de mapeo en C#, conectadas al mismo repositorio
Access de la aplicación actual. El orden de programación recomendado es el siguiente:
• Aplicación de mapeo de plantas y secciones
• Aplicación de mapeo de sondajes
• Aplicación cliente
• Aplicación de transacciones: procesador.exe
• Aplicación de servicio: servidor.exe
• Aplicación de configuración del SMD: configurador.exe
3. Para el testing y marcha blanca, se considera la liberación de los nuevos módulos de
mapeo para dos usuarios avanzados del sistema actual. De esta forma es como se han
hecho todas las modificaciones al sistema, las cuales han resultado exitosas.
4. En forma paralela al desarrollo del prototipo en la nueva plataforma de programación, se
debe diseñar el nuevo formato de transmisión de los datos solicitados por los usuarios,
así como de los nuevos datos aportados por los mismos. Se recomienda suspender por
completo el intercambio de información vía archivos Access y reemplazar esta práctica
por un formato más estándar como archivos ASCII, XML o similares más compactos.
5. Se considera la realización de un estudio para determinar el cambio del repositorio local
de datos. Esto debido a que para esto será necesario realizar cambios tanto en la
aplicación de servicio como en la aplicación cliente y en los mapeadores propiamente
tales.
Los puntos 1, 2 y 3 fueron realizados durante el desarrollo de esta tesis. Sólo falta realizar los
puntos 4 y 5, los que quedan como una recomendación en este documento.
45
4.2 Lenguaje de Programación
La elección del lenguaje y plataforma de desarrollo se hará basado en la realidad actual del
SMD en cuanto a los siguientes puntos:
1. Equipo físico y humano de desarrollo disponible: Actualmente sólo hay una persona a
cargo del diseño, desarrollo e implementación del SMD, así como de su administración.
2. Condiciones establecidas por el negocio: Debido a que el SMD cumple una función
estratégica al interior de la Superintendencia Geología de la División El Teniente, es
necesario asegurar su funcionamiento continuo, así como modificaciones y
mantenimiento rápidos.
3. Restricciones establecidas por la tecnología: Los equipos presentes en la División tienen
sistemas operativos Windows 2000 o posterior, en su gran mayoría. El hecho que la
plataforma actual de desarrollo (Visual Basic 6.0) se encuentre descontinuada por
Microsoft desde marzo de 2005 aumenta el riesgo de incompatibilidades futuras con
nuevos productos de esta compañía que, para bien o para mal, son los más utilizados
en la corporación.
4. Necesidad de conservar continuidad en el servicio actual: La migración del SMD debe
ser transparente para el usuario, sin ocasionar interrupciones al servicio.
5. Conservar todas las funcionalidades actuales del SMD más todas las nuevas
funcionalidades que se consideran necesarias.
Los puntos anteriormente mencionados se traducen en la necesidad de contar con una
plataforma de desarrollo que cumpla, como mínimo, los siguientes requisitos:
1. Alta velocidad en la codificación.
2. Herramientas de depuración rápida.
3. Compatibilidad con los sistemas operativos Windows 2000 o posterior.
4. Capacidad de desarrollo tanto de software gráfico como de servicios (daemon) y
tecnologías de conexión a distintas fuentes de datos (ODBC, OleDb o similares).
A partir de los antecedentes antes expuestos, es posible dirigir la mirada hacia la plataforma
.NET que ha estado en constante progreso desde 2000. Dicha plataforma ofrece compatibilidad
con los sistemas operativos existentes en la división. Adicionalmente, existe el llamado proyecto
Mono (Mono, 2006), el cual promete la implementación de las clases de la plataforma .NET en
otros sistema operativos tales como Linux, Solaris, Mac OS X, etc. Dicha promesa lo hace muy
46
interesante además para la posible futura migración de las aplicaciones que dan el servicio del
SMD.
Dentro de la plataforma .NET, existen una serie de lenguajes disponibles para el desarrollo.
Dentro de ellos destacan dos como interesantes para esta tesis: Visual Basic .NET y C# .NET.
Entre estos dos lenguajes, se optará por el desarrollo en C# debido a las siguientes razones:
1. Permite el desarrollo rápido de aplicaciones.
2. Posee recolección de basura, lo que evita el "escape" de memoria (memory leak)
contando con un algoritmo de recolección bastante eficiente.
3. Similitudes lingüísticas con Java y C++.
4. Estadísticas de rendimiento comparables (usualmente superiores) a lenguajes similares.
5. Entorno de desarrollo (IDE) bastante familiar para un desarrollador de Visual Basic 6.0.
6. Características como boxing y el sistema común de tipos que hacen mucho más fácil la
codificación.
7. Facilidad de distribución (un archivo .exe y algunas .dll).
8. Poderosas librerías que vienen con la tecnología .NET (e.g. Managed DirectX).
Gran compatibilidad con .NET Compact FrameWork, permite el desarrollo de aplicaciones para
PDA's con sistemas operativos del tipo Windows Mobile, que tengan el .NET Compact
FrameWork instalado.
47
Figura 34: Arquitectura propuesta para el SMD.
4.3 Arquitectura Propuesta
Tal como se describió en el capítulo 1, la arquitectura actual del SMD adolece de problemas de
acoplamiento entre las distintas capas que lo componen.
El trabajo efectuado en esta tesis sentará las bases para eliminar el acoplamiento antes
mencionado, de tal forma de conseguir una arquitectura similar a la mostrada en la figura 34.
Esta arquitectura separa el modelo de datos de las capas de servicio y cliente, mediante una
capa de acceso a datos, de tal forma de poder hacer cambios en dicho modelo, sin afectar los
desarrollos realizados aguas abajo. De esta forma, una vez establecido un protocolo estándar
de transmisión de datos, se podría licitar el desarrollo de cada una de las capas del SMD a
distintas empresas expertas en cada tema. Así mismo, se podría contar con más de una versión
de la aplicación cliente, la que incluso podría funcionar en otros sistemas operativos tales como
alguna distribución de Linux. Esto favorecería la portabilidad del SMD y su escalabilidad en el
futuro.
48
4.4 Reprogramación de aplicaciones en Visual Basic 6.0
Para adaptar el SMD a la nueva estructura de datos, según el plan diseñado, será necesario
reprogramar algunas funcionalidades de las siguientes aplicaciones:
1. Procesador
2. Configurador
3. Mapeador de Mapas
4. Mapeador de Sondajes
5. Importador de Vectores
6. Importador de Imágenes
En esta sección sólo se muestran los cambios que han sufrido los módulos más relevantes de
cada una de las aplicaciones antes enumeradas. Las interfaces que se muestran incorporan las
modificaciones realizadas, las que son descritas en cada sección.
4.4.1 Procesador de Solicitudes
Esta aplicación funciona en el servidor de aplicaciones, siendo la encargada de llevar a cabo las
solicitudes de los usuarios. Para esto es capaz de realizar lo siguiente:
1. Validar los permisos vigentes para el usuario
2. Bajar la información requerida si corresponde
3. Actualizar la base de datos central con los nuevos datos aportados por el usuario
4. Almacenar la información relativa a cada transacción
5. Generar una base de datos local válida, a partir de la estructura actual de la base de
datos central, para enviar al equipo del usuario
Para realizar estas tareas, esta aplicación obtiene la base de datos local del cliente (Access) de
un directorio del servidor de aplicaciones donde fue dejado vía FTP por la aplicación cliente.
Genera vínculos desde ésta a las tablas de la base de datos central y efectúa sentencias SQL
adecuadas a los fines de la solicitud realizada por el usuario. Este proceso, tal como se puede
ver, es bastante "poco estándar" y tiene asociados varios riesgos, por ejemplo, el hecho de
vincular una base de datos Access a varias tablas de la base de datos central.
Por esto, se recomienda cambiar esta práctica por una subida y bajada de datos que no
contemple la vinculación de tablas como medio. Esto ahora será posible debido a la eliminación
49
de los campos tipo BLOB de la tabla de soportes. Dichos campos sólo podían ser insertados a
través de SQL en la base de datos central, mediante la vinculación de tablas.
La validación de permisos de usuario no se ha visto afectada con los cambios en la estructura
de datos, debido a que las tablas asociadas permanecen iguales.
En cuanto a la bajada de información, afortunadamente la generación de la estructura de la
base de datos local se hace en forma automática con la lectura de las tablas de la base de
datos central. Por lo tanto, los cambios efectuados en la base de datos central, se verán
reflejados en la base de datos local, sin necesidad de modificaciones de código fuente.
Solamente fue necesario incluir la bajada del registro de GSYSSOPORTES asociado a cada
elemento mapeable (mapa o sondaje).
La eliminación de las tablas externas (DATSTABLAn) permite eliminar algo de código específico
para ellas.
La actualización de información en la base de datos central se ve afectada por los siguientes
cambios:
1. El IDSOPORTE de la tabla GSYSSOPORTES deja de ser autonumérico y cambia su
tipo de datos a string. Esto simplifica el código ya que hasta el momento era necesario
reasignar los identificadores de los nuevos soportes, por los definitivos asignados en la
base de datos central, al momento de la inserción de cada nuevo registro. Ahora los
soportes ya vienen con un IDSOPORTE único, por construcción.
2. La tabla GSYSSOPORTES se divide en tres: GSYSSOPORTES, TTEVERTICES y
TTETRAMOS. Esto produce un cambio en la cadena SQL que efectúa la subida de
datos. Este cambio permitirá en el futuro dejar de usar Access como portador de la
información, ya que hasta el momento era necesario sólo por el hecho del traspaso de
los campos de tipo BLOB desde Access a Oracle a través de la vinculación de tablas, tal
como se mencionó anteriormente.
4.4.2 Configurador
Esta aplicación es la que permite a los administradores del SMD realizar, entre otras, las
siguientes tareas:
1. Crear cuentas de usuario
2. Crear perfiles de usuario
3. Crear elementos mapeables: mapas y sondajes
50
Figura 35: Módulo de administración de temas genéricos.
4. Crear perfiles de elementos mapeables
5. Crear temas de mapeo
6. Configurar las reglas de mapeo: relaciones entre temas, relaciones entre campos, reglas
de validación de campos y valores que puede aceptar cada campo
7. Configurar los estilos de despliegue oficiales para cada tema
Los cambios en la estructura de datos hicieron necesario realizar modificaciones al módulo de
configuración de estilos de despliegue, almacenando los estilos en las nuevas tablas destinadas
para ello. Previamente, se realizó la migración de los datos de estilos ya configurados desde las
tablas originales hacia su nueva ubicación. Esto se hizo mediante la aplicación PL/SQL
Developer Versión 5.0. La eliminación de las tablas externas permite eliminar un módulo
completo destinado a su creación y edición.
Para implementar los cambios planeados, será necesario hacer varios cambios en los módulos:
1. Administrador de Temas Genéricos
2. Administrador de Sondajes
3. Administrador de Mapas
4. Administrador de Datos
El Administrador de
Temas Genéricos
(figura 35) es el que
proporciona la
interfaz para crear y
editar los temas de
mapeo del SMD.
51
Figura 36: Función para normalizar una cadena (Visual Basic 6.0)
Se procede a cambiar el método de denominación de las tablas asociadas a los temas
genéricos, reemplazando el prefijo "DATGTABLA" por "D_" y reemplazando el identificador del
tema, por el nombre real del tema normalizado. Para esto, se programó una simple función que
lleva todas las letras a mayúsculas sin acentos, reemplaza los espacios por guiones bajos ("_")
y elimina el resto de los caracteres (figura 36).
52
Figura 37: Módulo de Administración de Sondajes.
Además, para los campos de tipo texto fijo, se dejan como tipo VarChar2(90) en lugar de
Number, ya que desde ahora se almacenará el atributo literal y no el ID asociado al atributo en
la tabla GSYSNOMBRES.
El Administrador de Sondajes (figura 37) se verá muy afectado por el cambio propuesto, en el
sentido de reemplazar la tabla DATSSONDAJES por un tema configurable. Si bien se considera
de gran utilidad el cambio propuesto, el autor decide que deberá ser aplicado en una etapa
posterior al desarrollo de esta tesis ya que se considera prudente probar el sistema completo
con las modificaciones más urgentes, para luego implementar las menos críticas. El único
cambio que se llevará a cabo, será el de eliminar los campos VERTICES y EXTRADATA,
trasladando la información espacial del sondaje a la estructura dada por las tablas:
GSYSSOPORTES y TTEVERTICES. Así, cada sondaje será almacenado en un registro de la
tabla GSYSSOPORTES con su identificador IDSONDAJE ingresado en el campo IDSOPORTE.
53
Figura 38: Módulo de Administración y Análisis de Datos.
El Administrador de Datos (figura 38), es el módulo que permite la consulta y análisis de todos
los datos del SMD, tanto para sondajes como para mapas.
Debido a los cambios en la estructura de datos, fue necesario hacer algunos cambios en las
consultas SQL que realiza este módulo. Esto afectó positivamente el rendimiento de las
consultas a campos de tipo texto fijo. Además, el nuevo formato de almacenamiento de vértices
ha hecho disminuir el código fuente necesario para hacer consultas de sondajes que cortan
determinado volumen. Este tipo de consultas consisten en que dado un polígono en planta y
dos cotas, se obtienen todos los sondajes que, al menos en parte, están contenidos en dicho
volumen.
54
Figura 39: Mapeador de mapas (plantas y secciones) del SMD.
4.4.3 Mapeador de Mapas
Esta aplicación (figura 39), genera las interfaces necesarias para el mapeo de mapas (plantas,
secciones y superficie). Para esto, realiza las siguientes tareas, entre muchas otras:
1. Despliega los soportes con los estilos configurados en la base de datos
2. Despliega los vectores que se encuentren disponibles
3. Despliega las imágenes georreferenciadas que se encuentren disponibles
4. Genera las interfaces de mapeo de cada tema configurado
5. Valida la topología de los soportes dibujados (evita sobre posición de soportes del
mismo tema en el mismo espacio)
6. Provee herramientas de filtro de información
7. Permite imprimir mapas
8. Permite generar secciones definidas por el usuario en cualquier planta y con cualquier
orientación y extensión
55
Figura 40: Función para asignación de identificador de soporte.
El cambio en la forma de asignar los identificadores de los nuevos soportes afectará a ambos
módulos de mapeo. Se crea una nueva función (figura 40) que genera dicho identificador,
garantizando su unicidad al mantener un correlativo interno para cada sesión de mapeo. Dicha
sesión se identifica por un número único (denominado en el código como "IdProceso")
proporcionado por el sistema al momento de la bajada de datos.
La nueva denominación de las tablas asociadas a los temas de mapeo no incide prácticamente
en el código fuente de las aplicaciones de mapeo, ya que dicho nombre siempre ha sido leído
del campo NOMBRE_TABLA de la tabla GSYSTABLAS. Así mismo, la eliminación de los temas
externos y el tema "Estructura" sólo tiene como consecuencia la eliminación de bastante código
requerido para administrar el comportamiento del software ante tales casos especiales. Por lo
tanto, se considera muy positivo desde este punto de vista.
El cambio en la denominación de los campos de las tablas antes mencionadas resulta más
complejo de implementar, por el alto grado de dependencia que había al interior del código
fuente, de esta forma de denominación. El cambio se llevó a cabo con éxito de todas formas.
Al dejar de almacenar los vértices en campos de tipo BLOB, se ha podido prescindir de la dll
que prestaba el servicio de interpretación de dichos campos. Así, se hizo un cambio bastante
profundo en los métodos de lectura de soportes, haciendo un uso más intensivo de la memoria
56
RAM y disminuyendo al máximo los accesos a disco que se hacían con demasiada frecuencia
en la versión actual de los mapeadores.
Con estos cambios se logró ahorros de tiempo del orden de 80% en planos con gran cantidad
de información. Este ahorro fue medido cargando la información del mismo mapa ("Esmeralda
Producción") en el formato antiguo y el nuevo. Se hicieron 10 mediciones del tiempo de
despliegue del total del mapa con todos los temas "encendidos". En todas ellas la aplicación
que utilizaba el modelo antiguo demoró del orden de 11 segundos, mientras que la nueva
aplicación registró tiempos del orden de los 2 segundos.
57
Figura 41: Mapeador de Sondajes del SMD.
4.4.4 Mapeador de Sondajes
Esta aplicación (figura 41) genera las interfaces necesarias para el mapeo de sondajes. Para
esto, realiza las siguientes tarea, entre muchas otras:
1. Despliega los soportes con los estilos configurados en la base de datos
2. Genera las interfaces de mapeo de cada tema configurado
3. Valida la topología de los soportes dibujados (evita traslapes)
4. Permite imprimir sondajes
Esta aplicación comparte bastante código con el mapeador de mapas, por lo que los cambios
referidos anteriormente son válidos también para este módulo.
58
Figura 42: Mapeador unificado de sondajes y mapas.
4.4.5 Mapeador: Unificación de sondajes y mapas
Para simplificar aún más la mantenibilidad del código maximizando la reutilización del mismo,
se procedió a unificar los mapeadores de sondajes y mapas en una única aplicación MDI
(multiple document interface), tal como se aprecia en la figura 42.
Esto finalmente se tradujo en una disminución importante de la cantidad de líneas de código y
del tiempo requerido para depurar errores.
Además, ha traído importantes beneficios prácticos para el uso del sistema. En particular, ahora
es posible desplegar paralelamente un sondaje y un mapa, siendo posible visualizar la
expresión del sondaje sobre el mapa antes mencionado al momento de su edición. Esto facilita
la interpretación precoz de la información geológica, así como posteriores análisis espaciales de
información.
59
Figura 43: Importador de Vectores del SMD.
4.4.6 Importador de Vectores
El Importador de Vectores (figura 43) se vio afectado debido a que la forma de almacenamiento
de los vértices de los datos vectoriales era similar al de los datos en general, considerando el
uso de BLOB's. Por esto, fue necesario hacer modificaciones análogas a las requeridas por los
módulos de mapeo, de tal forma de almacenar los archivos dxf importados, en la nueva
estructura que considera una tabla de vértices.
60
Figura 44: Clase para el manejo de excepciones.
4.5. Prototipo del Mapeador de Elementos 2D
Para probar algunas de las capacidades básicas del lenguaje C# y la plataforma de desarrollo
.NET, se desarrolló un pequeño prototipo de la interfaz del mapeador de elementos 2D, que
corresponde al módulo capaz de visualizar los mapas del SMD. Para el desarrollo se crearon
clases básicas, algunas de las cuales son descritas en esta sección.
Este módulo cuenta con las siguientes capacidades:
1. Conexión a la misma base de datos Access '97 con la que actualmente operan los
mapeadores del SMD.
2. Despliegue de los soportes de todos los temas configurados, con los estilos definidos
actualmente en el SMD.
3. Capacidad de zoom in, zoom out, paneo y selección gráfica de soportes.
Para el manejo adecuado de excepciones, se creó la clase MyException (figura 44), la cual
llena un archivo de texto con cada excepción que se produce y la pila de llamadas recibidas en
forma previa al evento. Esto favorece mucho la depuración del código.
61
Figura 46: Función para abrir una base de datos Access en Visual Basic 6.0.
Figura 45: Clase para acceso a datos.
4.5.1 Acceso a la base de datos local
Las aplicaciones de mapeo actuales se conectan a la base de datos
local Access, a través de la tecnología DAO (data access objects),
proporcionada por el lenguaje Visual Basic 6.0. Dicha tecnología
provee de todas las clases necesarias para acceder y modificar los
datos contenidos, además de algunas utilidades adicionales como la
compactación de la base de datos.
En el caso de C#, se utilizó la tecnología ADO .NET para la conexión
al repositorio local. Las clases utilizadas para el acceso a datos están
contenidas en el espacio de nombres (namespace)
System.Data.OleDb las cuales son explotadas a través de la construcción de una clase
denominada Db (figura 45).
El código necesario para acceder a la base de datos local se exhibe tanto para Visual Basic 6.0
(figura 46) como para C# (figura 47).
62
Figura 48: Clase Punto.
Figura 47: Constructor de clase de acceso a datos en C#.
4.5.2 Interfaz gráfica de usuario
Con el objetivo de conservar la familiaridad del usuario con la interfaz del software actualmente
en funcionamiento, ésta fue conservada en la mayor medida posible, haciendo sólo algunas
modificaciones menores que han sido sugeridas en muchos casos por los mismos clientes del
SMD.
Para los objetos gráficos, la clase básica es el punto (figura 48), el
cuál cuenta con coordenadas reales X, Y, Z y con un par de lo que
denomino coordenadas topológicas. Estas últimas sirven para
resolver las relaciones entre los distintos polígonos en cada planta
o sección, tales como intersecciones, sobre posiciones o
inclusiones. Estas relaciones son siempre resueltas en 2D, por lo
que para el caso de las plantas se utilizan las coordenadas X e Y,
mientras que en las secciones, las coordenadas topológicas son
obtenidas como la proyección de cada polígono en el plano vertical
definido por la sección. En esta clase se implementa el método que
determina la distancia entre dos puntos.
63
Figura 49: Clases definidas para el manejo de elementos mapeables.
Figura 50: Clase soporte.
Los elementos mapeables como sondajes y mapas se consideran hijos de una clase abstracta
que denomino Elemento Mapeable (figura 49). En dicha clase agrupo también a elementos de
apoyo como lo son los vectores y las imágenes.
El manejo de soportes quedó centralizado en la clase
denominada Soporte (figura 50), la cual reúne ciertas
propiedades que son actualizadas a medida que el soporte va
siendo construido como lo son los límites de ubicación, el largo y
área si aplican, etc. Además, al momento de irse agregando
vértices a un soporte, la función que realiza dicha labor valida la
topología del mismo, evitando que el nuevo trazo corte a un trazo
ya existente o que el polígono se cierre en un punto que no sea el
primero.
Todas las visualizaciones que permite el sistema son en
superficies planas, ya sea una planta (plano horizontal) o una
sección (plano vertical). Los vértices que componen un soporte se
almacenan en una lista enlazada, lo que hace muy eficiente su
inserción y obtención.
64
Figura 52: Clases para manejar los temas, atributos y valores definidos en el código del SMD.
Figura 51: Clase lista enlazada.
Para manejar las listas de vértices, así como listas de otros elementos, se creo algo muy similar
a lo que son los templates en C++, y que en C# son denominadas clases genéricas. Éstas
están agrupadas en el espacio de nombres System.Collections.Generic. Haciendo uso de esta
funcionalidad, se crea la clase ListaElementos (figura 51). Tal como es de esperarse, el uso de
la clase ListaElementos nos permite mantener listas de distintos conjuntos de objetos de la
aplicación y se hace uso intensivo de ésta en muchas clases.
Para implementar el manejo del código del SMD, así como de los
estilos asociados a los valores que asumen los distintos atributos
de cada tema, se han creado las clases: tema, atributo y valor
(figura 52).
65
Figura 53: Vista del mapa Esmeralda Hundimiento, a través del prototipo en C#.
Finalmente, en la figura 53 se muestra un despliegue del sector Esmeralda Hundimiento del
yacimiento El Teniente.
Lograr este desarrollo no tomó más allá de un mes incluyendo el diseño y programación.
Además, el autor se ha dedicado también a otras actividades dentro de ese período de tiempo.
Por este motivo, se sostiene que la velocidad de desarrollo que se puede conseguir es muy
adecuada para los recursos disponibles para este efecto.
El rendimiento de la aplicación, en cuanto a velocidad de despliegue especialmente, es inferior
al logrado con Visual Basic 6.0. Sin embargo, se debe hacer notar que el desarrollador tiene
mucho que aprender con respecto al uso de GDI+ (Graphics Device Interface).
Otra herramienta destacable de Visual Studio 2005 es su capacidad de generación de
diagramas de clases, la cual es muy eficiente y útil para agilizar el proceso de diseño y
documentación del software.
66
5. CONCLUSIONES Y RECOMENDACIONES
En este capítulo se detallan las conclusiones a las que fue posible llegar una vez terminado este
trabajo, considerando tanto la experiencia recopilada durante el desarrollo del mismo, como la
experiencia obtenida durante los seis años que ha llevado el desarrollo e implementación del
mapeo digital en la Superintendencia Geología de la División El Teniente.
5.1 Conclusiones
En esta tesis se ha hecho una revisión crítica del sistema de mapeo digital que se viene
desarrollando y utilizando en la División El Teniente de CODELCO CHILE desde el año 2002.
Esta revisión ha permitido identificar y realizar los cambios más críticos que dicho sistema
requería para posibilitar su escalamiento e interoperabilidad. Es importante destacar que
muchos de los cambios indicados en esta tesis, han sido puestos con éxito en producción
durante el curso de este trabajo.
Los cambios realizados se han traducido en diversas mejoras en términos de normalización de
la estructura de datos subyacente, así como en el rendimiento de la aplicación de despliegue
gráfico.
La mayor normalización de la base de datos ha permitido el acceso a la información por
usuarios no familiarizados con el uso del SMD. El reemplazo de los campos de tipo BLOB ha
permitido acceder a la información de los vértices de los distintos soportes almacenados por vía
de simple SQL, disminuyendo drásticamente la dependencia del SMD por parte de la
Superintendencia Geología. La nueva estructura de datos permite facilitar la consulta geográfica
de soportes por cercanía a un punto dado.
La reprogramación de varias aplicaciones del SMD ha optimizado sensiblemente el despliegue
de la información de mapas, gracias a la disminución del acceso a disco. Esto fue posible en
gran medida debido a los cambios en la estructura de datos antes mencionados.
Para hacer posible el escalamiento del SMD, se ha definido a Visual Studio 2005 y, en
particular, al lenguaje C# como la plataforma de desarrollo futuro, en caso de seguir contando
con los mismos recursos físicos y humanos hasta ahora disponibles. El desarrollo del prototipo
de mapeador 2D en C#, ha permitido confirmar que este lenguaje resulta muy adecuado para
extender el desarrollo del SMD. La potencia de la plataforma .NET unida a la velocidad de
desarrollo lograda mediante el IDE de Visual Studio 2005 permiten continuar escalando el
sistema con los recursos actualmente disponibles, al menos en el mediano plazo.
67
Se ha confeccionado un plan de migración que permitirá un cambio de plataforma de desarrollo
gradual pero eficiente. Resulta fundamental seguirlo en forma estricta para garantizar la mínima
interferencia con la producción.
El éxito que ha tenido el mapeo digital durante sus seis años de funcionamiento en la
Superintendencia Geología de la División El Teniente, se ha debido fundamentalmente a que su
desarrollo ha estado siempre ligado estrechamente con el negocio al que apoya, en este caso la
Geología. Sin embargo, su generalidad le permite fácilmente ampliar su alcance fuera de esta
área, incorporando el manejo de otros temas como el estado geomecánico de los túneles.
La atención constante que se ha puesto en la satisfacción de los usuarios, siendo el
desarrollador uno de ellos, ha sido la base para la corta curva de aprendizaje que tienen las
aplicaciones de mapeo y análisis del SMD.
Todas las etapas de desarrollo del sistema de software antes detalladas, incluyendo esta tesis,
se han llevado a cabo mediante una estrategia de desarrollo "poco convencional", sin equipo de
diseño, desarrollo y pruebas bien definidos. El diseño y desarrollo han estado a cargo del autor,
mientras que las pruebas en general son realizadas por los usuarios más experimentados. Esta
práctica, si bien ha funcionado hasta el momento, se considera poco reproducible ante cambios
en las personas que desarrollan y usan el SMD.
Por esto, durante el desarrollo de esta tesis, el autor ha publicado una serie de procedimientos
que describen en detalle los pasos de cada una de las actividades relacionadas en mayor o
menor medida con la administración del SMD (Rodrigo, 2005, 2006 a y 2006 b). Dichos
documentos podrán ayudar también a la Superintendencia Geología de la División El Teniente a
certificarse ISO9000, meta que ha sido fijada por la Corporación para el mediano plazo.
5.2 Recomendaciones
En esta sección se indican una serie de recomendaciones para tres distintos ámbitos que
comprenden el SMD.
5.2.1 Acceso a datos
• Eliminar la práctica de vincular tablas desde una base de datos Access a la base de
datos central, por una subida y bajada de datos que porte los registros como texto y los
almacene en algún formato no propietario para su transmisión por la red.
• Estudiar alternativas para optimizar la bajada de información desde la base de datos.
68
• La base de datos local Access '97 actualmente utilizada debe ser reemplazada lo antes
posible. Ya se está comenzando el estudio de una buena alternativa para el repositorio
local de datos del SMD.
• Eliminar el único tema preconfigurado (Estructura) y reemplazarlo por uno genérico
equivalente.
• Mejorar el modelo de datos en lo que se refiere a vinculación de temas y atributos. En
particular, permitir vincular un tema a uno o más temas.
5.2.2 Protocolo de comunicación y transmisión de datos
• Implementar de un protocolo estándar de transmisión de los datos solicitados por los
usuarios, permitirá el desarrollo de varios tipos de aplicaciones de mapeo. Esto nos
permitirá adjudicar las distintas capas del SMD a distintos grupos de desarrollo
especializados en cada una de ellas.
5.2.3 Aspectos Administrativos
• Para poder lograr una trazabilidad de los cambios que sufren los soportes y la
información en general con el tiempo (por ejemplo, la evolución de una falla), se
recomienda estudiar los cambios en el modelo de datos que permitan esta potencialidad.
• Se recomienda licitar el desarrollo y mantenimiento de los distintos módulos del SMD
para lograr la permanencia del sistema en el tiempo. Dichas licitaciones deben ser
dirigidas y coordinadas por profesionales del perfil de los que han participado en el
desarrollo del SMD, quienes tienen el conocimiento cabal del negocio y de la
herramienta de software que lo apoya. Esto disminuirá la dependencia del SMD del
diseñador y desarrollador actual.
69
6. BIBLIOGRAFÍA
1. Encom Technology Pty Ltd. (2006). Encom Discover 6.1. Sistema de Información
Geográfica para profesionales de las Ciencias de la Tierra.
<www.encom.com.au/pdfs/discover61_spanish.pd>.
2. Esri (2006). Arcinfo, Complete Desktop GIS for the GIS professional. <www.esri.com/software/arcgis/arcinfo>
3. GAF (2006). Software. <www.gaf.de>
4. Geosoft (2006). Oasis Montaj. <www.geosoft.com/pinfo/oasismontaj/index.asp>
5. Geovectra S.A. (2003). Manual de GVMapper Versión 3.1.
6. Geovectra S.A. (2006). GVMapper. <www.geovectra.cl>
7. Mono. (2006). What is Mono? <www.mono-project.com>
8. Rodrigo B., José M. (2005). Procedimiento Administrativo de Proposición, Realización y
Reporte de Sondajes. GRMD-SGL-P-017. División El Teniente. CODELCO CHILE.
9. Rodrigo B., José M. (2005). Módulo de Análisis y Administración de Datos de Sondajes
para el Sistema de Mapeo Digital. SGL-I-124-2005. División El Teniente. CODELCO
CHILE.
10. Rodrigo B., José M. (2006 a). Instructivo para Certificación de Perforación, Topografía
de Collar y Medición de Trayectoria de Sondajes. GRMD-SGL-I-007. División El
Teniente. CODELCO CHILE.
11. Rodrigo B., José M. (2006 b). Manual de Instalación y Operación del Sistema de
Mapeo Digital. Informe Inédito de la Superintendencia Geología. División El Teniente.
CODELCO CHILE.
70
ANEXO A: Glosario
Base de Datos Central: Es la base de datos donde se almacena toda la información del SMD.
A ella sólo tiene acceso el servidor de aplicaciones y el módulo de configuración.
Actualmente es administrada a través de Oracle 9i.
Base de Datos Local: Es el repositorio donde se almacena la información en cada equipo de
mapeo. Actualmente se utiliza Microsoft Access '97 para este efecto.
BLOB: Binary Large Object.
Campo autonumérico: Es un campo que se auto incrementa en una unidad cada vez que se
agrega un registro en la tabla a la que pertenece. Para implementar esto en Oracle, se crea
una secuencia y un trigger que extrae el nuevo valor y lo inserta el campo de interés.
Corte Transparente: Sección muy delgada de una roca, cortada y preparada para su estudio al
microscopio.
Elemento Mapeable: Toda entidad espacial de una dimensión o dos dimensiones, sobre la cual
se pueden crear soportes en los distintos temas configurados en el SMD. Ejemplos de
elementos mapeables son las plantas, secciones, mapas de superficie y sondajes.
GCTIC: Gerencia Corporativa de Tecnologías de la Información y Comunicaciones
Manteo: Ángulo que forma un plano con el plano horizontal, medido en la dirección de máxima
pendiente del plano aludido.
Mapa: Representación geográfica bidimensional de la realidad. Usualmente se utilizan plantas
(mapa horizontal plano) o secciones verticales (mapa vertical plano).
Mapear: Reconocer información relativa a un tema dentro de un sondaje o mapa.
Rumbo: Ángulo que forma un linear con el Norte geográfico.
SMD: Sistema de Mapeo Digital.
Sondaje: Un sondaje consiste en una muestra de roca obtenida mediante la perforación de un
pozo en el macizo rocoso. Dicha muestra puede ser un cilindro sólido (sondaje diamantino)
o una muestra de polvo de roca (sondaje de aire reverso).
Soporte: Entidad espacial a la cual se le asocia información relativa a algún tópico. Puede ser
un punto, una polilínea o un tramo de un sondaje.
Tema Maestro o Padre: Es un tema que no está vinculado a ningún otro tema.
Tema Vinculado, Detalle o Hijo: Es un tema vinculado a otro de mayor jerarquía o maestro.
71
Trayectoria: Sucesión de mediciones puntuales de la orientación de un sondaje, que permiten
determinar su desviación con respecto al programa del mismo y, en consecuencia, su
ubicación "real" en el espacio.
Vectores: Son planos importados al SMD a partir de archivos DXF. Éstos quedan disponibles
en el sistema para los usuarios autorizados. Usualmente se utilizan para almacenar los
planos de los túneles de los sectores productivos.
Vértice: Punto (x, y, z) perteneciente a un soporte y originado durante el proceso de mapeo. A
un vértice único se le denomina punto en el SMD. Una sucesión de vértices puede ser una
polilínea o un polígono, en caso que el primer y último vértice sean iguales.
72
ANEXO B: Descripción global del SMD y sus componentes
En este anexo se describe el SMD en términos de sus principales componentes, de tal forma de
entregar al lector una visión de la forma en que este sistema opera y de las funcionalidades que
proporciona a los usuarios. Las interfaces serán omitidas para proteger la confidencialidad del
SMD.
B.1 Configurador
Este módulo del SMD es el que permite crear y administrar las cuentas de usuarios, perfiles de
usuarios y el código de mapeo implementado. También permite acceder a toda la información
almacenada, proporcionando herramientas de filtro, análisis de datos y utilidades de
exportación.
El acceso a este módulo se debe restringir a usuarios de confianza, con gran conocimiento del
negocio que se está configurando (e.g. geología, geomecánica u otro) y con habilidades para
estructurar información en forma coherente. Es deseable, aunque no indispensable, que se
tengan algunos conocimientos básicos de administración y consulta de bases de datos
(lenguaje SQL).
B.1.1 Creación de Cuentas de Usuario y Perfiles
Mediante una interfaz se permite crear y editar las cuentas de los usuarios del SMD. A cada
usuario le puede ser asignado uno o más perfiles. Cada perfil consiste en una serie de
autorizaciones para acceder a los distintos temas configurados en el SMD, así como a los
distintos elementos mapeables. De esta forma cuando un usuario reserva un mapa para
levantar información en el mismo, debe tener acceso al mapa y, separadamente, debe tener
acceso a los temas que desea editar.
Por otra parte, existen los llamados perfiles de elementos mapeables los que permiten asociar
un mapa con un conjunto específico de temas. Esto nos habilita para tener mapas temáticos
específicos destinados exclusivamente, por ejemplo, al levantamiento e interpretación litológica.
Cada elemento mapeable puede tener tan sólo un perfil.
B.1.2 Creación de Temas de Mapeo
Se provee una interfaz que permite crear cualquier tipo de tema o tópico que se requiera
mapear en terreno, sondajes o interpretar en gabinete.
73
El enfoque consiste en permitir al usuario crear un tema cualquiera. Luego, puede crear
campos, que son los conceptos a reconocer para dicho tema al momento de mapear. Cada
campo puede ser de tipo numérico, texto, memo (texto largo), objeto (archivo binario como foto,
documento pdf, etc.) o booleano. Se pueden establecer ciertas reglas de validación sobre los
valores que pueden asumir los campos (mínimo, máximo, suma mínima, suma máxima, etc.).
En particular, los valores de los campos de texto se pueden configurar de tal forma que el
usuario deba elegir entre un número restringido de posibilidades, ayudando al cumplimiento de
un estándar de mapeo. Sin perjuicio de esto, los usuarios que estén debidamente autorizados,
pueden agregar nuevos valores a dichos campos al momento del mapeo.
B.1.3 Consulta de Información
Para realizar análisis de grandes cantidades de información, el configurador cuenta con un
módulo destinado a este efecto, denominado Administrador de Datos. Su función consiste en
dar acceso a toda la información contenida en la base de datos, aportando herramientas para
simplificar su consulta y filtro tanto temático como espacial. Los datos obtenidos de esta forma,
pueden ser exportados en formato ASCII o Excel, lo que permite su posterior utilización en
softwares de modelamiento u otros.
Además, si se cuenta con los privilegios necesarios, es posible consultar todas las
transacciones realizadas en el sistema (bajadas de elementos, actualizaciones, labores
administrativas, etc.). Esto permite un control cercano de las actividades y facilita la posibilidad
de llevar una estadística respecto de las mismas.
B.1.4 Creación y edición de Elementos Mapeables
Los sondajes y mapas pueden ser creados y editados mediante sendas interfaces. Éstas
permiten asignarles nombre, perfil de mapeo (los temas que le corresponderán) y ubicación
espacial, entre otras características administrativas.
B.1.5 Importación de imágenes y planos vectoriales
Para mapear tanto en superficie como en labores subterráneas, suele ser de gran utilidad
contar con un plano topográfico. Dichos planos pueden ser importados al sistema cuando están
en formato dxf. Así mismo, si se cuenta con imágenes satelitales, fotografías aéreas o planos
antiguos escaneados, es posible georreferenciar dichas imágenes e importarlas al SMD para
contar con ellas al momento del mapeo o la interpretación.
74
B.1.6 Creación de programas de sondajes
Mediante una interfaz destinada al efecto, los geólogos pueden crear sus programas de
sondajes, ingresando cada una de las propuestas (nombre, ubicación, tipo de muestra, etc.). El
SMD provee la posibilidad de visualizar la propuesta en el mapa de tal forma de descartar a
priori cualquier error en los datos. Además, este módulo almacena dicha información en la base
de datos, lo que permite hacer un control administrativo del proceso de perforación de sondajes
desde la propuesta hasta el mapeo del testigo.
B.1.7 Administración de parámetros críticos
Existen generalmente una serie de parámetros administrativos que es conveniente almacenar
en la base de datos. Un ejemplo de dichos parámetros es la declinación magnética. Este dato
debe ser obtenido de una fuente confiable (IGM: Instituto Geográfico Militar) y su valor debe
estar respaldado por un documento oficial. Sin embargo, es útil que todos los usuarios tengan
acceso a dicho valor con objetivos prácticos. El SMD provee la posibilidad de almacenar los
parámetros críticos que sea necesario, para lo cual se consulta su nombre, descripción, tipo de
dato y valor. Una vez que son creados, cualquier aplicación perteneciente al SMD tendrá
acceso a dicho parámetro, pero sólo en modo de lectura. De esta forma cualquier modificación
en los valores (hecha en el Configurador), es inmediatamente difundida por el SMD a los
usuarios del sistema.
B.2 Servidor y Procesador
Debido a la naturaleza distribuida del SMD, existen dos aplicaciones encargadas de "escuchar"
y realizar las solicitudes encargadas por los usuarios. Estas aplicaciones residen el servidor de
aplicaciones del SMD.
B.2.1 Servidor
Esta aplicación acepta las conexiones de los clientes y "decide" si se autoriza o no la
transacción. Permite la concurrencia de un número configurable de usuarios (actualmente 20), y
deriva las solicitudes a otra aplicación denominada procesador. El proceso de autorización lo
realiza mediante la validación del nombre de usuario y contraseña enviados en forma codificada
desde el cliente, con la información correspondiente que existe en la base de datos central.
75
B.2.2 Procesador
El procesador es el encargado de efectuar los procedimientos necesarios para la sincronización
de la base de datos central con los nuevos datos aportados por los usuarios, así como la
consulta de información a la base de datos central y su derivación hacia los usuarios que la
soliciten. Es posible activar varias instancias del procesador, lo que permite el procesamiento
paralelo de las solicitudes.
B.3 Cliente del SMD
Esta aplicación permite el acceso de cada usuario al sistema de mapeo digital, a través de su
nombre de usuario y contraseña. Una vez iniciada una sesión es posible solicitar un elemento
mapeable para su edición o, simplemente, para su visualización. Así mismo es posible obtener
los vectores e imágenes que estén disponibles en la base de datos central.
B.4 Mapeador
Esta aplicación contiene toda la gráfica del SMD y es la que permite el despliegue de los
elementos mapeables, tanto mapas como sondajes.
B.4.1 Mapeador de Sondajes
Provee las interfaces y módulos para el mapeo de sondajes. Además, permite a los usuarios
exportar la información de los sondajes seleccionados hacia archivos ASCII o Excel. Así mismo,
es posible imprimir los sondajes en una impresora o plotter, agregando cierta información
administrativa como encabezado de cada hoja.
B.4.2 Mapeador de Mapas
Esta aplicación contiene la gráfica más compleja del SMD. Permite desplegar tanto plantas
como secciones y dibujar sobre ellos cualquier nuevo soporte. Esto último se puede hacer
directamente o con la ayuda de una serie de asistentes que facilitan la creación de nuevas
figuras.
Además, es posible conectar un GPS a computador portátil (puerto serial) y desplegar la lectura
obtenida directamente sobre el mapa que está siendo desplegado. Esto posibilita la ubicación
instantánea de la posición actual en el mapa de trabajo.
