Universidad de San Carlos de Guatemala

Facultad de Ingeniería
Escuela de Ingeniería en Ciencias y Sistemas

ADMINISTRACIÓN E INTEGRACIÓN DE UNA GEODATABASE

CON SISTEMAS DE INFORMACIÓN GEOGRÁFICA

Ana Cecilia Bolaños Véliz

Asesorado por el Ing. Jorge Armín Mazariegos

Guatemala, abril de 2011

 UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERÍA

ADMINISTRACIÓN E INTEGRACIÓN DE UNA GEODATABASE

CON SISTEMAS DE INFORMACIÓN GEOGRÁFICA

TRABAJO DE GRADUACIÓN

PRESENTADO A LA JUNTA DIRECTIVA DE LA

FACULTAD DE INGENIERÍA
POR

ANA CECILIA BOLAÑOS VÉLIZ

ASESORADO POR EL ING. JORGE ARMÍN MAZARIEGOS

AL CONFERÍRSELE EL TÍTULO DE

INGENIERA EN CIENCIAS Y SISTEMAS

GUATEMALA, ABRIL DE 2011

 UNIVERSIDAD DE SAN CARLOS DE GUATEMALA
FACULTAD DE INGENIERÍA

NÓMINA DE JUNTA DIRECTIVA

DECANO Ing. Murphy Olympo Paiz Recinos

VOCAL I Ing. Alfredo Enrique Beber Aceituno
VOCAL II Ing. Pedro Antonio Aguilar Polanco
VOCAL III Ing. Miguel Ángel Dávila Calderón
VOCAL IV Br. Luis Pedro Ortiz de León
VOCAL V P.A. José Alfredo Ortiz Herincx
SECRETARIO Ing. Hugo Humberto Rivera Pérez

TRIBUNAL QUE PRACTICÓ EL EXAMEN GENERAL PRIVADO

DECANO Ing. Murphy Olympo Paiz Recinos

EXAMINADOR Ing. Marlon Antonio Pérez Turk
EXAMINADORA Inga. Floriza Felipa Ávila Pesquera
EXAMINADORA Inga. Sonia Yolanda Castañeda
SECRETARIA Inga. Marcia Ivónne Véliz Vargas
 HONORABLE TRIBUNAL EXAMINADOR

En cumplimiento con los preceptos que establece la ley de la Universidad de

San Carlos de Guatemala, presento a su consideración mi trabajo de
graduación titulado:

ADMINISTRACIÓN E INTEGRACIÓN DE UNA GEODATABASE

CON SISTEMAS DE INFORMACIÓN GEOGRÁFICA

Tema que me fuera asignado por la Dirección de la Escuela de Ingeniería en

Ciencias y Sistemas, en agosto de 2009.

Ana Cecilia Bolaños Véliz

 AGRADECIMIENTOS A:

La USAC y Facultad Por ser mi segundo hogar, en donde alimenté

de Ingeniería mis conocimientos para aprovecharlos durante
mi vida.

El Programa Agua Por darme la oportunidad de aportar los

Fuente de Paz Y conocimientos para el bien de las instituciones.
SEGEPLAN

Mi madre Victoria Véliz Aguilar de Bolaños, por los

innumerables sacrificios, que gracias a ellos, el
día de hoy se ven los frutos reflejados.

Mi padre César Augusto Bolaños (q.e.p.d), aunque no

esté presente le dedico esta etapa de mi vida
profesional.

La ingeniera Vilma Por su ayuda invaluable, sus palabras de apoyo

Judith Muralles Aché y sus consejos que sirvieron para completar
esta fase de estudios, así como para un futuro
profesional.

Mi familia y amigos Por darme su apoyo incondicional.

 ÍNDICE GENERAL

ÍNDICE DE ILUSTRACIONES ........................................................................... V

GLOSARIO ....................................................................................................... IX
RESUMEN ........................................................................................................ XI
OBJETIVOS .................................................................................................... XIII
INTRODUCCIÓN ............................................................................................. XV

1. MARCO TEÓRICO ................................................................................... 1

1.1. Sistemas de información geográfica ............................................ 1
1.1.1. Concepto de punto...................................................... 2
1.1.2. Concepto de línea ....................................................... 2
1.1.3. Concepto de polígono ................................................. 2
1.2. Base de datos geográfica ............................................................ 3
1.2.1. Concepto de datos espaciales .................................... 3
1.2.2. Concepto de datos no espaciales ............................... 3
1.3. Tipos de datos espaciales en MySQL ......................................... 4
1.3.1. Concepto de well-known text (WKT) ........................... 4
1.3.2. Concepto de well-known binary (WKB)....................... 4
1.3.3. Tipos datos espaciales simples
(objetos únicos)........................................................... 4
1.3.4. Tipos de datos espaciales soportan
conjuntos de objetos ................................................... 5
1.4. Archivo Shape ............................................................................. 5
1.4.1. Archivo principal: * .shp .............................................. 5
1.4.2. Archivo de índice: *.shx. ............................................. 6
1.4.3. Archivo de base de datos: *. dbf ................................. 6

I
 1.4.4. Archivo de proyección: *. prj ....................................... 6
1.5. Extensible Markup Language (XML) ........................................... 6
1.6. Keyhole Markup Language (KML) ............................................... 7
1.7. Regiones y departamentos que conforman la
República de Guatemala ............................................................. 7
1.7.1. Región I o Metropolitana ............................................ 7
1.7.2. Región II o Norte ........................................................ 7
1.7.3. Región III o Nororiental ............................................... 8
1.7.4. Region IV o Suroriental .............................................. 8
1.7.5. Región V o Central ..................................................... 8
1.7.6. Región VI o Suroccidental .......................................... 8
1.7.7. Región VII o Noroccidental ......................................... 9
1.7.8. Región VIII o Petén .................................................... 9
 

2. FASE TÉCNICO-PROFESIONAL .......................................................... 11

2.1. Instituciones involucradas en el proyecto .................................. 11
2.1.1. Secretaría de Coordinación Ejecutiva
de la Presidencia (SCEP) ......................................... 11
2.1.2. Fondo Nacional Para la Paz (FONAPAZ) ................. 11
2.1.3. Instituto de Fomento Municipal (INFOM) .................. 12
2.2. Descripción del proyecto ........................................................... 12
2.2.1. Determinación de requerimientos ............................. 12
2.2.2. Principales procedimientos realizados
durante el proyecto ................................................... 16
2.3. Presentación de la solución al proyecto .................................... 18
2.3.1. Posibles soluciones analizadas ................................ 18
[Link]. ArcSDE .................................................... 18
[Link]. Código Abierto Kosmo ............................. 19
[Link]. Programación en Java ............................. 20

II
 [Link]. Convertidores de datos: kml2shp,
shp2kml, kml2xml
y shp2xml ................................................. 20
[Link]. Componentes kml2shp y shp2kml ........... 21
2.3.2. Problemas solucionados durante
el desarrollo .............................................................. 21
[Link]. Requerimiento de archivo prj ................... 21
[Link]. Nombres largos........................................ 22
2.4. Diseño ....................................................................................... 23
2.4.1. Modelo de entidad relación ....................................... 23
2.4.2. Modelo entidad relación transformado
a un modelo de base de datos
Geográfica ................................................................ 24
2.4.3. Herramienta shp2mysql ............................................ 25
2.4.4. Avances de la creación de ESRI shapes .................. 27
2.4.5. Problemas con los municipios de
Livingston y El Estor ................................................. 31
2.5. Productos finales del SIG: ArcGIS ............................................. 37
2.5.1. Compresión de ESRI shapes a
formato zip ................................................................ 38
2.5.2. Avances de creación de KML y KMZ ........................ 41
 

3. TRABAJO REALIZADO EN LA SECRETARÍA DE

PLANIFICACIÓN Y PROGRAMACIÓN DE LA
PRESIDENCIA ....................................................................................... 53
3.1. Conexión del servidor de Agua Fuente De Paz
con Kosmo Versión 2.0.............................................................. 53
3.2. Conexión del servidor de Agua Fuente de Paz
con gvSIG 1.1.1 ......................................................................... 63

III
 3.3. Conexión de GeoServer 2.0.1 con el servidor
Agua Fuente de Paz.................................................................. 66
3.4. Costos del proyecto................................................................... 74
3.5. Beneficios del proyecto ............................................................. 77
3.5.1. Recursos monetarios................................................ 77
3.5.2. Capital humano ........................................................ 77
3.5.3. Optimización de tiempo ............................................ 78
3.5.4. Satisfacción del Gobierno......................................... 78
3.5.5. Reducción del estrés ................................................ 79
3.5.6. Reducción de errores ............................................... 79
3.5.7. Uso libre o GNU ....................................................... 79
3.5.8. Comunicación entre procesos .................................. 79
3.5.9. Comunicación con SEGEPLAN ................................ 79
CONCLUSIONES ............................................................................................. 81
RECOMENDACIONES..................................................................................... 83
BIBLIOGRAFÍA ................................................................................................. 85
ANEXO ............................................................................................................. 87

IV
 ÍNDICE DE ILUSTRACIONES
 

FIGURAS

1. Antecedentes del proyecto....................................................................... 16

2. Solución para el proyecto......................................................................... 17
3. Configuraciones en SEGEPLAN .............................................................. 18
4. Sistema de referencia desconocido ......................................................... 22
5. Diagrama entidad relación de base de datos relacional........................... 24
6. Diagrama entidad relación de base de datos geográfica ......................... 25
7. Línea de comandos de shp2mysql .......................................................... 26
8. Representación de los 3 tipos de capas geográficas ............................... 28
9. Capa de departamentos con errores geográficos .................................... 29
10. Capa de municipios con errores geográficos. ......................................... 30
11. Capa de departamentos utilizando una restricción SQL ......................... 31
12. Capa de municipios con coordenadas incorrectas. ................................. 32
13. Acercamiento del municipio de El Estor .................................................. 33
14. Acercamiento del municipio de Livingston .............................................. 34
15. Alejamiento de la capa geográfica de Municipios ................................... 35
16. Capa de municipios con coordenadas corregidas................................... 36
17. Atributos no espaciales ........................................................................... 37
18. Capa de departamentos en ArcMap ...................................................... 37
19. Capa de municipios en ArcMap .............................................................. 38
20. Error al comprimir ESRI shape en formato zip ........................................ 39
21. Estadística de la cantidad de coordenadas............................................. 40
22. Filtro para consultas por medio de Xajax ................................................ 41

V
23. Capa de regiones en KML con errores de Coordenadas......................... 42
24. Capa de departamentos en KML con atributos no espaciales................. 43
25. Capa de comunidades en KML con atributos no espaciales ................... 44
26. Capa de regiones en KML, con atributos no espaciales y
errores en coordenadas. ......................................................................... 45
27. Capa de departamentos en KML, con atributos no espaciales
y errores en coordenadas ....................................................................... 45
28. Capa de municipios en KML con escala pequeña ................................... 46
29. Capa de municipios en KML .................................................................... 47
30. Capa de municipios en KML con atributos no espaciales........................ 47
31. Capa geográfica de departamentos y municipios .................................... 48
32. Capa geográfica con Google Maps ......................................................... 49
33. Capa geográfica de un KML con Google Maps, con una página
intermedia de conexión ........................................................................... 50
34. Capa de región dentro del servidor de Agua Fuente de Paz. .................. 51
35. Capa de departamento del servidor de Agua Fuente de Paz .................. 51
36. Capa de municipio del servidor de Agua Fuente de Paz ......................... 52
37. Capa de comunidades del servidor de Agua Fuente de Paz ................... 52
38. Representa el sistema de referencia WSG 1984 ..................................... 54
39. Cadena de conexión para el servidor de Agua Fuente de Paz ................ 55
40. Restricción del servidor para conexiones remotas. ................................. 56
41. Cadena de conexión con el servidor y tablas de la
base de datos ......................................................................................... 57
42. Representación de la selección del tipo de capa geográfica. .................. 58
43. Trazado erróneo de la capa por una inserción incorrecta
de una tupla ............................................................................................ 59
44. Capa de regiones y atributos con Kosmo 2.0. ......................................... 60
45. Capa de departamentos con Kosmo 2.0. ................................................ 60
46. Capa de municipios con Kosmo 2.0. ....................................................... 61

VI
47. Capa de comunidades con Kosmo 2.0. .................................................. 62
48. Capa de departamentos y comunidades con Kosmo 2.0. ....................... 62
49. Añadir una capa en gvSIG ...................................................................... 63
50. Conexión del servidor de Agua Fuente de Paz con gvSIG ..................... 65
51. Selección del mapa que se graficará ...................................................... 65
52. Capa de regiones con gvSIG y el servidor de Agua Fuente de Paz. ...... 66
53. Espacio de trabajo en GeoServer ........................................................... 67
54. Orígenes de datos en GeoServer ........................................................... 68
55. Conexión de GeoServer con el Servidor Agua Fuente de Paz. .............. 70
56. Previsualización de capas con GeoServer.............................................. 71
57. Capa de comunidades con atributos no espaciales en GeoServer......... 72
58. Capa de departamentos en GeoServer. ................................................. 72
59. Capa de departamentos con atributos no espaciales en GeoServer ...... 73
60. Capa de municipios con atributos espaciales en GeoServer .................. 74

TABLAS

I. Costos del proyecto de EPS: integración con una geodatabase. ........................... 75

VII
VIII
 GLOSARIO

Latitud Localización entre el polo norte y el polo sur, medida como

un ángulo entre el punto y el plano del ecuador.

Longitud Distancia angular entre un punto de la superficie terrestre y

un meridiano.

Leyenda Interpretación que se debe aplicar a los símbolos, códigos,

fecha, datum, fuente precisión, escala, entre otros.

Línea Objeto definido por una sucesión de puntos.

Mapa Esquema que representa los rasgos y características

naturales o artificiales de una superficie.

Mapa Mapa que representa las características pertenecientes a

temático una variable específica.

Password Serie de caracteres, pueden ser letras, números o símbolos

especiales, el cual es propio de un usuario para ingresar a
un programa en particular, al cual tiene permitido el acceso.

Proyección Transformación matemática que nos permite representar

en un plano otra superficie no plana.

IX
Punto Objeto de dimensiones nulas que representa un conjunto
de coordenadas.

Región Área que representa una característica en común. Conjunto

de polígonos.

Símbolo Representación gráfica de una entidad geográfica.

Sistema Sistema de referencia para localizar y representar un punto

coordenado en un espacio.

Sistema de Conjunto integrado por equipo de cómputo, programas,

información recursos humanos y procedimientos para capturar,
geográfica: manejar, manipular, analizar y representar información
geográfica, con el objetivo de ayudar en la toma de
decisiones.

Tupla Es un registro que conforma una tabla de una base de

datos.

UTM Proyección denominada Universal Transversa de Mercator.

Las magnitudes se representan en metros a nivel del mar.

X
 RESUMEN

Como primera fase del Ejercicio Profesional Supervisado, se identificó la

necesidad de intercomunicar diferentes aplicaciones para la entrega de
resultados propios del programa. Los requerimientos de los usuarios se
concentran en unificar los productos de software utilizados periódicamente.
Cada día se ofrece una variedad de productos de diferentes compañías y con
diferentes protocolos, y presentan un inconveniente a los usuarios que están
obligados a realizar procesos repetitivos y redundantes para comunicar su
información en diferentes aplicaciones. Es por ello que en el programa Agua
Fuente de Paz era preciso establecer una solución para transformar la base de
datos relacional en una base de datos geográfica. Fue necesario identificar,
analizar y ejecutar un medio de comunicación entre el servidor de la base de
datos geográfica con herramientas de Sistemas de Información Geográfica:
Paquete de ArcGIS, Google Map y Google Earth.

Para comunicar la base de datos geográfica con los SIG, se realizó una
página web con lenguaje PHP, en el cual se realizan consultas en lenguaje de
consulta estructurado y ésta retorna archivos propios de cada herramienta SIG.

Como segunda fase del proyecto, se configuraron los servidores de la

Secretaría de Planificación y Programación de la Presidencia y el servidor del
programa Agua Fuente de Paz, para que existiera comunicación entre ellos. El
objetivo principal, era publicar las capas geográficas del programa por medio de
archivos shapes dentro de Infraestructura de Datos Espaciales de
SEGEPLAN, en la cual participan varias instituciones gubernamentales
representando las capas geográficas del área de estudio.

XI
XII
 OBJETIVOS

General

Identificar, asesorar, diseñar y ejecutar la transformación de una base de

datos relacional a una base de datos geográfica, para convertirla en un
componente de un sistema de información geográfica, con el objetivo de
automatizar los procesos de creación y visualización de capas geográficas del
programa Agua Fuente de Paz.

Específicos

1. Implementar un mecanismo de comunicación entre la base de datos

geográfica del programa Agua Fuente de Paz y con el paquete de
ArcGIS para el mejoramiento en la creación de capas geográficas y
solucionar las inconsistencias en los datos.

2. Desarrollar una aplicación para generar capas geográficas que sean

visualizadas en Google Maps y Google Earth para reforzar la entrega de
capas geográficas de la institución.

3. Configurar los servidores de la Secretaría de Planificación y

Programación de la Presidencia para la comunicación con el Programa
Agua Fuente de Paz y con el paquete de ArcGIS para centralizar la
información y facilitar la visualización de las capas geográficas

XIII
XIV
 INTRODUCCIÓN

Optimizar las horas de trabajo, es de vital importancia para cualquier

empresa. La mayoría de puestos empresariales requieren reportes detallados
de resultados cada cierto período de tiempo y cuando la creación de estos es
compleja y repetitiva, tiene como resultado una reducción en la productividad
por parte de los responsables de dichos informes de capas geográficas. Es por
ello que se planteó la necesidad de una solución informática para integrar una
base de datos geográfica con un sistema de información geográfica.

En el presente trabajo de graduación, se detalla y define el proceso para

llegar a la solución del problema de generar capas geográficas semanales. Se
encuentra la descripción del proceso de transformación de un ESRI shape a un
archivo con sentencias en lenguaje de consulta estructurado, para su respectiva
inserción en el servidor. Seguidamente, se explica el proceso para la creación
de los ESRI shape, KML y KMZ.

Por otra parte, se puntualiza acerca del mecanismo de conexión entre el

servidor del programa Agua Fuente de Paz y los sistemas: ArcGIS, Google
Maps y Google Earth.

Para finalizar, se describe el progreso de las configuraciones realizadas

para establecer los enlaces entre el servidor del programa Agua Fuente de Paz
y las siguientes aplicaciones: Kosmo, GeoServer, gvSIG.

XV
 1. MARCO TEÓRICO

1.1. Sistemas de información geográfica

Es un sistema que reúne componentes de programas, equipo de cómputo,

talento humano e información para el análisis, administración y obtención de
resultados, para resolver problemas de carácter geográfico.

Se realizan modelos basados en datos del mundo real, debe poseer un

sistema de referencia, con el objetivo de resolver interrogantes propias de la
base de datos.

Los Sistemas de Información Geográfica tienen como objetivo presentar

los datos en mapas o capas geográficas, para crear informes o bien realizar
pronósticos apoyándose en las herramientas propias del software.

En un Sistema de Información Geográfica se unen los datos, atributos o

datos no espaciales con los datos geográficos, con el fin de reflejarlo
visualmente para el usuario, por medio de un mapa.

Un Sistema de Información Geográfica utiliza tres componentes básicos

para representar los datos geográficos: puntos, líneas y polígonos.

1
 1.1.1. Concepto de punto

Es el componente más sencillo. Puede representar elementos simples

como un teléfono, un poste, un monumento, un punto específico para identificar
una ciudad, etc.

Un punto es adimensional y se conforma únicamente de las coordenadas

“X” y “Y” que lo ubican de manera espacial (x,y) o (x,y,z).

1.1.2. Concepto de línea

Una línea se define como una secuencia de puntos, permite representar una
secuencia o trazo, como por ejemplo: calles, líneas telefónicas, drenajes, un río, etc.

Una línea requiere por lo menos dos puntos { (X,Y)1, .... , (X,Y)N} o {(X,Y,Z)1, ....
, (X,Y,Z)N}. Al obtener las coordenadas se puede calcular la longitud de la línea y el
sentido de la línea.

1.1.3. Concepto de polígono

Un polígono consiste en un área o un conjunto de líneas que forman una

región cerrada. Con un área o polígono se puede graficar lagunas, parcelas,
fincas, etcétera. El punto final debe ser igual al punto inicial, para cerrar el
polígono.

Un polígono debe contener al menos una línea { (L1), ..... ,(LN)} o bien
puede ser una sucesión de puntos, en la cual el primer y el último punto son
iguales. {(X,Y)1 ,(X,Y)2,.(X,Y) 3, ..,(X,Y)1} {(X,Y,Z)1 ,(X,Y,Z)2,.(X,Y,Z) 3,
..,(X,Y,Z)1}, es la restricción para que origine una zona cerrada. Con estos
datos se puede conseguir el área y el perímetro de dicho polígono.

2
1.2. Base de datos geográfica

Una base de datos, como su nombre lo indica, es un conjunto de datos

que tienen relación entre ellos, ya que son de un tema concreto. Estos datos
son transformados en información útil.

Ahora bien, una base de datos geográfica, también almacena columnas de

tipo geométrico, es decir, posee coordenadas y proyecciones que sirven de
base y son aceptados en Sistemas de Información Geográfica.

Una base de datos geográfica contiene dos elementos primordiales:

- Atributos o datos espaciales

- Atributos o datos no espaciales

1.2.1. Concepto de datos espaciales

Son los campos que almacenan los datos geográficos, tienen relación con
los demás objetos. Almacenan cada punto que conforman un polígono, líneas,
etc.

1.2.2. Concepto de datos no espaciales

Son las columnas o características que describen, califican, cuantifican al

objeto que formará el mapa. En la base de datos son los campos que
almacenan el nombre del accidente geográfico, tamaño, abreviatura, etc.

3
1.3. Tipos de datos espaciales en MySQL

Existen dos formatos de datos espaciales soportados por MySQL, los

cuales son utilizados con Structure Query Language (SQL):

• Well-known text (WKT)

• Well-known binary (WKB)

1.3.1. Concepto de well-known text (WKT)

La manera de detallar una geometría es en ASCII. Por ejemplo si se

especifica un elemento punto se haría: point(3 4).

1.3.2. Concepto de well-known binary (WKB)

Utiliza cadenas con datos binarios para describir la información de una

geometría. Se usan enteros sin signo de un byte, enteros sin signo de cuatro
bytes, y números de ocho bytes de doble precisión.

Un punto en código ASCII se define de la siguiente forma point (1 1) y en

hexadecimal se representaría de la siguiente forma:
0101000000000000000000F03F000000000000F03F.

1.3.3. Tipos datos espaciales simples (objetos únicos):

Point: almacena punto

Linestring: almacena una cadena de puntos, es decir una línea.

Polygon: almacena un polígono o área.

4
 1.3.4. Tipos de datos espaciales soportan conjuntos de
objetos

Multipoint: almacena un conjunto de puntos.

Multilinestring: almacena una colección de objetos del tipo LineString.

Multipolygon: almacena una colección de polígonos o áreas.

Geometrycollection: almacena objetos geométricos de cualquier tipo.

Geometry: almacena valores de cualquier tipo.

1.4. Archivo shape

Un archivo shp o shape, es un formato de vector creado por

Environmental System Research Institute (E.S.R.I.). Este conjunto de archivos
soporta las geometrías punto, línea, multilínea, polígono, multipolígono.

Un archivo shp puede tener información únicamente de un tipo

geométrico.

Este formato ESRI shape, se forma basado en los siguientes tres

archivos:

1.4.1. Archivo principal: * .shp

Contiene los datos geográficos, que servirán de lectura en el software.

5
 1.4.2. Archivo de índice: *.shx.

Crea índices para relacionar los datos no espaciales con los datos
espaciales, une los registros del archivo shp con el dbf.

1.4.3. Archivo de base de datos: *. dbf

Almacena los registros con la información no espacial de cada tupla o fila

que conformará los atributos de la capa.

1.4.4. Archivo de proyección: *. prj

Es un archivo de texto, que optimiza la apertura de los ESRI shapes, ya

que en él se almacena el tipo de proyección, latitud, longitud, grados, etc.

1.5. Extensible Markup Language (XML)

Traducido como “Lenguaje de Marcas Extensible”. Es un metalenguaje de

etiquetas creado por el World Wide Web Consortium (W3C).

No es un lenguaje propiamente dicho, ya que su función es definir la

gramática de otros lenguajes más específicos. Definir lenguajes para diferentes
necesidades. Su objetivo es permitir la compatibilidad entre sistemas para
compartir la información de una manera segura, fiable y fácil.

6
1.6. Keyhole Markup Language (KML)

Es un lenguaje de marcado basado en XML. Con este tipo de archivo se

pueden representar datos geográficos en tres dimensiones. Fue implementado
por la compañía Keyhole LT, que seguidamente fue adquirido por (hasta en la
actualidad) ofrece Google Earth.

Los archivos KML a menudo suelen distribuirse comprimidos como

archivos KMZ.

Básicamente, un archivo KML contiene una característica, puede ser un

lugar, una imagen o un polígono. Además, se puede incluir otros datos
relevantes como título, una descripción básica del lugar, descripciones y alguna
otra información.

1.7. Regiones y departamentos que conforman la República de

Guatemala

1.7.1. Región I o Metropolitana

Guatemala

1.7.2. Región II o Norte

Alta Verapaz
Baja Verapaz

7
 1.7.3. Región III o Nororiental

Chiquimula
El Progreso
Izabal
Zacapa

1.7.4. Region IV o Suroriental

Jalapa
Jutiapa
Santa Rosa

1.7.5. Región V o Central

Chimaltenango
Escuintla
Sacatepéquez

1.7.6. Región VI o Suroccidental

Retalhuleu
San Marcos
Sololá
Suchitepéquez
Totonicapán
Quetzaltenango

8
 1.7.7. Región VII o Noroccidental

Huehuetenango
El Quiché

1.7.8. Región VIII o Petén

Petén

9
10
 2. FASE TÉCNICO-PROFESIONAL

2.1. Instituciones involucradas en el proyecto

2.1.1. Secretaría de Coordinación Ejecutiva de la Presidencia

(SCEP)

Es la institución, junto con el Presidente de la República, encargada de

las siguientes funciones:

• Coordinar el Sistema Nacional de Consejos de Desarrollo Urbano y Rural,

y el Sistema de Consejos Regionales y Departamentales.

• Colaborar con la formulación de políticas de desarrollo urbano y rural.

• Brindar seguimiento para el cumplimiento de proyectos de mayor

prioridad para el Presidente de la República.

2.1.2. Fondo Nacional Para la Paz (FONAPAZ)

Es la institución encargada de los siguientes programas:

• Construcción de viviendas y hogares comunitarios rurales, edificios del

Estado, salones comunales y canchas polideportivas, centros escolares y
su equipo.

11
• Creación y ejecución de programas educacionales y recreacionales;
láminas, accesorios y materiales para la construcción de viviendas del
área rural; ayuda alimentaria; apoyo de proyectos de paz.

2.1.3. Instituto de Fomento Municipal (INFOM)

Esta institución tiene a su cargo los siguientes programas:

• Asistencia crediticia a las municipalidades.

• Asistencia técnica y administrativa.

• Caminos rurales.

• Saneamiento del medio.

2.2. Descripción del proyecto

2.2.1. Determinación de requerimientos

La Secretaría de Coordinación Ejecutiva de la Presidencia (SCEP), El

Fondo Nacional Para la Paz (FONAPAZ) y el Instituto de Fomento Municipal
(INFOM), son los encargados de recolectar y clasificar la información de los
índices semanales correspondientes. Cada institución tiene una persona
encargada de tabular dichos datos y enviarlos vía correo electrónico, en un día
específico a la persona autorizada en el proyecto Agua Fuente de Paz. Se
prevé que más instituciones formarán parte de este proyecto, así como existirán
nuevos usuarios o autoridades que podrán ingresar datos.

12
 Con la información obtenida por las instituciones encargadas, en el
proyecto Agua Fuente de Paz se encargan de trasladar dichos datos a un
sistema de información geográfica (SIG), para seguidamente efectuar las
respectivas capas geográficas con datos relevantes respectivos.
Simultáneamente, con dicha base de datos se producen reportes mensuales
más específicos, estadísticas, gráficas, proyecciones, etc.

La base de datos relacional geográfica tiene comunicación con las tres

propuestas iniciales de software de Sistemas de Información Geográfica:
ArcGIS, Web Map Service WMS para MapBender, productos de Google:
Google Earth y Google Map.

Como trabajo adicional, se realizó la conexión con su futuro servidor de

mapas Geoserver, la institución SEGEPLAN hará uso de este software, en un
proyecto que tienen contemplado en un futuro no lejano.

La automatización del proceso del traslado de información del servidor

hacia el conjunto de archivos ESRI shape generados por medio de PHP, son
utilizados en un Sistema de Información Geográfica para la generación de las
capas geográficas. Dicho procedimiento se realiza semanalmente, el cual, al
hacerlo en la manera en que se procesa actualmente, y que consiste en una
serie de pasos de conversión para transformar los datos en información útil,
derrocha recursos de equipo de cómputo y de programas, recursos monetarios
y lo más importante: consume el valioso tiempo de los colaboradores de la
institución.

Por lo descrito anteriormente, se realizó la entrega de una herramienta

que cumpla con los requerimientos óptimos de un sistema de información en un
entorno web, que brinde un apoyo a la elaboración de capas geográficas del

13
programa Agua Fuente de Paz, y consiguiente, que el proceso de obtención de
datos sea de una forma eficiente y eficaz.

Este Ejercicio Profesional Supervisado se realizó con el fin de solucionar

una problemática a nivel nacional, primordialmente en instituciones que no
cuentan con el presupuesto para subsidiar una necesidad de relevancia para el
país. Para la Secretaría Técnica del Gabinete Específico del Agua, es de vital
importancia la visualización de los proyectos que tienen en cada municipio de
Guatemala, para evaluar el avance progresivo semanalmente, y por
consiguiente, tener una visión para la toma de decisiones de las acciones a
seguir para el cumplimiento de las metas y objetivos de dicha institución.

La persona encargada es el Licenciado en Geografía y Antropología,

Didier Devers, que gran parte de su trabajo consiste en qué cada vez que
realiza un informe por medio de capas geográficas debe realizar los siguientes
pasos:

• Valida que cada comunidad este con su código INE correspondiente.

• Valida que los nombres de las comunidades y municipios estén

correctamente escritos. El problema radica en que no todas las
instituciones gubernamentales tienen con el mismo nombre a la
comunidad o municipio, es decir, el mismo territorio tiene diferente nombre
en una o más instituciones.

• Corrige la problemática de los nombres similares. Algunos lugares

poblados tienen similitud en el nombre, lo que confunde al personal que
ingresa la información, e intercambian los datos de cada comunidad.

14
• Tomar en cuenta en la recolección de estadísticas, que existen
comunidades que tienen diferente código INE en cada institución.

• Verificar que la comunidad esté asociada con su respectivo municipio.

Aquí es donde se origina el conflicto de tierras. En innumerables casos, la
comunidad está registrada en un municipio, pero geográficamente
pertenece a otro municipio; esto produce que ninguna municipalidad
quiera hacerse responsable de las necesidades de sus pobladores. Las
comunidades aparecen fuera de los límites del municipio al que
teóricamente pertenecen.

• Rectificar que las comunidades estén dentro del territorio de la República

de Guatemala. Hay comunidades guatemaltecas, que están
representadas geográficamente en territorio de México, El Salvador,
Honduras y Belice.

• Los lugares poblados tienen diferente prioridad en cada institución. La

clasificación de prioridades no se realiza bajo los mismos parámetros de
necesidades.

• Investigar y corregir la posición geográfica de lugares poblados, ya que

debido a una incorrecta medición de coordenadas, existen comunidades
que se encuentran ubicadas en áreas marítimas, Océano Atlántico y
Pacífico, ríos, lagos, etc.

15
 Figura 1. Antecedentes del proyecto

Fuente: elaboración propia

2.2.2. Principales procedimientos realizados durante el

proyecto

1. Convertir los archivos ESRI shape a sentencias SQL para generar las
tablas geométricas en una base de datos MySQL.

2. Desarrollo de la aplicación para generación de los archivos ESRI shape y

KML, obteniendo la información desde la base de datos.

3. El sistema realiza una consulta a la base de datos de MySQL, en la cual

obtienen campos con atributos espaciales y no espaciales.

4. Al resultado de la consulta, la cual puede contener restricciones y

proyecciones, se ingresa como parámetro a un método que se encarga de
dividir los campos necesarios para generar los archivos ESRI shapes. Por

16
 medio del lenguaje PHP se manipula el campo geométrico para interpretar
cada punto como un componente del atributo punto, línea o polígono.

Figura 2. Solución para el proyecto

 

Fuente: elaboración propia

5. Conversión de los archivos en formato zip, para su descarga.

6. Si la generación de la capa fue en formato KML, la aplicación permite la

opción de descargarlo en formato KMZ o bien de visualizarlo en tiempo de
compilación en Google Maps.

7. Configuraciones del servidor de SEGEPLAN, para que se autorizara la

comunicación con el servidor de Agua Fuente de Paz.

17
 Figura 3. Configuraciones en SEGEPLAN

Fuente: elaboración propia

Al intercomunicarse, permite la visualización de los mapas creados por los

profesionales de Agua Fuente de Paz y que dichos mapas se encuentren
acoplados en el servidor de SEGEPLAN, para que sean de utilidad a los
usuarios porque en este servidor se encuentran publicados diferentes capas
geográficas de diferentes instituciones y se actualizan periódicamente.

2.3. Presentación de la solución al proyecto

2.3.1. Posibles soluciones analizadas

[Link]. ArcSDE

Es un componente de ArcGIS, que permite la comunicación con una base

de datos relacionales y administración de la información geográfica. Tiene la
restricción que permite únicamente la conexión con los sistemas de gestión de

18
bases de datos o DBMS: IBM DB2, Informix, servidor de Microsoft SQL y
Oracle.

ArcSDE proporciona los datos a los productos de escritorio ArcView,

ArcEditor y ArcInfo.

Permite la administración de una geodatabase, en la cual varios usuarios

pueden editar la información, administrar diferentes tipos de usuarios con sus
respectivos privilegios, realizar consultas SQL a diferentes tablas y registros,
etc. En resumen, posee las mismas características que en una base de datos
relacional.

Es recomendable utilizar un DBMS para almacenar datos geográficos,

para que estos sean perdurables, tengan integridad y consistencia. Cabe
resaltar que al utilizar una base de datos, los usuarios tendrán la información
actualizada en cada momento. Con los shapes se puede perder información y
no todos los usuarios tienen los mismos datos.

Esta opción quedó descartada, debido a que el programa Agua Fuente de

Paz tiene como manejador de base de datos MySQL, que en la actualidad no lo
soporta ArcSDE.

[Link]. Código Abierto Kosmo

Es una herramienta o software SIG Código Abierto, bajo licencia

GNU/GPL. Creado por la empresa SAIG. Realiza análisis de información
territorial recogiendo sus datos a partir de una geodatabase.

19
 Esta propuesta fue desechada, debido a la inversión ya realizada para la
licencia de ArcGIS. ArcGIS posee un sinnúmero de extensiones para realizar
análisis estadísticos, proyecciones, análisis geográficos, pronósticos, mapeos,
geoprocesamientos, etc. Es una herramienta poderosa para los datos
geográficos.

Kosmo tiene sus bondades en cuanto al análisis geográfico, sin embargo,

existe una gran brecha en funcionalidad hacia el software de paquetes de
ArcGIS.

[Link]. Programación en Java

Existen paquetes de creación de ESRI shapes, realizando consultas a una

base de datos. El servidor del programa Agua Fuente de Paz no permite hacer
conexiones remotas por reglamentos de seguridad.

El servidor sólo provee soporte para el lenguaje PHP.

[Link]. Convertidores de datos: kml2shp, shp2kml,

kml2xml y shp2xml

Algunas de las herramientas que se evaluaron tenían errores, otras que se

examinaron sólo era permitido usarlas en período de prueba, es decir, son
versión trial, era necesario comprar las licencias de dichas aplicaciones.

Otras aplicaciones no fueron realizadas por instituciones o profesionales

confiables, poseían virus o spyware dentro de sus ejecutables.

20
 Se consiguió una página web para realizar conversiones de archivos. Pero
se detectaron los siguientes problemas:

-Depender del servicio de Internet y a la vez de una página que es

probable que deje de funcionar en cierto tiempo.

-No se tiene un respaldo profesional.

-La conversión de datos es lenta y tenía límite de carga de archivos.

[Link]. Componentes kml2shp y shp2kml

Componente propio de ArcGIS, es necesario comprar la licencia. La

inversión era de Q.3,200.00. Se seguía con el problema de obtener información
de la base de datos, ya que era necesario crear el archivo ESRI shape o el KML
con los procesos actuales y luego efectuar la conversión.

2.3.2. Problemas solucionados durante el desarrollo

[Link]. Requerimiento de Archivo PRJ

En la figura cuatro se visualiza el mensaje de aviso, el cual indica que falta

el archivo prj, en él se indica el sistema de proyección. Este error surgía al abrir
los archivos ESRI shape con ArcGIS. Al dar clic en el botón OK, graficaba el
mapa con sus respectivos atributos.

21
 Figura 4. Sistema de referencia desconocido

Fuente: elaboración propia

Se detectó que era necesario crear un archivo de texto con extensión prj,
con la siguiente información:

GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS
_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0
.0174532925199433]]

[Link]. Nombres largos

El nombre de los campos del ESRI shape debe tener como máximo 10
caracteres. El encabezado de dbf da errores cuando el campo tiene nombres
muy largos, por lo cual no crea el ESRI shape.

22
2.4. Diseño

Inicialmente se proporcionó el diseño de la base de datos relacional, al

cual se le realizaron las transformaciones propias para convertirlo en un
diagrama entidad relación de una base de datos geográfica.

2.4.1. Modelo de entidad relación

En el diagrama entidad relación inicial, existía una entidad llamada

GEO_Coordenada, la cual tenía como propósito almacenar la información
referente a los datos espaciales, es decir, las coordenadas de las regiones,
departamentos, municipios y comunidades.

En la figura 5, se encuentra el diagrama entidad relación el cual no

manejaba correctamente el atributo espacial. Con esta entidad se enlazarían
los campos geométricos junto con los datos no espaciales.

23
 Figura 5. Diagrama entidad relación de base de datos relacional

Fuente: elaboración propia

2.4.2. Modelo entidad relación transformado a un modelo de

base de datos geográfica

Con la investigación y posterior análisis, se determinó que la entidad

GEO_Coordenada era innecesaria, ya que MySQL maneja un tipo de dato
espacial de tipo Geometry, dicho tipo de dato almacena información de datos
espaciales tipo punto, línea y polígono.

En la figura 6, se detalla la parte geométrica en cada entidad. Por medio

del nuevo campo geométrico permite la creación de las capas geográficas.

24
 Figura 6. Diagrama entidad relación de base de datos geográfica

Fuente: elaboración propia

2.4.3. Herramienta shp2mysql

Es una herramienta para transformar los archivos ESRI shape en una

entidad. Genera un script basados en los datos del archivo, las salidas son
instrucciones SQL y crea una nueva tabla con sus respectivas inserciones, para
luego ser almacenados a una base de datos geográfica. En la figura 7 se
representa una secuencia de comandos para la herramienta shp2mysql.

25
 Figura 7. Línea de comandos de shp2mysql

Fuente: elaboración propia

 

Sintaxis:

shp2mysql [<options>] <shapefile> <tablename> <database name>

shp2mysql departamentos departamentos_table eps1 >[Link]

Donde:

Departamentos es el archivo ESRI shape.

Departamentos_table es el nombre de la tabla que se creará en la base de

datos.

Eps1 es el nombre de la base de datos que almacenará las tablas.

[Link] es el nombre del archivo de órdenes SQL.

26
 Opciones:

-s Ingresa el campo SRID, que representa el tipo de proyección que se

está utilizando en la entidad. En caso que no se especifique, el valor
predefinido es -1.

2.4.4. Avances de la creación de ESRI shapes

Para obtener la creación de ESRI shapes se utilizó la librería Código

Abierto en código PHP llamada [Link], en ella se crean las gráficas de
las capas por medio de graficar punto por punto para cada registro.

La librería soporta los tres tipos de datos espaciales: línea, punto y

polígono.

Debido a que dicha librería no adjuntaba ninguna documentación, era

complicado determinar el funcionamiento para la creación de los shapes. El
primer avance fue la creación de ESRI shape de tipo punto, seguidamente se
crearon los de tipo espacial de línea, y por último, los datos de tipo polígono.
Estos archivos contenían datos fijos, es decir, que se ingresaron manualmente
en un arreglo unidimensional cada punto que formaría la línea o polígono.

27
 Figura 8. Representación de los tres tipos de capas geográficas

Fuente: elaboración propia

El siguiente hito del proyecto fue la creación de los tres tipos de ESRI
shape tomando la información espacial y no espacial de las entidades de datos
de MySQL. Se realizó la codificación, siempre en el lenguaje de programación
php, para la conexión a la base de datos, obtener la información, transformar
los atributos y convertirlos a tipo de datos espaciales y no espaciales.

Se realizó una división del campo geométrico para obtener cada

coordenada de latitud y longitud y transformarla en un punto que formaría
posteriormente la gráfica de la línea o el polígono.

En la codificación de la división de las variables latitud y longitud de cada

punto, existía un problema al generar los departamentos, esto sucedía cuando
existía una división de polígonos, aparecía el símbolo de separación “)),((”, por
lo cual no se generaba correctamente.

28
 Figura 9. Capa de departamentos con errores geográficos
 

Fuente: elaboración propia

 

Como se observa, también existían problemas en la generación del mapa

de municipios, esto sucede porque existen municipios que lo conforman dos o
más polígonos. Dicha especificación ocurre en el campo Geometry, el cual
divide los polígonos por medio de paréntesis, lo que ocasionaba que la división
de los puntos no se realizara de forma correcta y completa.

29
 Figura 10. Capa de municipios con errores geográficos
 

Fuente: elaboración propia

En el ejemplo de la figura 11 se realizó una restricción de SQL, los

archivos ESRI shape son generados con las tuplas que cumplen los requisitos
solicitados por el usuario. Es por ello que no aparecen los departamentos que
no cumplían con la condición indicada.

30
 Figura 11. Capa de departamentos utilizando una restricción SQL

Fuente: elaboración propia

2.4.5. Problemas con los municipios de Livingston y El Estor

Otro de los inconvenientes, sucedía en el caso que existieran municipios,

departamentos o regiones, que al realizar la consulta no devolviera ninguna
tupla de resultado, es decir, existían polígonos sin información espacial. Al
consultarlo con el experto, se determinó que aunque no tuviera valores, siempre
debería aparecer el mapa completo, para una mejor comprensión de los
usuarios o personas interesadas en los reportes.

El municipio de Livingston se conforma por dos polígonos, divididos por un

río.

31
 Figura 12. Capa de municipios con coordenadas incorrectas

Fuente: elaboración propia

En la figura 13 se realizó un acercamiento en el municipio de El Estor y

se determinó que en el archivo ESRI shape existía una línea errónea que
unificaba ambos polígonos.

32
 Figura 13. Acercamiento del municipio de El Estor
 

Fuente: elaboración propia

En la figura 14 se muestra un acercamiento en el municipio de Livingston

y se determinó que en el archivo ESRI shape contenía el campo geográfico con
un solo polígono, cuando lo correcto es que dicho municipio se conforma por
dos polígonos separados.

33
 Figura 14. Acercamiento del municipio de Livingston

Fuente: elaboración propia

La figura 15 muestra un alejamiento de la capa geográfica para observar

el mapa en su totalidad, al realizar este procedimiento se determinó que en el
polígono existían coordenadas escritas en forma inversa, por lo cual los puntos
se ubicaban del otro lado del hemisferio terrestre.

34
 Figura 15. Alejamiento de la capa geográfica de municipios

Fuente: elaboración propia

La figura 16 muestra el archivo ESRI shape con todas las correcciones

realizadas para cada municipio.

35
 Figura 16. Capa de municipios con coordenadas corregidas

Fuente: elaboración propia

Entre las funciones de ArcGIS-ArcMap, se encuentra la opción de ver los

valores o datos no espaciales que conforman las capas geográficas. Se
observan todos los campos de cada tupla. Cabe resaltar, que existe una
columna llamada shape, en ella almacena las coordenadas de los polígonos, el
cual no es visible al usuario. También, automáticamente aparece el campo FID,
que consiste en una columna autoincrementable propia del programa.

36
 Figura 17. Atributos no espaciales

Fuente: elaboración propia

2.5. Productos finales del SIG: ArcGIS

Como producto final, se entregó la capa geográfica conformada por los 22

departamentos de la República de Guatemala.

Figura 18. Capa de departamentos en ArcMap

 

Fuente: elaboración propia

37
 En la figura 19 se observa la capa de municipios con los campos
geográficos corregidos.
 
Figura 19. Capa de municipios en ArcMap

Fuente: elaboración propia

2.5.1. Compresión de ESRI shapes a formato zip

Para agilizar el proceso de descarga, se unieron los diferentes formatos de

archivos shapes: dbf, shp, shx y prj, en una carpeta con el nombre de la sesión
del usuario. Por medio de la librería [Link], bajo licencia Código Abierto y en
lenguaje php, la carpeta que contiene los archivos fue comprimida en formato
zip.
Debido a que la ventana de apertura o descarga de archivos debía
hacerse en forma automática, surgía como error que se mostraba el contenido
del archivo. Por estar en formato zip se observaban caracteres propios de la
compresión del archivo.

38
 Dicho problema se solucionó al agregar en el código las funciones
ob_start() y ob_end_flush(), con ellas se realiza una limpieza y a la vez
almacenamiento del buffer .

Figura 20. Error al comprimir ESRI shape en formato zip

Fuente: elaboración propia

Se realizó como valor agregado, una pequeña aplicación que realiza un

conteo de la cantidad de puntos que forman cada polígono.

39
 Figura 21. Estadística de la cantidad de coordenadas
 

Fuente: elaboración propia

Se propuso realizar una aplicación para filtrar las consultas a través de

Xajax para el lenguaje de programación PHP, en la cual se seleccionaba la
región, departamento, municipio y comunidad con la cual se generaría el
informe.

40
 Figura 22. Filtro para consultas por medio de Xajax

Fuente: elaboración propia

2.5.2. Avances de creación de KML y KMZ

Existe un tipo de dato llamado multipolígono, en cada registro puede

contener uno o más polígonos. Por ejemplo, un departamento o estado puede
formarse por dos islas y un polígono rodeado por más polígonos.

En algunas regiones se incluye el polígono de uno o más lagos, al crear el

archivo KML, no se diferenciaban los dos polígonos, por el contrario, lo tomaba
como un solo polígono y trazaba una línea no existente entre el último punto del
primer polígono y el primer punto del segundo polígono.

41
 Figura 23. Capa de regiones en KML con errores de coordenadas

Fuente: elaboración propia

Visualización de capa geográfica de tipo polígono. Se reflejan campos

obtenidos de una subconsulta de la base de datos. La razón de que algunos
departamentos no se graficaron, fue porque en la consulta se restringió a que
se visualizarán únicamente los que tenían información.

42
 Figura 24. Capa de departamentos en KML con atributos no espaciales
 

Fuente: elaboración propia

Al dar clic en las capas, en este caso comunidades, aparece un recuadro

con la información de la consulta correspondiente a esa comunidad en
específico. Igual sucede con las capas geográficas de regiones, departamentos
y municipios.

43
 Figura 25. Capa de comunidades en KML con atributos no espaciales

Fuente: elaboración propia

 

 
Al igual que en la creación de los archivos ESRI shape, al generar los
archivos KML también se producían los errores en la creación de los campos
geométricos conformados por dos o más polígonos. En la figura 26 se visualiza
una línea que une los dos polígonos, la cual no debería existir.

44
 Figura 26. Capa de regiones en KML, con atributos no espaciales y
errores en coordenadas

Fuente: elaboración propia

Figura 27. Capa de departamentos en KML, con atributos no

espaciales y errores en coordenadas

Fuente: elaboración propia

 

45
 Si se reduce la escala del mapa, se puede analizar que las coordenadas
son incorrectas. Las coordenadas se alejan del territorio de la República de
Guatemala.

Figura 28. Capa de municipios en KML con escala pequeña

 
Fuente: elaboración propia

Se corrigió la lectura de las coordenadas para generar el nuevo archivo

KML que divide correctamente los polígonos que conforman los municipios,
departamentos, etc.

46
 Figura 29. Capa de municipios en KML

Fuente: elaboración propia

 

En la figura 30 se puede observar uno de los resultados finales, se generó

la capa de municipios y al seleccionar uno de ellos, se muestra una ventana
flotante que contiene los atributos no espaciales correspondientes al municipio
seleccionado.

Figura 30. Capa de municipios en KML con atributos no espaciales

Fuente: elaboración propia

47
 En el programa de Google Earth por medio del archivo en formato KML se
muestran dos capas geográficas al unísono, se demuestra la capa de
departamentos y la capa de comunidades.

Figura 31. Capa geográfica de departamentos y comunidades

Fuente: elaboración propia

 
 
Google Maps tiene la particularidad que puede conectarse a servidores y
acceder a los archivos en formato KML que se encuentren alojados en el
espacio destinado a publicar las capas geográficas.

48
 Figura 32. Capa geográfica con Google Maps

Fuente: elaboración propia

 
 
Existen sitios web que permiten cargar los archivos en formato KML para
su visualización, pero al realizar dicho procedimiento se restringía a publicar los
archivos en otro servidor ajeno a la institución. Por ello, se solicitó una llave
privada para hacer publicaciones desde el servidor del programa Agua Fuente
de Paz.

49
 Figura 33. Capa geográfica de un KML con Google Maps, con una
página intermedia de conexión

Fuente: elaboración propia

Se alojaron los archivos a publicar dentro del servidor del programa Agua
Fuente de Paz y con ello se logró realizar una conexión con Google Maps, para
mostrar las capas geográficas para el acceso de todo público. La visualización
de las capas se realiza por medio de un enlace.

50
 Figura 34. Capa de región dentro del servidor de Agua Fuente de Paz

Fuente: elaboración propia

 
 
 
Figura 35. Capa de departamento del servidor de Agua Fuente de Paz

Fuente: elaboración propia

51
 Figura 36. Capa de municipio del servidor de Agua Fuente de Paz
 

Fuente: elaboración propia

Figura 37. Capa de comunidades del servidor de Agua Fuente de Paz

 

Fuente: elaboración propia

52
 3. TRABAJO REALIZADO EN LA SECRETARÍA DE
PLANIFICACIÓN Y PROGRAMACIÓN
DE LA PRESIDENCIA

3.1. Conexión del servidor de Agua Fuente De Paz con Kosmo

Versión 2.0

Para utilizar el programa de Kosmo, es necesario indicar el Sistema de

Referencia Espacial, es decir, el sistema de proyección que está definido en las
capas.

Existen dos grupos que contienen los diferentes tipos de proyecciones:

EPSGG: son las iniciales de European Petroleum Survey Group.

IAU2000: correspondiente a la lista de proyecciones de International

Astronomical Union.

El sistema de proyección WSG 1984, se identifica con el código 4326. La

base de datos almacena las coordenadas con este sistema geográfico.

53
 Figura 38. Representa el sistema de referencia WSG 1984

Fuente: elaboración propia

Kosmo 2.0 permite la conexión con servidores que manejen extensiones

espaciales, y éstos se enumeran a continuación:

• PostGIS
• Oracle Spatial
• MySQL

Variables necesarias para la conexión:

Nombre del servidor: se ingresa el nombre del dominio de la institución, en

este caso corresponde: [Link]

54
 Puerto: se genera automáticamente al seleccionar el tipo de base de
datos.

Para MySQL corresponde el número de puerto 3306. Si por alguna norma

de seguridad el número de puerto es diferente al indicado, está permitido
modificarlo.

Nombre de la base de datos: ingresamos el nombre de la base de datos

específica con la cual se establecerá la conexión.

Usuario: se ingresa el nombre del usuario que ha sido autorizado para

conectar al servidor.

Contraseña: se ingresa la cadena de caracteres de tipo confidencial.

Figura 39. Cadena de conexión para el servidor de Agua Fuente de Paz

Fuente: elaboración propia

55
 Para que Kosmo complete la conexión y tome como válidos los
parámetros necesarios, es necesario ingresar las direcciones IP en la
configuración del servidor para que no restrinja el acceso remoto y que permita
la conexión.

Figura 40. Restricción del servidor para conexiones remotas

Fuente: elaboración propia

Un inconveniente presentado al completar el enlace con el servidor era

que debía retornar todas las tablas a las cuales el usuario tiene permitido el
acceso. Sin embargo, no se visualizaba, lo cual era ineficiente en el caso que
no fuera necesario transformar todas las tablas que tienen datos de tipo
Geometry en capas geométricas. Se corrigió con realizar la conexión
nuevamente y ya aparece la lista de las tablas de la base de datos.

56
 Figura 41. Cadena de conexión con el servidor y tablas de la base de
datos

Fuente: elaboración propia

Luego de las verificaciones propias del programa, no era posible

determinar qué tipo de geometría (punto, línea o polígono) corresponde a las
tablas seleccionadas. Por ello, se requería que se ingresara manualmente el
tipo de geometría al que correspondía la capa geográfica.

Se detectó que no estaba completo el campo geométrico de una tupla de

la tabla GEO_Regiones, por lo cual se actualizó y se corrigió el problema con
insertar correctamente la lista de coordenadas.

57
 Figura 42. Representación de la selección del tipo de capa geográfica

Fuente: elaboración propia

Como consecuencia de haber ingresado incorrectamente una tupla, el

programa Kosmo no logro completar el trazado de la capa, y realizaba el
trazado del mapa de Guatemala incompleto.

58
 Figura 43. Trazado erróneo de la capa por una inserción incorrecta de
una tupla

Fuente: elaboración propia

 
Los siguientes mapas obtienen su información directamente de la base de
datos geográfica alojada en el servidor del programa Agua Fuente de Paz.

En la figura 44 se muestra la entidad de regiones luego de haber realizado

las correcciones en las tuplas con coordenadas incorrectas. Se observa que
están trazados todos los polígonos y además se listan sus atributos no
espaciales.

59
 Figura 44. Capa de regiones y atributos con Kosmo 2.0

Fuente: elaboración propia

 
En la figura 45 se observa seleccionada la capa de departamentos, en la
cual se observa que los polígonos se encuentran formados completamente.

Figura 45. Capa de departamentos con Kosmo 2.0

Fuente: elaboración propia

60
 La figura 46 muestra por medio del programa Kosmo y con la conexión
del servidor de base de datos, se genera la capa de municipios, sin los
inconvenientes de los municipios formados por dos o más polígonos.

Figura 46. Capa de municipios con Kosmo 2.0

Fuente: elaboración propia

 
La tabla de comunidades lo forma el atributo de tipo punto, el cual se
conforma por latitud y longitud, por lo cual la capa geográfica también se
presenta de tipo punto.
 

61
 Figura 47. Capa de comunidades con Kosmo 2.0

 
Fuente: elaboración propia
 
 
Figura 48. Capa de departamentos y comunidades con Kosmo 2.0

Fuente: elaboración propia

 
 
 

62
3.2. Conexión del servidor de Agua Fuente de Paz con gvSIG 1.1.1

Al iniciar a gvSIG, se presenta una ventana para administrar los proyectos.

Se abrirá una nueva ventana del gestor de capas geográficas y añadimos una
capa.

Figura 49. Añadir una capa en gvSIG

Fuente: elaboración propia

Para realizar el enlace con el servidor de Agua Fuente de Paz, se ingresó

a la opción de “Parámetros de la conexión” y se incluyeron los siguientes datos:

Para la conexión, existen las siguientes opciones de manejadores de base

de datos.

63
 Entre las opciones disponibles están:

• PostGIS JDBC Driver

• HSQLDB Driver
• MySQL JDBC Driver

Como el servidor de la institución posee como manejador de bases de

datos MySQL, seleccionamos esta opción.

Nombre del servidor: se ingresa el nombre del dominio de la institución, en

este caso corresponde: [Link]

Puerto: se genera automáticamente al seleccionar el tipo de base de

datos.

Para MySQL corresponde el número de puerto 3306. Si por alguna norma

de seguridad el número de puerto es diferente al indicado, está permitido
modificarlo.

Nombre de la base de datos: ingresamos el nombre de la base de datos

específica con la cual se establecerá la conexión.

Usuario: se anota el nombre del usuario que ha sido autorizado para

ingresar al servidor.

Contraseña: se ingresa la cadena de caracteres de tipo confidencial.

64
 Figura 50. Conexión del servidor de Agua Fuente de Paz con gvSIG

Fuente: elaboración propia

Otro paso importante en la configuración consistió en elegir las tablas que

era necesario reflejar en el programa, se definieron las columnas de las tablas,
el tipo de proyección, el campo que correspondía a la llave primaria y el campo
que contenía las coordenadas. Como campo opcional, se puede determinar el
campo de visualización del mapa.

Figura 51. Selección del mapa que se graficará

Fuente: elaboración propia

65
 En la figura 52 se observa la conexión con gvSIG y el servidor, los datos
se obtienen de la base de datos geográfica. El programa reconoce el tipo de
capa y lo transforma en la representación de una capa geográfica.
 
Figura 52. Capa de regiones con gvSIG y el servidor de Agua Fuente de
Paz

Fuente: elaboración propia

3.3. Conexión de GeoServer 2.0.1 con el servidor Agua Fuente de Paz

Para utilizar GeoServer, es necesario ingresar a un navegador web de

nuestra elección e ingresamos la dirección [Link]
Tomar en cuenta, que, si cambia el puerto 8080, debe sustituirlo en dicha
dirección.

66
 Como las configuraciones mencionadas anteriormente, se ingresaron los
datos propios de la conexión. Adicionalmente, GeoServer solicita el número de
conexiones simultáneas mínimas y máximas que soportará el servidor, el
tiempo de respuesta del servidor, etc.

Como primer paso, de preferencia se debe crear un espacio para

englobar los mapas de la institución. En la nueva página se encuentran los
espacios de trabajo ya disponibles. Considerar que un espacio de trabajo se
utiliza para una mejor administración de los mapas a publicar.

Figura 53. Espacio de trabajo en GeoServer

Fuente: elaboración propia

En la sección de orígenes de datos vectoriales se instaló un complemento

de la herramienta, para que aceptara los dispositivos de conexión con el
Manejador de base de datos MySQL.
67
 Figura 54. Orígenes de datos en GeoServer

Fuente: elaboración propia

Ahora, se ingresan los datos que nos solicita para establecer la conexión.

Espacio de trabajo: seleccionar si se creó un nuevo espacio de trabajo o

uno de los ya definidos (ya establecidos).

Nombre del origen de datos: cadena de caracteres que identifique el

almacén de datos o la conexión:

Description: una breve descripción de la conexión. Ésta es opcional.

Dbtype: tipo de la base de datos.

Host: dirección URL del servidor, a la cual se conectan.

Port: se genera automáticamente al seleccionar el tipo de base de datos.

68
 Para MySQL corresponde el número de puerto 3306. Si por alguna norma
de seguridad el número de puerto es diferente al indicado, está permitido
modificarlo.

Database: se ingresa el nombre de la base de datos específica con la cual

se establecerá la conexión.

User: se ingresa el nombre del usuario que ha sido autorizado para

ingresar al servidor.

Password: se ingresa la cadena de caracteres de tipo confidencial.

Max connection: tiene definido como 10 conexiones máximas al servidor.

Min connection: tiene definido como una conexión mínima al servidor.

Connection timeout: tiempo máximo de respuesta del servidor:

Validate connections: habilitar checklist para que valide las conexiones:

Primary key metadata table: campo opcional, indica la llave primaria de la

tabla.

Storage engine: Tipo MyISAM.

69
 Figura 55. Conexión de GeoServer con el servidor Agua Fuente de Paz

Fuente: elaboración propia

En la sección de Previsualización de capas, se enumeran las conexiones

propias del servidor de Agua Fuente de Paz. Adicionalmente, se reflejan
algunos ejemplos propios del programa.

70
 Figura 56. Previsualización de capas con GeoServer

Fuente: elaboración propia

A continuación se muestran los resultados de los mapas que serán

publicados:

En la figura 57, se visualiza la capa de comunidades (tipo punto) y en el

cual se puede seleccionar una comunidad y automáticamente aparecen los
atributos no espaciales correspondientes a la comunidad seleccionada, en la
parte inferior de la capa.
 

71
 Figura 57. Capa de comunidades con atributos no espaciales en
GeoServer

Fuente: elaboración propia

La capa de departamentos se grafica correctamente desde GeoServer,

esto se ejemplifica en la figura 58.

Figura 58. Capa de departamentos en GeoServer

 
Fuente: elaboración propia

72
 Al realizar un acercamiento a la capa geográfica, se observan mayores
detalles y de igual forma aparecen los atributos no espaciales como el nombre
del departamento, código, etc. En la figura 59 se observa el acercamiento en
los departamentos de Alta Verapaz y Baja Verapaz.
 
 
Figura 59. Capa de departamentos con atributos no espaciales en
GeoServer

Fuente: elaboración propia

En la figura 60 se obtuvo como resultado la capa de municipios con sus

respectivos atributos no espaciales.

73
 Figura 60. Capa de municipios con atributos
no espaciales en GeoServer

Fuente: elaboración propia

3.4. Costos del proyecto

A continuación se presenta la tabla I, en la cual se realiza una proyección

de los costos para la ejecución del proyecto.

74
 Tabla I. Costos del proyecto de EPS: integración
con una geodatabase
 
RUBROS COSTO MENSUAL 6 MESES
UNITARIO

Impuesto al valor Q - Q -
agregado
Impuesto sobre la renta Q - Q -
De edificios y viviendas Q. 500.00 Q. 500.00 Q. 3,000.00
(Q. 1,500.00 / 3
personas)
Servicios de informática y Q. 70.00 Q. 5.600.00 Q. 33,600.00
sistemas computarizados
(4 horas diarias X 20
días)
Servicios profesionales Q. 175.00 Q. 1,750.00 Q. 10,500.00
de asesor (10 horas
mensuales)
Servicios profesionales Q. 30.00 Q. 600.00 Q. 3,600.00
de contabilidad (1 hora
diaria X 20 días)
* Servicios básicos
Energía eléctrica Q. 100.00 Q. 600.00
(Q.300.00 / 3 personas)
Agua (Q.120.00 / 3 Q. 40.00 Q. 240.00
personas)
Telefonía (Q.600.00 / 3 Q. 200.00 Q. 1,200.00
personas)

75
Continuación de tabla de costos del proyecto de EPS: integración con una
geodatabase

Publicidad y propaganda Q. 500.00 Q. 3,000.00

Impresión, Q. 500.00 Q. 3,000.00
encuadernación y
reproducción
Viáticos en el interior Q. 25.00 Q. 500.00 Q. 3,000.00
Transporte de personas Q. 30.00 Q. 600.00 Q. 3,600.00
Mantenimiento y Q. 300.00 Q. 1,800.00
reparación de equipo de
oficina
Mantenimiento y Q. 200.00 Q. 1,200.00
reparación de equipo de
cómputo
Alimentos para personas Q 100.00 Q. 600.00
Papel de escritorio Q. 10.00 Q. 250.00 Q. 1,500.00
Libros, revistas y Q. 15.00 Q. 375.00 Q. 2,250.00
periódicos
Útiles de oficina Q. 5.00 Q. 125.00 Q. 750.00
Útiles de limpieza y Q. 5.00 Q. 125.00 Q. 750.00
productos sanitarios
Subtotal Q. 74,190.00
Gastos no previstos (3%) Q. 2,225.70
TOTAL A INVERTIR Q. 76,415.70

Fuente: elaboración propia

 

76
3.5. Beneficios del proyecto

3.5.1. Recursos monetarios

El programa Agua Fuente de Paz realizó una considerable inversión en la

compra del servicio de hosting, que es un servidor remoto que permite el
alojamiento de páginas web y diferentes funcionalidades para Internet y de
licencias para utilizar programas de ArcGIS. Se consiguió una reducción de
costos, ya que las librerías que se implementaron son Código Abierto.

La inversión para adquirir la extensión de ArcSDE se aproxima a los

Q. 96,000.00 al año, además, se requiere de licencias para el servidor y los
clientes. En conclusión, el costo por implementar extensiones o complementos
propias de ArcGIS es oneroso.

3.5.2. Capital humano

La recopilación y verificación de los datos que conformarían cada mapa, el

Licenciado Devers los crea en el término de siete días y siempre tenía que
realizar todos los pasos de verificación y corrección.

Por el contrario, luego de implementar la solución que se presentó como

idónea para las necesidades de la institución, se debe solicitar al encargado de
la base de datos, que ejecute una consulta a la base de datos, con las
restricciones y proyecciones que necesita en ese momento. Únicamente
depende del tiempo de respuesta del servidor para resolver la consulta SQL y el
tiempo en que se tarda la librería en generar los ESRI shapes y KML.

77
 Debido a los atrasos en la entrega de las capas geográficas, era necesario
la contratación de más personal, que implicaba un desembolso extraordinario
del presupuesto asignado al Programa.

El tiempo que el Licenciado Devers invertía en realizar procesos

repetitivos y complicados, puede emplearlo en optimizar los geoprocesos más
precisos y sofisticados para la obtención de pronósticos reales y proponer
soluciones mejor detalladas y basados en antecedentes de información
geográfica estandarizada.

3.5.3. Optimización de tiempo

Realizar una solicitud monetaria para adquirir nuevas licencias,

representaba estar a la espera durante unos meses para tener la resolución de
aprobación o de negación. El proceso implica inclusive licitaciones, para lo cual
es necesario invertir unos meses más para tomar la decisión.

3.5.4. Satisfacción del Gobierno

Las autoridades responsables de velar por las actividades que se realizan

de incorporación de agua potable y saneamiento, podrán ingresar al servidor de
mapas de SEGEPLAN y podrán observar las capas en conjunto de diferentes
instituciones.

78
 3.5.5. Reducción del estrés

Las personas encargadas de reunir la información organizada por

comunidades para formar las capas, no se verán afectadas psicológicamente, al
tener que organizar grandes archivos con los reportes semanales.

3.5.6. Reducción de errores

Se minimiza el riesgo de cometer errores humanos, como resultado de

grandes cantidades de registros. Al unificar los reportes de las otras
instituciones involucradas, para formar el reporte propio del programa, se
pueden borrar, modificar, intercalar los datos o utilizar reportes antiguos o que
no corresponden a la institución que se requiere analizar.

3.5.7. Uso libre o GNU

Puede ser utilizado por otras organizaciones que presenten la misma

problemática de tecnología, asimismo de recursos financieros.

3.5.8. Comunicación entre procesos

Se integró la base de datos con los Sistemas de Información Geográfica:

ArcGIS, Google Earth y Google Maps.

3.5.9. Comunicación con SEGEPLAN

Las configuraciones realizadas en el servidor de SEGEPLAN, tendrá

comunicación con el programa Agua Fuente de Paz. Dicho enlace será
aprovechado para unificar y reflejar las capas geográficas de la institución.

79
80
 CONCLUSIONES

1. Se produjo una aplicación con el lenguaje de programación PHP, que

realiza consultas SQL a la base de datos, dicha información sirve de
base para la creación de las capas geográficas en una forma
automatizada y personalizada, generando ESRI shapes necesarios para
el conjunto de programas de ArcGIS.

2. Se elaboró un sitio web para la creación, descarga y visualización de

capas geográficas en formato KML y KMZ, las cuales son extensiones
propias de Google Maps y Google Earth, para que sean consultados vía
online.

3. En la Secretaría de Planificación y Programación de la Presidencia se

realizaron configuraciones de servidores con la tecnología de GeoServer,
que permiten la comunicación con la base de datos con el servidor del
programa Agua Fuente de Paz y se visualizan las capas geográficas
periódicas.

81
82
 RECOMENDACIONES

1. Combinar programas con licencia y programas libres, para fortalece los

procesos de negocios de distintas actividades laborales en las
organizaciones, instituciones, etc.

2. Utilizar bases de datos que proporcione integridad, consistencia,

seguridad, disponibilidad entre otras características. Eliminar la
utilización de los archivos como fuente de datos, para contrarrestar los
problemas de inconsistencia de datos.

3. Dar mantenimiento a las aplicaciones para actualizar nuevos

requerimientos y que éstas no se conviertan en obsoletas.

4. Crear tablas que contengan las tuplas frecuentes que conforman las
capas geográficas para reducir las consultas a la base de datos, así
como la reducción de creación de vistas. Optimizar las consultas por
medio de tuning para que éstas no consuman los recursos del servidor.

5. Adquirir las licencias para la extensión de ArcSDE para tener conexión

directa con la base de datos y disminuir la utilización de terceras
aplicaciones.

6. Revisar periódicamente las configuraciones realizadas en el servidor de

Geoserver y proporcionar el respectivo mantenimiento, como la
habilitación de puertos, habilitación de direcciones de confianza, ejecutar
actualizaciones, continuidad a las normas de seguridad.

83
7. Proponer a las instituciones correspondientes que estandaricen los
códigos correspondientes a departamentos, municipio y comunidades,
para evitar duplicidad y errores.

8. Unificar en lo posible a las instituciones gubernamentales, para que

reflejen sus resultados por medio de capas geográficas, en un único
servidor de mapas para facilitar las consultas a los usuarios involucrados
en el proyecto.

9. Dar servicio de mantenimiento al equipo de cómputo con personal

calificado y se sugiere realizarlo cada tres meses.

10. Capacitar frecuentemente al personal involucrado según un programa de

estudios adecuado a los requerimientos de la institución.

84
 BIBLIOGRAFÍA

1. Andrew Perencsik, Simon. Building a Geodatabase, 1999.

2. Booth, Bob. Building a Geodatabases Tutorial, 2006.

3. Bordignon Fernando. Blog: apuntes, son solo apuntes [En línea]. Marzo
de 2011. Disponible en Web:
<[Link]

4. Conceptos básicos y ArcSDE [En línea]. Marzo de 2011. Disponible en

Web:
<[Link]
[Link]>.

5. Environmental System Research Institute, Inc. ESRI Shapefile Technical

Description, Estados Unidos de América, 1998.

6. Environmental System Research Institute, Inc. ¿Qué es ArcGIS?,

Estados Unidos de América, 2002.

7. Extensible Markup Language (XML) [En línea]. Marzo de 2011.

Disponible en Web:
<[Link]

85
8. Geography Markup Language (GML) [En línea]. Marzo de 2011.
Disponible en Web:
<[Link]

9. Keyhole Markup Language (KML) [En línea]. Marzo de 2011. Disponible

en Web: <[Link]

10. Programa Agua Fuente De Paz [En línea]. Marzo de 2011. Disponible
en Web: <[Link]

11. Proyecto GCP. Manual Curso Análisis Espacial ArcView 8.2, Santiago de
Chile, Mayo de 2003.

12. Proyecto GCP. Trabajando con ArcCatalog, 2008.

13. Saig. Sistemas abiertos de información geográfica, Kosmo-Desktop,

2006.

14. Santiago, Iván. Fundamentos de ArcGIS, Puerto Rico, Noviembre de

2005.

15. Scott Crosier, Bob. Getting Started With ArcGIS, 1999.

86
 ANEXO

Bitácora de actividades
 
Julio de 2009

FECHA ACTIVIDAD

13/julio/2009 Reunión inicial en SEGEPLAN 10:00 a 12:00

14/julio/2009 Reunión de explicación de funcionamiento de organizaciones

17:00-19:00

15/julio/2009 Investigación de SIG Google Earth

16/julio/2009 Investigación de Georeferencial

17/julio/2009 Reunión de explicación de modelos entidad relación

18:00-20:00

20/julio/2009 Reunión de explicación de funcionamiento de procesos en

Casa Presidencial

2:30-4:30

21/julio/2009 Investigación de Georeferencial y SIG

87
Continuación de bitácora de julio

22/julio/2009 Capacitación “Uso y manejo del Sistema Nacional de

Información Territorial SINIT”

Laboratorio de Sistemas de Información Geográfica –SIG

Tercer Nivel, Edificio T-9

Facultad de Agronomía

USAC, zona 12

9:00-17:30

23/julio/2009 Reunión en SEGEPLAN

Entrega de disco

Explicación de Georeferencial

9:30-11:30

24/julio/2009 Instalación de ArcGIS

25/julio/2009 Reunión explicación EPS

Edificio T-3

Facultad de Ingeniería

USAC, zona 12

27/julio/2009 Investigación de extensiones espaciales.

88
Continuación de bitácora de julio

28/julio/2009 Preparación de cartas y creación de perfil solicitados por EPS

29/julio/2009 Preparación de cartas y creación de perfil solicitados por EPS

30/julio/2009 Preparación de cartas y creación de perfil solicitados por EPS

31/julio/2009 Preparación de cartas y creación de perfil solicitados por EPS

Agosto de 2009

FECHA ACTIVIDAD

03/agosto/2009 Entrega de perfil y cartas de aprobación

04/agosto/2009 Pruebas con ArcGIS Desktop

05/agosto/2009 Pruebas con ArcGIS Desktop

06/agosto/2009 Conferencia Centroamericana de Usuarios ESRI 2009

07/agosto/2009 Conferencia Centroamericana de Usuarios ESRI 2009

10/agosto/2009 Generación de kml por medio de Java

11/agosto/2009 Generación de kml por medio de Java

12/agosto/2009 Reunión con el Ing. Rodolfo Calvo

13/agosto/2009 Investigación de librerías para convertir xml a ESRI shape.

14/agosto/2009 Investigación de librerías para convertir kml a ESRI shape.

17/agosto/2009 Investigación de librerías para convertir kml a ESRI shape.

89
Continuación de bitácora de agosto

18/agosto/2009 Reunión con el equipo de trabajo

19/agosto/2009 Trámite de constancias de cierre de plan de estudios

20/agosto/2009 Presentación de anteproyecto

21/agosto/2009 Presentación de anteproyecto

24/agosto/2009 Trámite de entrega de cartas en EPS

25/agosto/2009 Búsqueda de librerías para crear ESRI shape con php

26/agosto/2009 Comprensión de librería bfShapeFiles-0.0.2

Conversión de archivos ESRI shape a tablas de MySQL

27/agosto/2009 Conexión de base de datos

28/agosto/2009 Creación de ESRI Shape de tipo polígono

31/agosto/2009 Creación de ESRI Shape de tipo punto

Septiembre de 2009

FECHA ACTIVIDAD

01/septiembre/2009 Trámite en EPS para recoger carta de incorporación, la

cual estaba errónea y resolución de dudas

02/septiembre/2009 Creación de ESRI Shape de tipo línea

03/septiembre/2009 Creación de ESRI Shape de tipo polígono

90
Continuación de bitácora de septiembre

04/septiembre/2009 Trámite en EPS para recoger carta de incorporación

07/septiembre/2009 Anteproyecto

08/septiembre/2009 Anteproyecto

09/septiembre/2009 Anteproyecto

10/septiembre/2009 Anteproyecto

11/septiembre/2009 Anteproyecto

14/septiembre/2009 Plan de contingencia

15/septiembre /2009 Plan de contingencia

16/septiembre/2009 Plan de contingencia

17/septiembre/2009 Plan de contingencia

18/septiembre/2009 Plan de contingencia

21/septiembre/2009 Plan de contingencia

22/septiembre/2009 Reunión en Casa Presidencial

23/septiembre/2009 Trámite de entrega de anteproyecto y plan de

contingencia

24/septiembre/2009 Corrección de problema de visualización de gráfico de

mapa

25/septiembre/2009 Corrección de problema de visualización de gráfico de

mapa

91
Continuación de bitácora de septiembre

28/septiembre /2009 Corrección de problema de coordenadas de polígonos

29/septiembre /2009Corrección de problema de coordenadas de polígonos

30/septiembre/2009 Reunión en Casa Presidencial

Octubre de 2009

FECHA ACTIVIDAD

01/octubre/2009 División de polígonos por medio de coordenadas cuando forman un

municipio

02/octubre/2009 División de polígonos por medio de coordenadas cuando forman un

municipio

05/octubre/2009 Creación de función que permita dividir varios polígonos cuando son
propios de una región.

06/octubre/2009 Suspensión de actividades, por trámites de posgrado

07/octubre/2009 Trámites de EPS

08/octubre/2009 Trámites de EPS

09/octubre/2009 Creación y primeros artículos con información del EPS (actividad

adicional)

12/octubre/2009 Suspensión de actividades, por trámites de posgrado

92
Noviembre de 2009

FECHA ACTIVIDAD
16/noviembre/2009 Actualizaciones del modelo Entidad-Relación.
17/noviembre/2009 Generación de kml con conexión a la base de datos.
18/noviembre/2009 Generación de kml con conexión a la base de datos.
19/noviembre/2009 Generación de links en el kml
20/noviembre/2009 Generación de links en el kml
23/noviembre/2009 Creación de cuadro de información de la consulta
asociado con las acciones del ratón.
24/noviembre/2009 Creación de cuadro de información de la consulta
asociado con las acciones del ratón.
25/noviembre/2009 Creación de cuadro de información de la consulta
asociado con las acciones del ratón.
26/noviembre/2009 Reunión con el asesor Ingeniero Rodolfo Calvo
27/noviembre/2009 Creación de sesión de usuario.
30/noviembre/2009 Asociar sesión con el archivo generado.

Diciembre de 2009

FECHA ACTIVIDAD
01/diciembre/2009 Recepción de Key de Google Maps API
02/diciembre/2009 Recepción de librería para crear zip.
03/diciembre/2009 Pruebas con Google Maps.
04/diciembre/2009 Pruebas con Google Maps.
07/diciembre/2009 Publicación de mapas en el servidor.
08/diciembre/2009 Pruebas con librería [Link]

93
Continuación de bitácora de diciembre

09/diciembre/2009 Compresión de archivos en formato zip de los archivos

generados
10/diciembre/2009 Compresión de archivos en formato zip de los archivos
generados
11/diciembre/2009 Asociar kml con Google Maps en forma automática.
14/diciembre/2009 Asociar kml con Google Maps en forma automática.
15/diciembre/2009 Conversión de kml en kmz.
16/diciembre/2009 Conversión de kml en kmz.
17/diciembre/2009 Reunión con el asesor Ingeniero Rodolfo Calvo
18/diciembre/2009 Instalación de base de datos en el servidor y creación de
acceso.
21/diciembre/2009 Conversión de kml en kmz.
22/diciembre/2009 Apertura de kmz en Google Maps.
23/diciembre/2009 Apertura de kmz en Google Maps.
24/diciembre/2009 Descanso
25/diciembre/2009 Descanso
28/diciembre/2009 Actualización de sentencias para insertar tabla regiones en
el servidor.
29/diciembre/2009 Actualización de sentencias para insertar tabla
departamento en el servidor.
30/diciembre/2009 Actualización de sentencias para insertar tabla municipio y
Ccmunidad en el servidor.
31/diciembre/2009 Descanso

94
Enero de 2010

FECHA ACTIVIDAD
01/enero/2010 Descanso
04/enero/2010 Pruebas en el servidor aguafuentedepaz.
05/enero/2010 Pruebas en el servidor aguafuentedepaz.
06/enero/2010 Instalación de herramientas para conexión con Segeplan
07/enero/2010 Instalación de herramientas para conexión con Segeplan
08/enero/2010 Pruebas de conexión al servidor con Kosmo, gvSIG, Quantum
GIS.
11/enero/2010 Conexión exitosa al servidor con Kosmo.
12/enero/2010 Conexión para SEGEPLAN
13/enero/2010 Conexión para SEGEPLAN
14/enero/2010 Conexión para SEGEPLAN
15/enero/2010 Conexión para SEGEPLAN

95