universidad francisco de paula santander

Transcripción

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
BIBLIOTECA EDUARDO COTE LAMUS
RESUMEN – TESIS DE GRADO
AUTORES: FRANCISCO JAVIER RADA NIÑO
OMAR ARGENIS DUARTE MALDONADO
FACULTAD: INGENIERIA
PLAN DE ESTUDIOS: INGENIERIA DE SISTEMAS
DIRECTOR: NELSON BELTRÁN GALVIS
TITULO DE LA TESIS: WEB PARA EL ACCESO A LA INFORMACIÓN GEOGRÁFICA
DEL DEPARTAMENTO NORTE DE SANTANDER Y LAS VARIABLES E INDICADORES
SISTEMATIZADOS POR EL PROYECTO OBSERVATORIO REGIONAL DE PAZ
RESUMEN:
Se recopiló la información cartográfica de cada municipio del departamento Norte de
Santander; clasificando la información de variables e indicadores de los tres ejes básicos
(derechos humanos, gobernabilidad y participación ciudadana, desarrollo
socioeconómico) provista por el observatorio. Se migraron los datos espaciales y no
espaciales que se encuentran en sistemas de archivo a almacenamiento persistente en
la base de datos. Así mismo, se integró la base de datos espacial con la base de datos
del proyecto Observatorio Regional de Paz (ORDICOP). Además, se desarrolló la
aplicación Web SIG, visualizando la información geográfica del departamento Norte de
Santander y las variables e indicadores sistematizados por el Observatorio Regional
Paz. Por último, se implementó el plan de pruebas, con el fin de garantizar el
cumplimiento de los requisitos planteados por ORDICOP.
CARACTERÍSTICAS:
PAGINAS: 177
PLANOS:
ILUSTRACIONES:
CD-ROM: 1
WEB PARA EL ACCESO A LA INFORMACIÓN GEOGRÁFICA DEL
DEPARTAMENTO NORTE DE SANTANDER Y LAS VARIABLES E
INDICADORES SISTEMATIZADOS POR EL PROYECTO OBSERVATORIO
REGIONAL DE PAZ
FRANCISCO JAVIER RADA NIÑO
FACULTAD DE INGENIERÍA
PLAN DE ESTUDIOS DE INGENIERÍA DE SISTEMAS
SAN JOSÉ DE CÚCUTA
2010
WEB PARA EL ACCESO A LA INFORMACIÓN GEOGRÁFICA DEL
DEPARTAMENTO NORTE DE SANTANDER Y LAS VARIABLES E
INDICADORES SISTEMATIZADOS POR EL PROYECTO OBSERVATORIO
REGIONAL DE PAZ
FRANCISCO JAVIER RADA NIÑO
Trabajo de grado presentado como requisito para optar al título de:
Ingeniero de Sistemas
Director:
NELSON BELTRÁN GALVIS
Ingeniero de Sistemas
FACULTAD DE INGENIERÍA
PLAN DE ESTUDIOS DE INGENIERÍA DE SISTEMAS
SAN JOSÉ DE CÚCUTA
2010
A mi madre, Angelina Niño Peñaranda, por darme la vida más feliz que un niño
deseara vivir.; tú eres la luz que siempre brilla en medio de todas mis confusiones,
tus oraciones siempre están conmigo, tus cuidados y tu amor me permiten seguir
creciendo y ser un hombre mejor, gracias a ti logro este merito.
A mis tías, Carmen Niño, Trinidad Niño, Margarita Niño y Rosa Niño Peñaranda,
por estar atentas de mí y no dejarme decaer.
A mis hermanas, Judith Rada y Ariela Rada, aunque estén física o mentalmente
distantes los llevo siempre en mi corazón.
A mis primos Álvaro Niño y Margarita Espejo, por su fraternidad y su apoyo y por
ser dos hermanos más.
A mi esposa, Sandra Patricia Ordoñez León, tu cariño y tu amor me han ayudado
a superar los momentos difíciles, llegaste en el momento preciso como un
designio divino para guiarme con tu consejo e inteligencia, sin ti no habría podido
alcanzar el éxito.
A mi amiga, Kelly Roció Niño, la familia no se elige los amigos si y por eso son
especiales, gracias por tu amistad y por tus concejos.
Francisco Javier
A mis padres, Luis Duarte y Mariela Maldonado, por su amor, comprensión y
respaldo además de sus esfuerzos para hacerme la persona que soy hoy en día.
A mi abuela, Carmen Vera, por brindarme todo el amor y el cuidado necesario en
mis primeros años.
A mi hermana, Liliana Duarte, por compartir conmigo momentos de alegría y
tristeza que siempre estarán en nuestros recuerdos.
A mi novia, Yesenia Diosa, por ser mi complemento y brindarme su amor, en el
transcurso de todos estos años.
Omar Argenis
AGRADECIMIENTOS
Los autores expresan sus agradecimientos a:
Doctor Víctor Bautista Olarte, Coordinador del proyecto ORDICOP, por habernos
permitido realizar nuestro trabajo de grado en el torno al proyecto Ordicop
permitiéndonos aplicar nuestros conocimientos y habilidades y así mismo obtener
nuevos conocimientos.
Ingeniero de Sistemas Nelson Beltrán Galvis, director del trabajo de grado, por sus
consejos y asesorías técnica y metodológica, que nos ayudo a enfocarnos
siempre en la solución del problema.
Ingeniero Carlos René Angarita, por su asesoría técnica y por la atención que nos
prestó durante el transcurso del estudio realizado.
Equipo de trabajo del Proyecto ORDICOP, especialmente a la Ingeniera de
Sistemas Claudia Yamile Gómez Llanes, por sus consejos, recomendaciones,
asesorías y todos sus aportes que sin duda permitieron la realización de un
excelente trabajo.
Los docentes del Plan de Estudios de Ingeniería de Sistemas, en especial a los
Ingenieros Oscar gallardo, Pilar Rodríguez Tenjo y Marco Adarme, jurados del
trabajo de grado, por su colaboración y recomendaciones hechas a la
investigación.
Grupo GIDIS, por permitir que nuestro trabajo de grado hiciera parte del grupo de
investigación.
CONTENIDO
pág.
INTRODUCCION
18
1. GENERALIDADES
21
1.1 INTRODUCCIÓN A LOS SISTEMAS DE INFORMACIÓN
GEOGRÁFICOS
22
1.1.1 Flujo de trabajo de un SIG
23
1.1.2 Modelos de datos en un SIG
26
1.1.3 Sistemas de Información Geográficos en la Web (WebGIS)
33
1.2 BASES DE DATOS GEOGRÁFICAS Y DATOS ESPACIALES
33
1.2.1 Consultas espaciales
33
1.3 INTRODUCCIÓN A LA CARTOGRAFÍA
34
1.3.1 Cartográfica temática
35
1.3.2 Métodos de clasificación de datos
37
1.3.3 Simbología
40
1.3.4 Sistemas de proyecciones
41
1.3.5 Sistemas de coordenadas
43
1.4 MAPAS TEMÁTICOS CON MAPSERVER
45
2. CAPTURA Y PROCESAMIENTO DE LOS DATOS
46
2.1 DATOS TEMÁTICOS
46
2.2 DATOS ESPACIALES
47
2.3 TRATAMIENTO DE LOS DATOS ESPACIALES
52
2.4 FUSIÓN O UNIFICACIÓN DE LAS FUENTES DE DATOS
54
3. ACTIVIDADES DESARROLLADAS
55
4. METODOLOGIA DE DESARROLLO
59
5. DESARROLLO DEL PROYECTO
63
5.1 FASE I EXPLORATORIA
63
5.2 FASE II PLANIFICACION
71
6. CONCLUSIONES
108
7. RECOMENDACIONES
109
BIBLIOGRAFÍA
110
ANEXOS
111
LISTA DE FIGURAS
pág.
Figura 1. Logotipo Observatorio de Paz
21
Figura 2. El flujo de trabajo en un SIG
23
Figura 3. Topologías validas e inválidas
24
Figura 4. El proceso de fusión de las fuentes de datos
25
Figura 5. Partes del análisis georreferencial
26
Figura 6. Representación de puntos en el modelo vectorial
27
Figura 7. Representación de polígonos en el modelo vectorial
28
Figura 8. Representación de líneas en el modelo vectorial
28
Figura 9. Elementos que conforman un archivo de formas (shape .shp)
30
Figura 10. Modelo de datos raster, distribución de continentes y océanos
31
Figura 11. Modelo TIN, elevación de superficies en 3D
32
Figura 12. Tipos de consultas espaciales
34
Figura 13. Intervalos basados en cuantiles
38
Figura 14. Representación utilizando intervalos iguales
39
Figura 15. Intervalos basados en puntos de corte natural
40
Figura 16. El cubo de colores
41
Figura 17. Proyección cilíndrica
42
Figura 18. Proyección transversa
43
Figura 19. Sistema de coordenadas con paralelos y meridianos
43
Figura 20. Sistema de coordenadas geográficas, latitud y longitud
44
Figura 21. La estructura del mapfile
45
Figura 22. Consola programa shp2pgsql
52
Figura 23. Referenciación de los datos espaciales
54
Figura 24. El ciclo de desarrollo en XP
59
Figura 25. PostgreSQL / PostGIS
67
Figura 26. MapServer
68
Figura 27. Funcionamiento del servidor de mapas MapServer
69
Figura 28. Partición de imagen utilizando tiled cache
71
LISTA DE CUADROS
pág.
Cuadro 1. Entidades geométricas para la representación vectorial
29
Cuadro 2. Breve listado de variables por eje de investigación
46
Cuadro 3. SRID (Spatial Referencing System Identifier) aplicado a los
archivos de formas transformados
53
Cuadro 4. Asignación de prioridades a las historias de usuario
72
Cuadro 5. Cronograma de tareas por Iteraciones
73
Cuadro 6. Planificación de iteraciones
81
Cuadro 7. Historias de la iteración 1
81
82
82
82
83
Cuadro 12. Planificación de las tareas
84
Cuadro 13. Tareas realizadas para HU-01
85
89
91
93
94
96
98
99
100
100
103
104
105
106
LISTA DE FORMATOS
pág.
Formato 1. Cartografía correspondiente al límite departamental
47
Formato 2. Cartografía correspondiente al límite internacional (frontera con
Venezuela)
48
Formato 3. Cartografía correspondiente al ámbito regional
49
Formato 4. Cartografía correspondiente al ámbito municipal
50
Formato 5. Cartografía correspondiente al ámbito veredal
51
Formato 6. Descripción de la historia de usuario consultar mapa
74
Formato 7. Descripción de la historia de usuario configurar mapa
74
Formato 8. Descripción de la historia de usuario tipo de mapa
75
Formato 9. Descripción de la historia de usuario ver mapa
75
Formato 10. Descripción de la historia de usuario mover mapa
76
Formato 11. Descripción de la historia de usuario navegar mapa
76
Formato 12. Descripción de la historia de usuario registrar usuario
77
Formato 13. Descripción de la historia de usuario ingresar al sistema
77
Formato 14. Descripción de la historia de usuario salir del sistema
78
Formato 15. Descripción de la historia de usuario imprimir mapa
78
Formato 16. Descripción de la historia de usuario administrar eje temático
79
Formato 17. Descripción de la historia de usuario administrar variables
79
Formato 18. Descripción de la historia de usuario administrar indicador
80
Formato 19. Descripción de la historia de usuario administrar estudio anual
80
Formato 20. Descripción de la tarea T-01 para la historia HU-01
86
86
87
87
88
88
89
89
90
90
91
91
92
92
93
93
94
94
95
95
96
96
97
97
98
98
99
99
100
101
101
102
102
103
103
104
104
105
105
106
106
107
LISTA DE ANEXOS
pág.
Anexo A. Fase III - diseño
112
Anexo B. Fase IV desarrollo
162
Anexo C. Fase V pruebas
175
INTRODUCCION
El presente trabajo, se desarrollo en el marco de la alianza entre la Universidad
Francisco de Paula Santander, la Gobernación del Departamento de Norte de
Santander y el proyecto observatorio regional para el desarrollo integral y la
convivencia pacífica de Norte de Santander (ORDICOP), este trabajo se planteo
como apoyo a las actividades desarrollas dentro de la perspectiva de trabajo del
Observatorio regional de paz, encaminado en los tres ejes temáticos; cultura de
paz y derechos humanos, gobernabilidad democrática y desarrollo
socioeconómico.
En este contexto se implemento una aplicación web basada en un diseño por
capas, esta solución permite realizar un análisis exploratorio de datos espaciales
básico, junto con la posibilidad de visualizar, manipular y consultar estos datos
gráficamente de una manera ágil con una gran interactividad gracias a la
aplicación del conjunto de tecnologías AJAX, esta pretende ser una herramienta
con la capacidad de ayudar a las personas interesadas en la temática a realizar
una caracterización del territorio, establecer diagnósticos para la situación actual y
evaluar propuestas para el establecimiento de planes de trabajo.
Otro aspecto importante en el desarrollo del trabajo es que se observo la
necesidad de transferir la información sistematizada al público, por lo tanto se
facilito el acceso a la aplicación y se implementaron interfaces para la fácil
interpretación de la información producida, dado que al parecer existe una
tendencia a imponer restricciones directas por parte de las instituciones que
procesan información espacial o indirectas por cuenta de los altos costos que
implica la adquisición de software especializado para el tratamiento de datos
geográficos, el mantenimiento de sistemas de información geográficos y el
entrenamiento que se debe proporcionar al personal que lo maneja.
En la actualidad los diferentes municipios del Departamento de Norte de
Santander no cuentan con fuentes de datos abiertas que suministren la
información necesaria en cuanto a la situación geográfica, disposición y
distribución espacial, que les permita identificar las capacidades y recursos
territoriales con los cuales cuenta su respectivo municipio.
Pese a que en la actualidad se están desarrollando proyectos para cubrir estas
necesidades de información por parte de instituciones del gobierno a nivel
18
nacional y la existencia de herramientas que permiten un acceso más o menos
global a esos datos geográficos, por ahora no existe una solución a corto plazo
que integre el conjunto de soluciones especificas necesarias para el proyecto
ORDICOP tales como: Integración de los datos propietarios recopilados por el
Observatorio con datos espaciales de los municipios del Norte de Santander y
acceso por parte del público a estos datos.
La carencia de este sistema ha limitado la disposición de información al público
por parte del ORDICOP, por cuanto no se dispone de un sistema que relacione los
datos recolectados al sitio de ocurrencia de los fenómenos que estos representan.
Se encuentra que el problema radica en que se requiere presentar información
que se puede representar en una manera mucho más adecuada y legible
mediante el uso de técnicas de cartografía.
Existen muchos datos espaciales recolectados, procesados y organizados, sin
embargo existe una tendencia a imponer restricciones directas o indirectas al
acceso a esa información, ya sea por los altos costos que implica la adquisición de
software especializado como los sistemas de información geográficos (SIG), el
mantenimiento de estos sistemas y el entrenamiento que se debe proporcionar al
personal que lo maneja.
Si bien desde el punto de vista social el uso de la tecnología SIG aporta la
capacidad de comunicar con pocas restricciones los fenómenos geográficos
naturales o artificiales mediante mapas, los aspectos económicos y cognitivos
señalados anteriormente, dificultan la tarea de construcción de mapas por parte de
la gran mayoría del público que alguna vez necesita hacer uso de la información
geográfica.
Conforme a lo mencionado anteriormente, el observatorio regional para el
desarrollo integral y la convivencia pacífica de Norte de Santander (ORDICOP) ha
planteado la necesidad de implementar un sistema de información geográfico
(SIG), el cual va a permitir un acceso libre a información integrada y relacionada a
los distintos municipios que conforman el departamento de Norte de Santander,
dado que estos municipios en muchos casos no cuentan con los recursos de
capital, tecnología y de recurso humano, apropiados para comunicar la
información espacial.
Cerca del 80% de la información tratada por instituciones y empresas públicas o
privadas tienen en alguna medida relación con datos espaciales, lo que demuestra
que la toma de decisiones depende en gran parte de la calidad, exactitud y
19
actualidad de esta información espacial. En este sentido los Sistema de
Información Geográfica (SIG), se han constituido en un arma eficaz a la hora de
complementar el pensamiento y las relaciones de causalidad entre los fenómenos,
teniendo un impacto social importante las investigaciones que se realizan.
Una aplicación web SIG seria relevante para el Observatorio puesto que se
integraría a la estrategia de trabajo de este, proporcionando nuevos métodos y
herramientas para el análisis y la toma de decisiones en torno a las actividades
que se llevan a cabo dentro de la perspectiva de trabajo que incluye: Cultura de
Paz y derechos humanos, Gobernabilidad democrática y desarrollo
socioeconómico. En relación a estos puntos clave para la investigación que lleva a
cabo el Observatorio, el proyectó web SIG permitirá a este relacionar los datos
recolectados con sus respectivas ubicaciones geográficas.
La aplicación web SIG permitirá al Observatorio tener respuestas acertadas
acerca de cuestiones tales como Localización ¿Qué hay en…? Condición ¿Dónde
sucede que…? Tendencias ¿Qué ha cambiado….? Rutas ¿Cuál es el camino
optimo…? Pautas ¿Qué pautas existen…? Modelos ¿Qué ocurriría si…? ,
proporcionándoles herramientas adecuadas, información bien elaborada, de gran
calidad y relacionada a los distintos municipios del Departamento de Norte de
Santander.
20
1. GENERALIDADES
Para entender la motivación y la utilidad del presente proyecto conviene hacer una
breve descripción de lo que es el Observatorio regional para el desarrollo integral y
la convivencia pacífica del Norte de Santander. Este, es un instrumento de
carácter interinstitucional e interdisciplinario que investiga, documenta,
sistematiza, analiza y promueve escenarios, cuya finalidad es favorecer la
gobernabilidad democrática y de convivencia pacífica, como principios rectores
para el desarrollo integral, equitativo y sostenible.
Figura 1. Logotipo Observatorio de Paz
Fuente: OBSERVATORIO REGIONAL PARA EL DESARROLLO INTEGRAL Y LA
CONVIVENCIA PACÍFICA DE NORTE DE SANTANDER. Información general del
observatorio de paz. San José de Cúcuta: ORDICOP, 2009.
Misión. El observatorio es un espacio de investigación y análisis, con criterio
objetivo y propositivo, orientado a producir herramientas que apoyen el accionar
de las entidades comprometidas con el logro de la Paz, la Gobernabilidad, y el
desarrollo Integral de la región y de la frontera.
Visión. El Observatorio contribuye a orientar la reflexión de los diferentes sectores
de la sociedad norte-santandereana sobre sus políticas, programas y proyectos,
en el desarrollo de la agenda pos-conflicto regional y en la consolidación de la
integración fronteriza.
21
1.1 INTRODUCCIÓN A LOS SISTEMAS DE INFORMACIÓN GEOGRÁFICOS
La idea o concepto de sistema de información geográfico surge aproximadamente
en la década de los 60’s; desde entonces su conceptualización ha evolucionado,
sobre criterios globales, funcionales o tecnológicos. En este orden de ideas se
puede concebir un sistema de información geográfico (SIG), como un sistema
computacional que define un conjunto de métodos, herramientas y datos que
están diseñados para actuar coordinada y lógicamente para capturar, almacenar,
analizar, transformar y presentar toda la información geográfica y de sus atributos
con el fin de satisfacer múltiples propósitos.
Desde luego el concepto de SIG involucra el concepto de sistema, el cual hace
referencia a un conjunto de partes o componentes interrelacionados entre sí, por
ello un SIG consta de varios componentes, los cuales involucran una
infraestructura necesaria para su funcionamiento:
El equipo (hardware). Está conformado por los equipos de cómputo y los
periféricos además de los dispositivos GPS, tabletas digitalizadoras, etc...
Los programas (software). Consiste de los conjuntos de programas con la
funcionalidad para la visualización, consulta y análisis de los datos geográficos.
Los usuarios. El personal, ya sean los usuarios del sistema (categorizados según
el rol que estos tengan en el sistema).
Los procedimientos. Todo el conocimiento y el conjunto de técnicas aplicadas
por el talento humano sobre el software SIG en conjunción con el hardware con el
fin de lograr los objetivos.
La tecnología SIG permite gestionar y analizar la información espacial, que surge
de la necesidad de disponer rápidamente de información para resolver problemas
y contestar preguntas de modo inmediato. Por ende se espera que cumplan con
ciertas funciones, como mínimo:
Funciones de adquisición o captura de la información. Estas proveen rutinas
para adquirir y refinar la información geográfica espacial como la temática
preparándola para que pueda ser migrada a los sistemas que la trataran.
22
Funciones de gestión. Esta función hace posible la organización y estructuración
de los datos iníciales en varias capas de información con algún significado.
Posteriormente se podrá extraer una parte de información que interesa en cada
momento para realizar análisis y consultas de forma más eficiente.
Funciones de análisis. Son las que confieren a un SIG su mayor potencialidad.
Facilitan el procesado de los datos, permitiendo extraer información no presente a
simple vista, generar nuevos datos y realizar simulaciones de comportamientos
basados en modelos del territorio.
Funciones de salida. Permiten mostrar al usuario tanto los propios datos
incluidos en el sistema como el resultado de las consultas y análisis sobre ellos. El
formato será muy diverso, mapas, gráficos, tablas, listados, etc.
1.1.1 Flujo de trabajo de un SIG. Para obtener el máximo beneficio de un SIG,
el usuario debe saber cuál es la secuencia de fases que ha de aplicar para llegar a
solucionar un problema que se le ha planteado, la siguiente figura, ilustra el
proceso del flujo de trabajo.
Figura 2. El flujo de trabajo en un SIG
23
Estas fases consisten en los siguientes procesos:
Captura de la información. La cantidad de información requerida varía en
función del problema planteado, de tal manera que la calidad de los datos
originales influye en la calidad del resultado final.
Preparación de la información. Es necesario que la información esté limpia de
errores (cometidos en la captura) y dotada de una estructura que permita una
consulta y un análisis eficiente por parte del sistema.
En el caso de información vectorial, hacer que los polígonos estén cerrados o que
las líneas conecten entre sí permitirá estructurar la información guardando sus
relaciones topológicas, tal como puede apreciarse en la siguiente figura.
Figura 3. Topologías validas e inválidas
Fuente: BECK, Kent. Extreme programing explained. Florida: Addison-wesley,
1999.
Fusión de la información espacial y temática. Es el proceso por el cual se
asocia a cada elemento geográfico información temática externa de naturaleza
diferente a la espacial, la siguiente figura, ilustra acerca de dicho proceso.
Cada elemento geográfico tiene un enlace biunívoco con su información temática
asociada de forma que es posible interrogar a un elemento espacial y obtener el
resultado en forma de información temática y viceversa, interrogar a la información
temática y obtener como resultado un elemento espacial.
24
Figura 4. El proceso de fusión de las fuentes de datos
Fuente: MORENO JIMÉNEZ, Antonio.
geográfica, Madrid: Alfaomega, 2006.
Sistemas y análisis de la información
Análisis de la información. Una vez fusionados los datos, se los puede someter
a operaciones de análisis que sigan los criterios de resolución del problema.
El análisis puede ser sobre datos de una única naturaleza (datos espaciales o
temáticos por separado) o analizar ambos tipos de datos a la vez. La siguiente
figura, muestra el análisis que se puede realizar dentro de un SIG, en cual se
puede tratar la información geográfica de tres formas:
Analizando únicamente la parte temática (como haríamos en una base de datos
corriente).
Analizando únicamente la parte espacial, estudiando sus características
geométricas.
25
Analizando de forma conjunta ambos componentes, siendo esta forma la más útil
y potente desde el punto de vista de la filosofía de trabajo de los SIG.
Figura 5. Partes del análisis georreferencial
1.1.2 Modelos de datos en un SIG. Un modelo es una representación de la
realidad y se genera mediante la selección y la simplificación de sus partes. Para
que sea geográfico, el modelo ha de poseer un sistema de referenciación
geográfico.
La información en un SIG, es decir, los datos geográficos tienen dos
componentes: la información espacial y la información de atributos. La información
espacial dice donde está localizado un elemento geográfico, en relación a sus
coordenadas ya sean planas o geográficas. La información de atributo define que
es el elemento.
26
Para almacenar la información espacial podemos recurrir a entidades geométricas
básicas como los puntos, las líneas y los polígonos. Un punto es la representación
de un par de coordenadas (x, y); una línea es el conjunto de puntos y un polígono
es un conjunto de coordenadas que envuelven un área. La información de estos
atributos se almacena en tablas.
Existen algunos atributos que provienen de la propiedad geométrica de los
elementos que la representan: las coordenadas de un punto, la longitud de una
línea y el área de un polígono. Además de esta información, pueden asociarse
tablas que describen los atributos alfanuméricos del elemento.
Cuando la información se representa mediante elementos geométricos se dice que
tiene una representación vectorial. Otra forma de almacenamiento y manipulación
de la información geográfica es el modelo raster o por celdas. Es importante
mencionar que la forma de almacenamiento y de manipulación de la información
en un SIG varía de acuerdo con las funciones que este debe cumplir.
Modelo de datos vectorial. Cuando se representan los fenómenos geográficos
mediante puntos, líneas y polígonos, estamos utilizando el denominado modelo de
datos vectorial. Este resulta particularmente útil para representar entidades
geográficas discretas, como edificios, carreteras o límites municipales, las
siguientes figuras, ilustran acerca de los fenómenos geográficos mencionados.
Figura 6. Representación de puntos en el modelo vectorial
27
Figura 7. Representación de polígonos en el modelo vectorial
Figura 8. Representación de líneas en el modelo vectorial
28
La información de la geometría y los atributos relacionados a esta última son
asociados mediante propiedades relacionales en una base de datos. Por lo tanto
en un nivel de información vectorial se pueden almacenar puntos, líneas, y
polígonos. El siguiente cuadro, muestra los tipos de representación vectorial.
Cuadro 1. Entidades geométricas para la representación vectorial
Elemento geométrico
Puntos
Representación
Fenómenos puntuales en
los
que
se
desea
conocer la posición x, y
Fenómenos lineales en
los
que
se
desea
conocer la longitud
Ejemplo
Pozos, postes, etc.
Vías,
drenajes,
oleoductos, líneas de
conducción eléctrica.
Semáforos,
señales
Fenómenos puntuales en
de tránsito, entrega de
Nodos
la intersección de los
aguas en redes de
arcos
drenaje.
Fenómenos relativos a
áreas
definidos
por
Lotes, uso de suelo,
Polígonos
regiones
homogéneas
cobertura vegetal.
acotadas
por
una
frontera
Fuente: Parra-Sánchez-Marulanda. Sistemas de Información Geográfica Base de
la Gestión Ambiental
Líneas
En un SIG vectorial existe un concepto muy importante, llamado topología que
define las relaciones espaciales entre los elementos geográficos. Cuando se
construye la topología a cierto nivel de información, las propiedades geométricas y
topológicas se definen y almacenan en tablas. La estructura de esas tablas varía
dependiendo del tipo de entidad; sin embargo, todas ellas tienen algunas
características comunes.
Cada entidad ocupa un registro de tabla.
Solo se puede almacenar uno y solo un tipo de elemento geométrico por tabla, es
decir: si el elemento geométrico consiste de puntos, solo se podrán almacenar
puntos en la tabla.
29
Para un conjunto de datos espaciales, es posible tener más de una tabla de
atributos.
Cada registro de la tabla contiene, como mínimo, un identificador que también se
almacena en la base de datos grafica.
Un formato de archivo vectorial. El shapefile (archivo de formas o cartográfico),
es un formato de archivo propietario, creado por la empresa ESRI desarrolladora
del sistema ArcGIS, que ha llegado a convertirse en el estándar de facto.
El shapefile o archivo de formas se presenta como un conjunto de ficheros, con el
mismo nombre de archivo pero con distintas extensiones, entre los que podemos
distinguir tres ficheros básicos siempre presentes y ocasionalmente dos índices
espaciales y dos índices de atributo:
Ficheros básicos: están compuestos por tres extensiones, el núcleo o .shp
(shape), el cual almacena las características geométricas de sus registros como
una lista de pares de coordenadas X-Y. El índice de los registros .shx (índex
shape), contiene un índice de cada registro, es decir, un registro del número de
registros y la longitud de cada registró existente en el .shp. Las bases de datos
con los atributos .dbf (database file) que guardan la información de los atributos y
sus características, conteniendo un registro de cada elemento de los .shp.
Índices espaciales: no existen hasta la ejecución una operación, como unión o
selección espacial. Dos archivos son creados: .sbn y sbx. Los .sbn (spatial bin o
recipiente espacial) dividen el area de los elementos geográficos de los .shp en
areas rectangulares llamadas recipientes. Cada recipiente contiene el numero de
registros de cada elemento que caen dentro de esa area, de modo que cuando se
hace una consulta espacial sobre el .shp, este el primer documento que se lee.
Figura 9. Elementos que conforman un archivo de formas (shape .shp)
30
El modelo de datos raster. En el modelo raster la representación del mundo real
no es discreta, como en el modelo vectorial sino continua, mediante un área
dividida en celdas regulares que se denominan cuadriculas o grid y en donde cada
celda se conoce con el nombre de pixel (picture element). En este modelo cada
pixel representa una cualidad cuantificable de observación, la mínima,
representada en cada localización mediante un tono o color, que se traduce a un
valor numérico o nivel digital.
En vez de representar los elementos por sus coordenadas, el modelo raster utiliza
una rejilla o malla superpuesta sobre el paisaje para representar los elementos
geográficos. El fenómeno predominante dentro de una celda determina la
información de la celda. Puede crearse una tabla de atributos para cada valor de
la celda.
En general, todas las imágenes digitales se almacenan en formato raster, también
llamado formato por pixeles. Cada pixel o celda representa un área determinada
de la superficie terrestre. Así, para representar un área de estudio se pueden
agrupar múltiples niveles de información de diferentes resoluciones, de la misma
manera que en el formato vectorial [4]. Cada tema puede ser representado por
medio de una malla independiente o bien una malla puede tener múltiples
atributos asociados a ella.
Figura 10. Modelo de datos raster, distribución de continentes y océanos
Fuente: MITCHELL, Tyler. Web mapping illustrated. New York: O`reilly, 2006.
31
Debido a la representación por celdas del modelo raster, es necesario definir la
resolución o tamaño de la celda. El atributo se asocia a cada celda como un valor
único: por tanto el número total de de valores que deben almacenarse depende
del número de filas y de columnas de la malla. La resolución define el tamaño de
los archivos digitales así como la precisión en la ubicación de elementos.
Los componentes de la malla son entonces: celda, las filas y columnas, las
coordenadas del origen de la malla. En una malla podemos almacenar valores
enteros o reales. La gran ventaja del modelo raster es que permite modelar
fenómenos tales como la expansión de áreas urbanas, la propagación del fuego,
el crecimiento de plagas y todas las operaciones llamadas algebra de mapas.
El modelo de red de triángulos irregulares (TIN). El tercer modelo, utilizado
para representación tridimensional es el modelo TIN (Triangulated Irregular
Network) o red de triángulos irregulares, en este modelo las entidades geográficas
son representadas como una red de triángulos irregulares unidos entre sí
mediante puntos con valores X, Y e Z. las entidades que son muy complejas
pueden ser representadas con una mayor exactitud, con un determinado volumen
de datos, mediante una superficie TIN.
Figura 11. Modelo TIN, elevación de superficies en 3D
32
1.1.3 Sistemas de Información Geográficos en la Web (WebGIS). A los
sistemas de información geográficos publicados por internet se les conoce con el
nombre genérico de WebGIS sin embargo, estos no constituyen un SIG por sí
mismos, sino más bien son una parte de estos. Un WebGIS es una aplicación
WWW que generalmente ofrece funciones de visualización de cartografía digital,
búsqueda y operaciones de geoprocesamiento básicas. un Sistema de
Información Geográfico se distingue de su contraparte en Internet en que este
último tiene el objetivo especifico de comunicar información geográfica a la mayor
cantidad de usuarios posibles permitiéndoles ubicarse en el espacio e incluso
permitiéndole a estos ubicar geográficamente recursos físicos en la red de datos,
por ejemplo aquellas aplicaciones de mapas callejeros que permiten cruzar estos
con datos GPS en tiempo real, aplicaciones catastrales o sistemas de información
geográfico de administraciones locales.
1.2 BASES DE DATOS GEOGRÁFICAS Y DATOS ESPACIALES
Se pueden considerar dos grandes tipos de datos espaciales por un lado los datos
geográficos, que incluyen los datos representados por alguna geometría y la
información de atributo asociada a ellos. Por otra parte los datos de diseño
asistido por computadora (CAD), como los diseños de edificios. Cada tipo
representa situaciones distintas, el dato geográfico representa información
existente, modela situaciones reales, en tanto los datos de diseño son el resultado
del proceso de modelar objetos que aun no existen.
El soporte de los datos espaciales en las bases de datos es importante para el
almacenaje, indexado y consulta eficientes de los datos basados en las posiciones
espaciales. Por ejemplo, supóngase que se desea almacenar un conjunto de
polígonos en una base de datos y consultar la base de datos para hallar todos los
polígonos que intersecan un polígono dado. No se pueden utilizar las estructuras
estándares de índices como los árboles B o los índices asociativos para responder
de manera eficiente esas consultas. El procesamiento eficiente de esas consultas
necesita estructuras de índices de finalidades especiales, como los árboles R.
1.2.1 Consultas espaciales. Hay varios tipos de consultas que implican
operaciones espaciales como muestra la siguiente figura, generalmente estas
consisten en:
Las consultas de proximidad solicitan objetos que se hallen cerca de una
ubicación especificada. La consulta para hallar todos los restaurantes que se
hallan a menos de una distancia dada de un determinado punto es un ejemplo de
33
consulta de proximidad. La consulta de vecino más próximo solicita el objeto que
se halla más próximo al punto especificado.
Las consultas regionales tratan de regiones espaciales: estas consultas pueden
preguntar por objetos que se hallen parcial o totalmente en el interior de la región
especificada. Un ejemplo es la consulta para hallar todas las tiendas minoristas
dentro de los límites geográficos de una ciudad dada.
Figura 12. Tipos de consultas espaciales
Fuente: BECK, Kent. Extreme programing explained. Florida: Addison-wesley,
1999.
Puede que las consultas también soliciten intersecciones y uniones de regiones.
Por ejemplo, dada la información regional, como pueden ser la lluvia anual y la
densidad de población, una consulta puede solicitar todas las regiones con una
baja cantidad de lluvia anual y una elevada densidad de población. En general, las
consultas de datos espaciales pueden tener una combinación de parámetros
espaciales y no espaciales.
1.3 INTRODUCCIÓN A LA CARTOGRAFÍA
La cartografía se puede definir como la ciencia, la tecnología y el arte de elaborar
mapas que representan los datos geográficos y espaciales, la cual abarca la
formación, análisis, mantenimiento, lectura, interpretación y uso de mapas. El
mapa a su vez, se define como un modelo reducido y simplificado de la realidad,
así mismo es una representación convencional, grafica y a escala de fenómenos
concretos o abstractos localizados en algún punto en el espacio y que conserva la
posición relativa de su localización.
34
1.3.1 Cartográfica temática. Se Puede asumir la cartografía temática como el
esquematismo que se realiza en un conjunto de mapas que contienen una
información adicional propia, distinta de la puramente geográfica. Se fundamenta
en una base de referencia locacional e incluye una información adicional.
Cuando se ve un mapa se desea que este cumpla con ciertas cualidades, como:
Claridad y Legibilidad. Del mapa, evitando, por ejemplo, incluir demasiada
información en él.
Esquematismo. Al pasar de la realidad a un mapa, tendremos que generalizar la
información en función del fenómeno y la escala.
Rigurosidad. Definida como la precisión. Se trata de colocar el fenómeno, no sólo
en el sitio exacto, sino no intentar ser más preciso que la propia fuente de
información. La mayoría de los mapas incluyen datos estadísticos que han tenido
que ser tratados previamente de una manera rigurosa.
Poder de evocación. Que seamos capaces de hacer entender la información.
Por ejemplo, los colores oscuros son mejores, en este sentido, que los claros.
El mapa tiene muchas ventajas a la hora de presentar información espacial porque
con los colores, tramas, leyendas y demás elementos, en una misma hoja se está
representando todo, se transmite una gran cantidad de información que el usuario
puede usar según sus necesidades. Esa enorme cantidad de información debe ser
elaborada según el receptor al que va dirigido el mapa.
Simbolizar los datos implica la elección de los colores y símbolos que
representaran los elementos además de agruparlos y clasificarlos de acuerdo a
sus valores. La lectura de un mapa no se basa en la identificación de sus
elementos, si no en la búsqueda de relaciones que se establecen entre ellos. Por
tanto, es preciso que en el dibujo haya orden evitando las reiteraciones.
Existe una ilimitada variedad de datos espaciales que pueden representarse bajo
símbolos, estos pueden clasificarse en tres:
35
Símbolos de puntos: son individuales, representan datos posiciónales
Símbolos de línea: representan una diversidad datos geográficos, no implica que
el tipo de dato se lineal o escalar sino que la información lo sea
Símbolos de zona o área: se extienden sobre la superficie del mapa, para indicar
cierto aspecto común.
Los símbolos pueden tener valores distintos en función de su color, valor, tamaño,
forma, espaciado, orientación y ubicación.
El color es la apreciación más importante y compleja, dado que el color se asocia
a un valor. La elección de los colores a utilizar es esencial para que el mapa este
bien presentado, de otro modo pueda distraer la atención indebidamente,
mediante combinaciones y contrastes inadecuados.
Para que se presenten mejor los elementos hay que tener en cuenta: en primer
lugar que sean claros y legibles, por tanto hay que fijar bien los tamaños para que
luego cuando se lean, se interpreten correctamente. Es decir, deben estar bien
contrastados, uniformes y claros, para que no se presten a confusión, en segundo
lugar, el signo debe diferir del fondo y de los signos adyacentes. El contraste se
logra mediante la modulación de elementos gráficos. Por último, los elementos
deben estar dispuestos de tal modo que la relación parezca lógica y no fuera de
lugar.
Mapas cuantitativos. La mayor parte de representaciones cartográficas se
realizan con variables de tipo cuantitativo, por ello son más empleados en toda la
comunidad científica. En esta representación cartográfica se tienen en cuenta dos
aspectos de los datos geográficos: la Entidad Geográfica, como base de
referencia locacional, y la Componente Temática.
La entidad geográfica puede ser de dos tipos: natural o artificial. La primera
significa como está en el propio territorio, por ejemplo, el uso del suelo; si estudio
el terreno por zonas, se tratará de una entidad geográfica artificial.
La componente temática es variable; muy pocas veces es constante y que desde
el punto de vista estadístico es necesario tener claros tres conceptos:
36
Variable: es el concepto general, el fenómeno, este se suele representar por la
letra mayúscula(X).
Valor: cantidad que toma en un momento determinado. se representa con la
misma letra, en minúscula (xi).
Frecuencia: número de veces que se repite un valor en un periodo determinado
(ni).
Mapas de Coropletas. Son mapas en los que se representa las distintas
variaciones de una variable sobre un espacio dado, empleando colores con tramas
diferentes. En este caso el espacio sobre el que se representan es un área o
región. Los símbolos cambian de color en función de los valores que adopte la
variable elegida.
Son adecuados para representar datos en rangos sean cualitativos o cuantitativos
con algún tipo de progresión numérica (medidas, proporciones, porcentajes, etc.),
así como para variables de densidad o de intensidad.
Para realizar este tipo de representación de datos hay que organizar los datos,
ordenarlos y clasificarlos, en el caso de los mapas temáticos de coropletas lo
usual es representar las variaciones mediante clases. Esto se logra aplicando un
método de clasificación, la selección de este dependerá de la distribución de los
datos.
1.3.2 Métodos de clasificación de datos. Se describe a continuación:
Intervalos basados en cuantiles. Cada intervalo posee el mismo número de
elementos. Muchas veces esta división induce al error, pues valores bajos de la
variable son regularmente incluidos en el mismo intervalo que los valores altos.
Sin embargo para atenuar esta distorsión se pueden incrementar el número de
intervalos.
Su utilización es más adecuada para datos cuya distribución sea homogénea, es
decir, que no presenta un número excesivo de elementos con valores similares.
37
Figura 13. Intervalos basados en cuantiles
Intervalos iguales: los valores de la variable se agrupan en intervalos de igual
amplitud o tamaño. Su utilización es adecuada para datos cuya amplitud (valores
máximos y mínimos) es bastante conocida.
En cambio, no es aconsejable si se desea apreciar diferencias muy pequeñas
entre elementos con valores muy similares.
38
Figura 14. Representación utilizando intervalos iguales
Intervalos basados en puntos de corte natural. Es el método óptimo. Realiza el
agrupamiento buscando patrones inherentes a los datos reduciendo la variación
de elementos en una clase mediante el algoritmo de optimización de Jenks. El
algoritmo de Jenks consiste básicamente en la minimización de la suma de la
varianza intra-clase. Es decir, se trata de obtener la máxima homogeneización
(mínima dispersión) dentro de cada intervalo y la máxima dispersión entre
intervalos.
39
Figura 15. Intervalos basados en puntos de corte natural
1.3.3 Simbología. El color en cartografía temática juega un papel muy
importante en la visualización y el análisis de los datos presentados en los mapas
temáticos, por lo tanto su correcta aplicación facilitara la observación de patrones
e identificación de relaciones.
Los modelos de colores pueden dividirse en: Modelos basados en la percepción
(Perceptually based models), como HSB (hue, saturation, brightness) el cual tiene
una representación similar a como los humanos perciben los colores en cada
momento de su vida. Por otra parte en los modelos basados en la pantalla
(display-based model) como RGB (red, green, blue), la apariencia de los colores
producida depende de la configuración de la pantalla.
En el modelo RGB los colores se especifican basándose en la intensidad de los
colores primarios (rojo, verde, azul).
40
El rango de intensidades para la gama de colores puede ser visto como un cubo
con posiciones especificadas en un plano tridimensional con coordenadas enteras
positivas x, y e z, estas coordenadas controlan la intensidad del rojo, verde y azul,
el valor máximo para cada coordenada suele ser 256, con un rango de 0 a 255. Lo
cual da 2563 o mejor 16.777.216 combinaciones posibles de colores.
En cartografía temática, lo más común es identificar el valor estadístico más bajo
con un el color más claro del esquema de colores seleccionado, es decir un color
de inicio y un color final, el cual identificara el valor estadístico más alto, de tal
manera que los colores para los valores estadísticos intermedios se calculan
mediante una interpolación lineal entre los colores de inicio y fin.
Figura 16. El cubo de colores
Fuente: ROBINSON, Arthur. Elementos de cartografía. Madrid: John Wiley, 1995.
1.3.4 Sistemas de proyecciones. Una proyección cartográfica es un sistema
que representa la superficie curva de la tierra sobre un plano o un sistema plano
de meridianos y paralelos sobre el cual se puede dibujar un mapa.
Es necesario establecer una correcta correspondencia entre los puntos ubicados
sobre la superficie cuerva y sobre el plano; esto se logra mediante la proyección.
41
Para ello se usa una figura geométrica representada por un cono, un cilindro o un
plano, etc.
Las proyecciones se clasifican de acuerdo a la figura seleccionada, para la
proyección encontramos:
Proyección cónica.
Proyección cilíndrica.
Proyección cilíndrica de Mercator.
Proyección Transversa de Mercator.
Proyección acimutal.
Figura 17. Proyección cilíndrica
42
Figura 18. Proyección transversa
En Colombia la proyección usada es por el Instituto geográfico Agustín Codazzi,
para realizar cartografía es la Proyección Transversa de Mercator (UTM).
1.3.5 Sistemas de coordenadas. El sistema de coordenadas está basado en la
rotación de la tierra y está compuesto por un conjunto de líneas imaginarias
trazadas sobre la superficie de la tierra denominada paralelos y meridianos.
Figura 19. Sistema de coordenadas con paralelos y meridianos
43
El plano horizontal esta demarcado de forma natural por el Ecuador que divide la
tierra en dos hemisferios: norte y sur, el cual podrá ser medido en grados de
Latitud N, o grados con signo positivo y cualquier punto situado al sur será medido
con grados de latitud S o grados con signo negativo, con un rango de +90º N y 90ºS.
El meridiano de Greenwich demarca el plano vertical, forma el círculo máximo que
pasa por los polos y divide en dos hemisferios: el oriental y el occidental, los
grados hacia el oriente o hacia el occidente serán medidos como grados de
longitud: grados con signo positivo hacia el oriente y negativos hacia el occidente
con un rango entre +180ºE y -180ºO. Entre los sistemas de coordenadas más
usados encontramos el sistema de coordenadas geográficas y el sistema de
coordenadas planas: El sistema de coordenadas geográficas, representa la
ubicación de cualquier punto sobre la tierra con base en un par de medidas
angulares: latitud y longitud.
Figura 20. Sistema de coordenadas geográficas, latitud y longitud
Sistema de coordenadas planas. Es un sistema constituido por una serie de
líneas verticales y horizontales denominadas ordenadas y abscisas. La unidad de
medida es determinada mediante el sistema métrico decimal.
Los valores de los ejes se usan como sistemas de tipo local en mapas de escala
grande debido a su gran precisión para ubicar puntos. Para el caso de Colombia,
los orígenes son 74º 4’ 51’’ de longitud W y 4º35’56”57 de latitud N.
44
1.4 MAPAS TEMÁTICOS CON MAPSERVER
El archivo de configuración Mapfile. El mapfile es un archivo de configuración
utilizado por el entorno de desarrollo MapServer, es una especie de archivo .INI o
de inicialización, en el se define: la apariencia, la proyección, las capas, fuentes de
datos geográficos y todas las características necesarias para producir un mapa,
tales como, extensión, formato de salida, visibilidad, color, posición de las
etiquetas, tipo de fuentes, etc. Posee una sintaxis básica, basada en una
estructura jerárquica de layes (capas) y classes (clases), como se muestra a
continuación, en el diagrama.
Figura 21. La estructura del mapfile
45
2. CAPTURA Y PROCESAMIENTO DE LOS DATOS
2.1 DATOS TEMÁTICOS
Los datos empleados en la aplicación están agrupados en tres ejes temáticos,
estos datos fueron proporcionados por el mismo Observatorio el cual se ha
encargado de obtener esta información a partir de las distintas actividades que
realiza en los municipios que investiga. Los estudios realizados por el
Observatorio incorporan datos desde el año 1997, los cuales están clasificados
por variables, indicadores y ejes temáticos, cabe mencionar que la información
obtenida abarca por ahora solo el ámbito municipal.
Cultura de paz y derechos humanos, Gobernabilidad democrática y Desarrollo
socioeconómico.
El siguiente cuadro, describe algunas de las variables, que se han utilizado para
definir las tendencias en los tres ejes temáticos, nótese que aparecen algunas
variables en dos o tres ejes simultáneamente, esto indica que la variable se utiliza
para describir este eje pero desde una perspectiva distinta.
Cuadro 2. Breve listado de variables por eje de investigación
EJE TEMATICO
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Cultura de paz y derechos humanos
Gobernabilidad
Desarrollo Socioeconómico
46
VARIABLE
Desmovilización
Homicidios
Violencia
Cultivos ilícitos
Fosas
Seguridad
Participación ciudadana
Partidos Políticos
Educación
Salud
Matriculas por zona
Socioeconómico
Población en edad escolar
Producción
Población por nivel y zona
Geográfico
2.2 DATOS ESPACIALES
La cartografía empleada en el proyecto está compuesta por varios mapas políticoadministrativos del Departamento Norte de Santander en los ámbitos: regional,
municipal y veredal. Esta cartografía se describe a continuación:
Formato 1. Cartografía correspondiente al límite departamental
DATOS BASICOS
Layer name: limiteDepartamental
Geometry: Polygon
Feature Count: 1
Extent:
(1048910.084239, 1251986.117633) (1228138.244564, 1519400.100562)
SISTEMA DE REFERENCIA ESPACIAL
PROJCS["Colombia_Bogota_Zone",
GEOGCS["GCS_Bogota",
DATUM["Bogota_1975",
SPHEROID["International_1924",6378388.0,297.0]],
PRIMEM["Greenwich",0.0],
UNIT["Degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["False_Easting",1000000.0],
PARAMETER["False_Northing",1000000.0],
PARAMETER["Central_Meridian",-74.08091666666667],
PARAMETER["Scale_Factor",1.0],
PARAMETER["Latitude_Of_Origin",4.599047222222222],
UNIT["Meter",1.0]]
Id: Integer (6.0)
descrip: String (30.0)
extension: String (10.0)
47
Formato 2. Cartografía correspondiente al límite internacional (frontera con
Venezuela)
DATOS BASICOS
Layer name:
modifica
limite
Internacional
Geometry: Line String
Feature Count: 1
Extent:
(1079784.705592, 1267524.573191) (1228138.213990, 1519404.603831)
UNIT["Degree",0.0174532925199433]],
UNIT["Meter",1.0]]
ID: Integer (8.0)
48
Formato 3. Cartografía correspondiente al ámbito regional
DATOS BASICOS
Layer name: regiones
Geometry: Polygon
Feature Count: 6
Extent:
(1048910.084239, 1251986.117633) (1228138.244564, 1519400.100562)
UNIT["Degree",0.0174532925199433]],
UNIT["Meter",1.0]]
region: String (20.0)
49
Formato 4. Cartografía correspondiente al ámbito municipal
DATOS BASICOS
Layer name: limite mpal modifi
Geometry: Polygon
Feature Count: 41
Extent:
(1048910.084239, 1242632.925552) (1228138.244564, 1519400.100562)
UNIT["Degree",0.0174532925199433]],
UNIT["Meter",1.0]]
NOM_MUNI: String (20.0)
COUNT: Real (11.0)
NOM_DPTO: String (19.0)
AREA_KM2: Real (9.2)
TOTAL_CANT: Real (16.0)
TOTAL_OTRA: Real (18.0)
50
Formato 5. Cartografía correspondiente al ámbito veredal
DATOS BASICOS
Layer name: veredas nds modifica
Geometry: Polygon
Feature Count: 1790
Extent:
(1048910.084239,
1251986.117633) - (1228138.244564,
1519400.100562)
UNIT["Degree",0.0174532925199433]],
UNIT["Meter",1.0]]
NOM_UNID: String (30.0)
COD_SUB: Integer (10.0)
NOM_SUBR: String (12.0)
NOM_MUNI: String (20.0)
COD_SISBEN: Real (13.0)
TIPO_UNID: String (17.0)
AREA_KM2: Real (9.2)
51
2.3 TRATAMIENTO DE LOS DATOS ESPACIALES
La mayoría de la cartografía se encontraba en el formato de datos vectorial .shp
dado que estos debían vincularse con los datos temáticos en la base de datos, lo
mejor era convertir cada archivo .shp a una tabla en la base de datos. Para ello
los archivos .shp se hicieron más livianos, es decir, se eliminaron columnas que no
guardaban información necesaria.
Para la transformación de formato se utilizo la herramienta SPIT del programa
Quantum GIS, la cual es solo una interfaz grafica de la utilidad de PostgreSQL
shp2pgsql. A continuación se muestra el procedimiento utilizado para la migración
utilizando el programa shp2pgsql en consola:
Figura 22. Consola programa shp2pgsql
D:\data\shapes>shp2pgsql -i -s 4218 geo_municipio.shp geo_municipio >
geo.sql
Shapefile type: Polygon
Postgis type: MULTIPOLYGON[2]
El comando shp2pgsql, tiene un conjunto de opciones disponibles, a continuación
se describen algunas que se aplican son:
-D:
obliga a utilizar el formato database dump por defecto el formato insert es
utilizado optimizando la carga de los datos.
-s < #>: configura el código SRID (spatial reference system identifier), para cuando
se crean las tablas y las geometrías. Es importante especificar ya que permitirá
realizar operaciones de transformación de coordenadas dentro la base de datos
-i: obliga a usar enteros de 32 bits para todos los valores enteros.
-W <encoding >:
especifica el tipo de codificado a aplicar.
52
-a: modo adicionar, es el modo por defecto, crea la tabla vacía y luego la llena con
los datos.
El siguiente cuadro, muestra algunas de las propiedades del identificador de
sistema de referencia espacial (SRID), el cual es un código utilizado por la base de
datos espacial para saber qué sistema de coordenadas geográficas y cuál
proyección fue aplicada a los datos espaciales.
Cuadro 3. SRID (Spatial Referencing System Identifier) aplicado a los
archivos de formas transformados
SRID
AUTH_NAME
AUTH_SRID
SRTEXT
PROJ4TEXT
4218
EPSG
4218
GEOGCS["Bogota
1975",DATUM["Bogota_1975",SPHEROID["International
1924",6378388,297,AUTHORITY["EPSG","7022"]],TOWGS
84[307,304,318,0,0,0,0],AUTHORITY["EPSG","6218"]],PRIMEM["Green
wich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.017
45329251994328,AUTHORITY["EPSG","9122"]],AUTHORI
TY["EPSG","4218"]]
+proj=longlat +ellps=intl +towgs84=307,304,-318,0,0,0,0
+no_defs
El campo SRID representa un código único de identificación, implícitamente se
refiere a una llave foránea utilizado por la columna que almacena la geometría de
una tabla frecuentemente llamada the_geom ó geom, de modo que el SRID está
embebido en cada geometría.
El campo AUTH_NAME se refiere a la autoridad u organización que define el
sistema de referenciación (por ejemplo para sistemas EPSG, la autoridad es
ESPG).
El campo AUTH_SRID es el código asignado por la autoridad y los campos
SRTEXT y PROJ4TEXT son la definición del sistema en sintaxis WKT (well known
text) y PROJ4 respectivamente
53
2.4 FUSIÓN O UNIFICACIÓN DE LAS FUENTES DE DATOS
Una vez realizado el tratamiento de los datos geográficos, se necesito vincularlos
con la información temática, esto se hizo utilizando la tabla que contiene los datos
del ámbito municipal ya que toda la información temática hacía referencia a este
ámbito. Uniendo las tablas temáticas y las tablas espaciales mediante el GID
(geographic identificator) se pueden obtener mapas temáticos clasificando los
valores de los indicadores atendiendo diferentes criterios de consulta.
Figura 23. Referenciación de los datos espaciales
54
3. ACTIVIDADES DESARROLLADAS
Recopilar información cartográfica de cada municipio del departamento Norte de
Santander.
Para cumplir este objetivo se realizaron las siguientes actividades:
Actividades: Obtener los datos geográficos adecuados a la naturaleza del
proyecto.
Metodología:
Solicitar a acceso a los datos geográficos a la oficina de planeación del
departamento Norte de Santander y a las dependencias que posean este tipo de
información.
Revisar los datos recibidos filtrando los que tengan mayor calidad.
Resultados obtenidos:
Se obtuvieron datos geográficos de los ámbitos departamental, municipal y
veredal del departamento de Norte de Santander.
Se seleccionan los datos que van a utilizarse.
Clasificar la información de variables e indicadores de los tres ejes básicos
(derechos humanos, gobernabilidad y participación ciudadana, desarrollo
socioeconómico) provista por el observatorio.
Actividades: Organizar los datos de variables e indicadores conforme al esquema
de clasificación manejado del observatorio.
55
Metodología:
Obtener los datos almacenados libros de Excel y en bases de datos Access.
Solicitar a ingeniero de ORDICOP información sobre la forma de clasificación de
los datos temáticos.
Reunirse con ingeniero de ORDICOP para verificar la clasificación y validar el
trabajo realizado.
Resultados obtenidos: Se obtienen los datos temáticos organizados por eje,
variable, indicador, municipio y año y se almacenan en formato XLS.
Migrar los datos espaciales y no espaciales que se encuentran en sistemas de
archivo a almacenamiento persistente en la base de datos.
Actividades: Migrar los datos temáticos y los datos geográficos a la base de datos
de indicadores.
Metodología:
Seleccionar un sistema de gestión de base de datos.
Programar el esquema para la base de datos de indicadores.
Pasar los datos temáticos filtrados a la base datos.
Exportar los archivos .SHP a la base de datos fijando un sistema de referencia
espacial.
Resultados obtenidos: Se obtiene un esquema de base de datos preliminar con los
datos geográficos y los datos temáticos almacenados en la misma base datos.
56
Integrar la base de datos espacial con la base de datos del proyecto Observatorio
Regional de Paz (ORDICOP).
Actividades: Enlazar las tablas temáticas con las tablas que almacenan los datos
geográficos de los municipios.
Metodología: Referenciar la tabla geográfica de municipio mediante llave foránea.
Resultados obtenidos: Se unifican las estadísticas de los datos temáticos con los
datos geográficos.
Desarrollar una aplicación Web SIG para visualizar la información geográfica del
departamento Norte de Santander y las variables e indicadores sistematizados por
el observatorio regional paz.
Actividades: Implementar un aplicativo Web que permita crear mapas temáticos
relacionados al comportamiento de un indicador en el departamento de norte de
Santander.
Metodología: Desarrollar, configurar o implementar herramientas que permitan
manipular y visualizar información geográfica relacionada con la información
geográfica del departamento de Norte de Santander.
Resultados obtenidos: Se desarrollo una aplicación que permite consultar
información de indicadores para diagramar el comportamiento de estos en un
mapa
Implementar un plan de pruebas para la aplicación con el fin de garantizar el
cumplimiento de los requisitos planteados por ORDICOP.
Actividades: Desarrollar un plan de pruebas.
Metodología: Realizar pruebas de unidad y pruebas de aceptación para verificar el
funcionamiento del software.
57
Resultados obtenidos: Se implemento un plan de pruebas.
Entregar la aplicación funcionando y con sus respectivos manuales de usuario del
sistema, instalación y configuración.
Actividades: Entregar el aplicativo terminado a satisfacción de ORDICOP con sus
manuales.
Metodología: Instalar la aplicación, escribir los manuales de usuario y los
manuales del sistema.
Resultados obtenidos:
Se instalo la aplicación en el servidor de ORDICOP.
Se elaboraron los manuales de sistema y manuales de usuario.
58
4. METODOLOGIA DE DESARROLLO
Para la realización del proyecto se opto por la metodología de desarrollo ágil
Extreme Programing o XP ya que sus principios básicos: de simplicidad,
comunicación y retroalimentación se adaptan al tamaño del proyecto, tiempo de
duración y cantidad de personas implicadas en su desarrollo, además de ofrecer
formas de adaptación a los cambios planteados por el cliente.
Al igual que otras metodologías agiles, XP sigue el modelo de desarrollo evolutivo
en espiral, lo cual implica; realizar un plan de proyecto basado en versiones del
producto acordadas a partir de funcionalidades concretas, y realizar el desarrollo
para esas funcionalidades concretas.
Una vez entregada la versión del producto cumpliendo con los requisitos (no un
prototipo, sino una versión funcionando), el proceso vuelve a iniciarse con un
conjunto mayor de funcionalidades.
Extreme Programming, puede dividirse en cuatro principios sobre los que se va
iterando hasta que el proyecto ha finalizado (el cliente aprueba el proyecto). Estas
fases o principios son: interacción con el cliente o fase exploratoria, planificación,
diseño, desarrollo y pruebas.
Figura 24. El ciclo de desarrollo en XP
GIBERT GINESTA, Marc. Ingeniería del software de entornos de software libre.
Barcelona: Universidad abierta de Cataluña, 2005.
59
Fase I Fase exploratoria o de Interacción con el cliente. En esta fase el cliente
pasa a ser una parte implicada en el equipo de desarrollo, tiene una gran
interacción con el equipo de programadores, ya que los requerimientos se van
tomando a lo largo del proyecto, se hace posible que este pueda opinar durante el
proceso aportando respuestas a las dudas que van surgiendo por parte del equipo
de desarrollo.
En XP aparece el concepto de Historia de usuario, estas son parecidas a los
casos de uso, son frases cortas escritas por el cliente de máximo tres líneas en las
que se describe un proceso en forma sencilla sin usar tecnicismos. Una vez que
se han escrito, las historias de usuario se utilizaran para elaborar la planificación
de las entregas y los test de aceptación por parte del cliente.
La elaboración de las historias de usuario consta de dos fases.
En la primera fase, el cliente describe con sus propias palabras las características
y es informado de las dificultades técnicas de cada una y las ordena en función de
la prioridad.
En la segunda fase, el equipo técnico será el encargado de catalogar las historias
del cliente y asignarles una duración.
La norma es que cada historia de usuario debe realizarse en un espacio entre una
y tres semanas de programación. Las que requieran menos tiempo serán
agrupadas, y las que necesiten más serán modificadas o divididas.
Fase II Planificación. Una vez que se han obtenido las historias de usuario se
procede a clasificarlas por prioridad y luego se pasa a la planificación de la
próxima (o primera) entrega del producto. En la reunión de planificación se debe
implicar al cliente, al gestor del proyecto y a los desarrolladores. El objetivo será
planificar las siguientes entregas ordenando las historias de usuario que faltan por
desarrollar. Deberá ser el cliente quien dicte el orden de las historias de usuario, y
los desarrolladores quienes estimen el tiempo que les llevaría idealmente en
desarrollarlo. Las historias de usuario se suelen reflejar en tarjetas, que se van
agrupando y clasificando encima de la mesa durante la planificación.
El resultado deberá ser un conjunto de historias que tengan sentido, y que puedan
llevarse a cabo en poco tiempo. Para planificarlo, se puede hacer según dos
60
criterios, basándose en el tiempo hasta la siguiente entrega o en el alcance
(entendido como el número de funcionalidades) que se desea que tenga. Aquí
entra en juego, la velocidad del proyecto, esta velocidad nos servirá para decidir
cuántas historias de usuario vamos a incluir en la próxima entrega. La velocidad
del proyecto es simplemente el número de historias de usuario completada en la
iteración anterior, si se trata de la primera iteración, habrá que hacer una
estimación inicial.
Los desarrolladores convertirán las historias de usuario en tareas (: en lenguaje
técnico) de una duración máxima de tres días ideales de programación cada una.
Se escribirán en tarjetas y se pondrán encima de la mesa para agruparlas,
eliminar las repetidas, y asignarlas a cada programador.
Fase III Diseño. Durante la definición de la solución, así como en la de cada
historia de usuario, es recomendable mantener la simplicidad como clave de éxito
en el diseño, ya que a un diseño simple es más fácil agregar complejidad.
Es muy útil hacer una declaración de metáfora para definir el sistema. Es decir, un
proceso o sistema que todos conozcan y que puedan identificar con el proyecto
que se está desarrollando.
Encontrar una buena metáfora ayudará a tener una visión común, un vocabulario
compartido, generalizando, la metáfora puede sugerir nuevas ideas o soluciones.
En cuanto a la arquitectura, la metáfora dará forma al sistema, identificará los
objetos clave y sugerirá características de las interfaces.
Para el diseño del sistema, se utilizan de tarjetas CRC (clases, responsabilidad y
colaboraciones). En donde cada tarjeta representa un objeto del sistema, con un
nombre que la representa, las responsabilidades que contrae y los objetos con los
cuales colabora, en este fase es muy importante tener en cuenta el concepto de
refactorización el cual consiste en realizar cambios necesarios en las partes de
código que se considere necesario, sin modificar su funcionalidad o su interacción
con el resto del sistema.
Fase IV Desarrollo y pruebas. Antes de empezar a codificar se tienen que hacer
pruebas, es decir; crear test unitarios antes de desarrollar las funcionalidades,
estos test unitarios son pequeños trozos de código que prueban las
funcionalidades de un objeto, de modo que esa prueba pueda incorporarse a un
proceso de pruebas automatizado por lo cual cada vez que se quiera implementar
61
una parte de código, en XP, se tiene que escribir una prueba sencilla, y después
escribir el código para que la pase. Una vez pasada se amplía y se continúa.
Respecto a la integración, se deberá hacer una integración continua, es decir,
cada vez se va integrando pequeños fragmentos de código, para evitar que al
finalizar el proyecto se tenga que invertir grandes esfuerzos en la integración final.
62
5. DESARROLLO DEL PROYECTO
5.1 FASE I EXPLORATORIA
Historias de usuario.
Las historias de usuario no son casos de usos, estas
constituyen una muy útil mediante estas podemos obtener información valiosa
acerca de las necesidades más inmediatas el usuario.
HU-01: Consultar mapa: Permite al usuario confeccionar un mapa temático en
base a estadísticas disponibles en el sistema, ofreciendo algún criterio de
consulta.
HU-02: configurar mapa: El usuario tiene cierto grado de personalización del
mapa, en cuanto a los colores y técnicas de clasificación de datos y tipo de mapa
para la representación.
HU-03: Tipo de mapa: Permite al usuario la opción de crear mapas con gamas de
color o con diagramas de datos.
HU-04: Ver mapa: Es posible que el usuario pueda abrir y trabajar sobre varios
mapas.
HU-05: Mover mapa: Al mapa desplegado es posible aplicarle movimientos, para
poder ver regiones que no sean visibles en la pantalla actual.
HU-06: Navegar mapa: El usuario tiene a su disposición un conjunto de
herramientas que le facilitan la interacción con la imagen del mapa y los datos
asociados a este, tales como acercar o alejar la vista, mover vista, identificar y
restablecer.
HU-07: Registrar usuario: Permite a un usuario ingresar al sistema para consultar
mapas.
63
HU-08: Ingresar al sistema: El sistema solo puede ser accedido si el usuario se ha
registrado previamente.
HU-09: Salir del sistema: Cierra la sesión establecida al ingresar al sistema,
eliminando todos los datos de dicha sesión.
HU-10: Imprimir mapa: Permite al usuario que ha confeccionado un mapa,
guardarlo en varios formatos de imagen.
HU-11: administrar eje temático: Permite a un usuario administrador manejar los
datos de los que conforman un eje temático.
HU-12: administrar variables: Permite a un usuario administrador manejar los
datos de las variables que conforman un eje temático.
HU-13: administrar indicadores: Permite a un usuario administrador manejar los
datos de las indicadores que miden las diferentes variables.
HU-14: Estudio anual: Permite a un usuario administrador vincular el valor de un
indicadores a un municipio por año.
Roles participantes. Dado el tamaño del proyecto, este se compone de un grupo
pequeño de personas. A continuación se hace una descripción de las personas
que están involucradas en el proyecto.
Clientes: esta grupo está conformado por las personas directamente interesadas
en el desarrollo de este.
Ing. Nelson Beltrán G. Ingeniero de sistemas UFPS.
Ing. Claudia Gómez Ll. ingeniera de sistemas ORDICOP.
Director del Proyecto: Ingeniero Nelson Beltrán.
64
Responsables del Seguimiento: Francisco Javier Rada Niño – Omar Argenis
Duarte Maldonado.
Formador del Equipo: Francisco Javier Rada Niño – Omar Argenis Duarte
Maldonado.
Desarrolladores: Francisco Javier Rada Niño – Omar Argenis Duarte Maldonado.
Usuarios del sistema.
Administrador:
Este usuario es quien ingresa información a la base de datos
la cual más tarde será cruzada con la información geográfica para producir un
mapa.
Sus necesidades principales son:
Realizar las operaciones básicas de, inserción, eliminación, actualización y
consulta sobre la base de datos mediante una interfaz.
Acceder de forma segura a la aplicación mediante la asignación de un nombre de
usuario y una contraseña, aparte del perfil de acceso creado en la base de datos.
Visitante:
Este usuario desea obtener información estadística del
departamento, representada en un mapa, visualizar esta información en el visor de
mapas, imprimirla o descargarla a su computador.
Este usuario no necesita tener conocimientos avanzados en sistemas y en
computación, solo informática o computación básica (uso de un navegador).
En síntesis sus necesidades principales son:
Visualizar con facilidad un mapa aprovechando herramientas para: desplazarse
por el mapa, acercar o alejar la vista.
65
Consultar información en el mapa mediante alguna herramienta
Imprimir o descargar mapas.
Registrarse e identificarse en el sistema, para poder utilizar la aplicación.
Tecnologías y herramientas utilizadas. Para el desarrollo del sistema se
determino la necesidad de aplicar un conjunto de tecnologías tales como:
Un servidor de Base de Datos Espacial: el cual nos provee de una estructura de
almacenamiento consistente, atomicidad, persistencia e integridad en los datos,
además de proveernos de capacidades de cálculo y operaciones sobre el conjunto
de datos espaciales.
Un servidor Web: Para manejar las comunicaciones a un alto nivel entre el usuario
final y el proceso que sirve los mapas del lado servidor. Presenta una página Web
la cual contiene el propio mapa y las herramientas necesarias para manipularlo
(acercar, alejar la vista, mover, etc.).
Un servidor de Mapas: Es el mecanismo detrás de los mapas que se presentan en
la Web. El servidor de mapas necesita ser configurado para comunicarse con el
servidor Web para que este pueda producir una imagen apropiada a partir de los
datos geográficos.
PostgreSQL 8.2 + PostGIS 1.3.2 Las bases de datos espaciales proveen de un
almacenamiento extendido, además de proporcionar funciones para la
manipulación de datos espaciales.
Frente a otras soluciones de código abierto como MySQL, PostgreSQL provee un
soporte nativo para tipos de datos espaciales, además del costo de adquisición el
cual es nulo en comparación con las soluciones comerciales. PostgreSQL es un
Sistema Manejador de Bases de Datos Objeto-Relacional de Código Abierto,
desarrollado en la Universidad de California por el Departamento de Ciencias de la
Computación de Berkeley. Es pionero en muchos conceptos que solo han estado
disponibles en algunos Motores de Bases de Datos comerciales desde hace
tiempo. Es compatible con una gran parte del estándar SQL y ofrece muchas
características modernas:
66
Búsquedas complejas.
Integridad referencial.
Disparadores (Triggers).
Vistas.
Integridad de transacciones.
Control de concurrencia multiversion.
PostGIS es una extensión al sistema de base de datos objeto-relacional
PostgreSQL. Permite el uso de objetos GIS. PostGIS es desarrollado por la
empresa Refractions Research Inc. Como un proyecto de investigación en bases
de datos espaciales.
Figura 25. PostgreSQL / PostGIS
PostGIS ofrece una abstracción sobre el modelo de datos vectorial,
implementando tipos de datos que permiten manipular los elementos geométricos
básicos: POINT, POLYGON, LINE, así como otros derivados de la combinación de
estos para representaciones 3D, en particular PostGIS extiende los tipos que ya
existen en PostgreSQL cumpliendo con los estándares OGC (Open Geospatial
Consortium).
67
UMN MapServer. MapServer es un entorno de desarrollo en código abierto (Open
Source Initiative) para la creación de aplicaciones web que utilicen mapas con
datos espaciales ya sean vectoriales o raster, en otras palabras MapServer no es
un SIG, aunque incorpora algunas características básicas inherentes a uno.
MapServer fue diseñado para permitir crear mapas configurables mediante el
mapfile, el cual establece las fuentes de datos y la apariencia del mapa.
Figura 26. MapServer
Sus características principales son:
Ejecución bajo plataformas Linux/Apache y Windows.
Soporte para los formatos vectoriales: shapefiles, PostGIS, ArcSDE, GML y otros
muchos vía OGR.
Soporte para los formatos raster: JPG, PNG, GIF, TIFF/GeoTIFF, EPPL7 y otros
vía GDAL.
Fuentes TrueType.
Soporte para diferentes proyecciones del mapa.
Soporta el etiquetado de geometrías, y trata la colisión de etiquetas.
Soporte para scripting y entornos de desarrollo más populares (PHP, Python, Perl,
Ruby, Java y C#).
68
Totalmente configurable mediante el mapfile.
MapServer trabaja detrás del servidor web, este recibe las peticiones de
generación de mapas y se las pasa a MapServer el cual se encarga de construir el
mapa. MapServer abre todos los orígenes de datos que estén siendo
referenciados, los coloca en capas y genera una imagen ya sea JPEG, GIF, PNG,
etc. con las propiedad definidas en el mapfile y la entrega al servidor web, el cual
la transmite de vuelta al usuario que hizo la solicitud.
Figura 27. Funcionamiento del servidor de mapas MapServer
Quantum GIS. Quantum GIS (o QGIS) es un Sistema de Información Geográfica
(SIG) de código libre para plataformas Linux, Unix, Mac OS y Microsoft Windows.
Era uno de los primeros ocho proyectos de la Fundación OSGeo y en 2008
oficialmente graduó de la fase de incubación. Permite manejar formatos raster y
vectoriales, así como bases de datos. Algunas de sus características son:
Soporte para la extensión espacial de PostgreSQL, PostGIS.
Manejo de archivos vectoriales Shapefile, ArcInfo coverages, Mapinfo, GRASS
GIS, etc.
69
Soporte para un importante número de tipos de archivos raster (GRASS GIS,
GeoTIFF, TIFF, JPG, etc.)
Una de sus mayores ventajas es la posibilidad de usar Quantum GIS como GUI
del SIG GRASS, utilizando toda la potencia de análisis de este último en un
entorno de trabajo más amigable.
Entorno de desarrollo KA-MAP 1.0 Ka-map es un proyecto de código abierto
que provee una API javascript para el desarrollo de aplicaciones web de mapas
con interfaces altamente interactivas usando las características disponibles en los
navegadores modernos. Proporciona un conjunto de elementos tales como:
Movimiento (Panning) interactivo y continuo sin recargar la pagina.
Opciones de navegación con teclado (zooming, panning).
Manejo de vistas (Zooming) a escalas predefinidas.
Barra de escala interactiva, soporte para leyendas y mapas clave.
Control opcional de capas en el lado cliente.
Puesta en cache de imágenes en el lado servidor.
En una aplicación MapServer convencional, cada vez que un usuario realiza una
operación desde la más sencilla (pan) a una compleja (consulta) sobre la interfaz
del mapa, se desencadenan una serie de operaciones, que concluyen con la
presentación de la imagen del mapa.
En Ka-map, MapServer recolecta todos los datos una vez y fragmenta la imagen
en téselas (recuadros) de 200 pixeles de ancho y alto. Cada vez que un mapa es
cargado con Ka-Map en determinada escala, este controla el área exacta y
entrega los téselas para esa área.
70
Figura 28. Partición de imagen utilizando tiled cache
5.2 FASE II PLANIFICACION
Planificación de entregas. En este punto el cliente selecciona las historias de
usuario y las selecciona por prioridad ordenándolas dependiendo por prioridad,
hecho esto los programadores estiman el esfuerzo y la cantidad de tiempo que
será necesario invertir en cada historia.
En base a esta estimación se establece un cronograma y se pacta una fecha para
la próxima entrega.
Prioridad de las historias: La prioridad es establecida por el cliente, obedeciendo a
los siguientes criterios.
Prioridad Alta: La historia de usuario debe ser implementada para cumplir los
objetivos del negocio.
71
Prioridad Media: La historia de usuario tiene un impacto mediano sobre los
objetivos del negocio.
Prioridad Baja: La historia de usuario aumentará la satisfacción del cliente, pero no
está justificada explícitamente.
Las estimaciones son asignadas de acuerdo al esfuerzo de desarrollo de cada
Historia de Usuario, estas estimaciones se trabajan en puntos y cada punto
equivale a 40 horas de trabajo.
Cuadro 4. Asignación de prioridades a las historias de usuario
HISTORIA
HU-01
HU-02
HU-03
HU-04
NOMBRE
Consultar mapa
Configurar mapa
Tipo mapa
Ver mapa
HU-05
HU-06
HU-07
Mover mapa
Navegar mapa
Registrar usuario
HU-08
HU-09
HU-10
HU-11
HU-12
HU-13
HU-14
PRIORIDAD ESTIMACION HORAS
ALTA
3
120
MEDIA
1
40
MEDIA
1
40
MEDIA
1
40
MEDIA
MEDIA
BAJA
1
1
1
40
40
40
Ingresar al sistema
Salir del sistema
Imprimir mapa
BAJA
BAJA
ALTA
0,5
0,5
1
20
20
40
Administrar eje temático
Administrar variables
Administrar indicadores
Estudio anual
ALTA
ALTA
ALTA
ALTA
1
1
1
1
40
40
40
40
Cronograma de entregas. Una vez se ha establecido la prioridad para las
historias de usuario, asignamos una o un grupo de historias dependiendo de su
puntaje a una iteración de modo que no se exceda el plazo de entrega que es de
tres semanas por iteración.
72
SEMANA 15
SEMANA 14
SEMANA 13
SEMANA 12
SEMANA 10
SEMANA 11
ITERACION 5
SEMANA 9
ITERACION 4
SEMANA 8
ITERACION 3
SEMANA 7
SEMANA 6
SEMANA 5
SEMANA 4
SEMANA 3
ITERACION 2
SEMANA 2
HISTORIA
ITERACION 1
SEMANA 1
Cuadro 5. Cronograma de tareas por Iteraciones
HU-01
HU-02
HU-03
HU-04
HU-05
HU-06
HU-07
HU-08
HU-09
HU-10
HU-11
HU-12
HU-13
HU-14
Descripción de las historias de usuario.
Cuando se captura la información
en historias de usuario, esto se hace en las propias palabras del cliente,
posteriormente estas historias se catalogan y se escriben en términos más
formales recogiendo aspectos técnicos según la descripción del analista o el
programador.
73
Formato 6. Descripción de la historia de usuario consultar mapa
Historia de usuario
Numero: 01
Usuario: visitante
Nombre historia: Consultar mapa
Prioridad (:Alta/Media/Baja): ALTA
Puntaje: 3
Iteración: 1
Programador responsable: Francisco Javier Rada
Descripción:
Se proporciona al usuario la capacidad de construir un mapa temático,
partiendo de un conjunto de estadísticas previamente almacenadas en la base
de datos, agrupadas por eje temático (gobernabilidad, derechos humanos,
desarrollo socioeconómico) y clasificadas por variable, indicador y año
respectivamente.
Observaciones:
Cuando el usuario selecciona un valor de la lista, la lista que le sigue debe
cargarse con valores relacionados el seleccionado, mostrando la subcategoría, evitando consultas que no retornen datos.
Formato 7. Descripción de la historia de usuario configurar mapa
Historia de usuario
Numero: 02
Usuario: visitante
Nombre historia: Configurar mapa
Prioridad (:Alta/Media/Baja): MEDIA
Puntaje: 1
Iteración: 2
Descripción:
El usuario tiene cierto grado de personalización del mapa, este puede
configurar el esquema de colores seleccionando un color inicial y un color final
para construir un mapa de coropletas, también puede configurar la capa base
(limite departamento, limite municipio, limite región), también puede
seleccionar un método de clasificación de datos según su criterio (cuantiles,
corte natural o intervalos iguales).
Observaciones:
Se deben programar métodos de clasificación de datos que calculen los
intervalos de corte esto puede ser cuantiles, intervalos iguales y corte natural.
74
Formato 8. Descripción de la historia de usuario tipo de mapa
Historia de usuario
Numero: 03
Usuario: visitante
Nombre historia: Tipo de mapa
Puntaje: 1
Iteración: 2
Descripción:
Permite establecer al usuario la opción de crear mapas tipo coropleta (gamas
de color) para una sola serie de datos o tipo mapa-diagrama (diagramas de
datos) para representar entre 2 y 3 series de datos, los tipos diagramas se
pueden representar en barras o tortas.
Observaciones:
Es necesario evitar que el usuario construya mapas de diagramas con una sola
serie ya que genera una excepción en MapServer.
Formato 9. Descripción de la historia de usuario ver mapa
Historia de usuario
Numero: 04
Usuario: visitante
Nombre historia: Ver mapa
Puntaje: 1
Iteración: 2
Descripción:
Brinda la funcionalidad necesaria para que el usuario pueda crear múltiples
mapas y trabajar con estos simultáneamente, con el fin de brindarle la
posibilidad de comparar y analizar la información de los mapas
Observaciones:
Se deben programar métodos que permitan generar las interfaces de
navegación de mapa automáticamente evitando sobre escritura de valores.
75
Formato 10. Descripción de la historia de usuario mover mapa
Historia de usuario
Numero: 05
Usuario: visitante
Nombre historia: Mover mapa
Puntaje: 1
Iteración: 3
Descripción:
Al mapa desplegado es posible aplicarle movimientos, para poder ver regiones
que no sean visibles en la pantalla actual.
Observaciones:
Esta historia se encuentra previamente implementada en el framework ka-Map,
archivo kaHZoomer.js
Formato 11. Descripción de la historia de usuario navegar mapa
Historia de usuario
Numero: 06
Usuario: visitante
Nombre historia: Navegar mapa
Puntaje: 1
Iteración: 3
Descripción:
El usuario tiene a su disposición un conjunto de herramientas que le facilitan la
interacción con la imagen del mapa y los datos asociados a este, tales como
acercar o alejar la vista, mover vista, identificar y restablecer.
Observaciones:
Esta historia se encuentra previamente implementada en el framework ka-Map.
76
Formato 12. Descripción de la historia de usuario registrar usuario
Historia de usuario
Numero: 07
Usuario: visitante
Nombre historia: Registrar usuario
Prioridad (:Alta/Media/Baja): BAJA
Puntaje: 1
Iteración: 4
Programador responsable: Francisco Javier Rada, Omar Duarte
Descripción:
Permite a un usuario registrarse en el sistema para poder acceder a la
aplicación, el usuario ingresa algunos datos en un formulario y a cambio
obtiene unas credenciales de acceso a la aplicación (login y password) y se le
concede acceso mediante uno de los perfiles de conexión (administrador o
visitante).
Observaciones: Es necesario implementar controles para asegurar la validez
de la contraseña y del correo electrónico.
Formato 13. Descripción de la historia de usuario ingresar al sistema
Historia de usuario
Numero: 08
Usuario: visitante
Nombre historia: Ingresar al sistema
Puntaje: 0,5
Iteración: 4
Descripción:
El sistema solo puede ser accedido si el usuario se ha registrado previamente,
este debe identificarse con su nombre de usuario (login) y su contraseña.
Observaciones:
Es necesario ofrecer un método de recuperación de contraseña en el caso de
que el usuario la olvide.
77
Formato 14. Descripción de la historia de usuario salir del sistema
Historia de usuario
Numero: 09
Usuario: visitante
Nombre historia: Salir del sistema
Puntaje: 0,5
Iteración: 4
Descripción:
Cierra la sesión establecida al ingresar al sistema, eliminando todos los datos
de dicha sesión.
Observaciones:
Es necesario eliminar los datos de sesión como medida de seguridad.
Formato 15. Descripción de la historia de usuario imprimir mapa
Historia de usuario
Numero: 10
Usuario: visitante
Nombre historia: Imprimir mapa
Puntaje: 1
Iteración: 3
Descripción:
Permite al usuario imprimir o guardar un mapa, en varios formatos de imagen y
también obtener un reporte más detallado acompañado de gráficos y la
descripción textual del mapa.
Observaciones:
Se admiten los formatos JPG, PNG, GIF para la imagen del mapa. Formato
PDF para el reporte completo.
78
Formato 16. Descripción de la historia de usuario administrar eje temático
Historia de usuario
Numero: 11
Usuario: Administrador
Nombre historia: administrar eje temático
Puntaje: 1
Iteración: 4
Programador responsable: Omar Duarte
Descripción:
Permite a un usuario administrador manejar los datos de los que conforman un
eje temático, por lo cual debe poder utilizar una interfaz que le permita realizar
operaciones de consulta, inserción, eliminación y actualización sobre un eje
temático
Observaciones:
Debe evitarse la eliminación en cascada.
Formato 17. Descripción de la historia de usuario administrar variables
Historia de usuario
Numero: 12
Nombre historia: Administrar variable
Puntaje: 1
Iteración: 5
Descripción:
Permite a un usuario administrador manejar las variables que representan los
fenómenos estudiados, debe proporcionarse una interfaz que le permita
realizar operaciones de consulta, inserción, eliminación y actualización sobre
una variable vinculada a un eje temático
Observaciones:
Una variable debe estar siempre vinculada a un eje temático
79
Formato 18. Descripción de la historia de usuario administrar indicador
Historia de usuario
Numero: 13
Nombre historia: Administrar indicador
Puntaje: 1
Iteración: 5
Descripción:
Permite a un usuario administrador manejar los indicadores que van a
cuantificar representan las variables, debe proporcionarse una interfaz que le
permita realizar operaciones de consulta, inserción, eliminación y actualización
sobre un indicador de una variable.
Observaciones:
Formato 19. Descripción de la historia de usuario administrar estudio anual
Historia de usuario
Numero: 14
Nombre historia:
Usuario: visitante
Estudio anual
Puntaje: 1
Iteración: 5
Descripción:
Permite agregar el valor de un indicador a un municipio medido para un año.
Debe proporcionarse una interfaz que le permita realizar operaciones de
consulta, inserción, eliminación y actualización.
Observaciones:
Planificación de las iteraciones. Conforme al flujo de trabajo del proyecto se
debe hacer una planificación en iteraciones, que debe ser retocada al cabo de
unas cuantas iteraciones. Ya que en cada iteración hay que realizar la
planificación de la misma, es decir la planificación iterativa.
80
En esta se especifican las historias de los usuarios cuya implementación se
considera primordial y se añaden aquellas que no han pasado las pruebas de
aceptación de anteriores iteraciones. La planificación de una iteración también
hace uso de tarjetas en las que se escribirán tareas, que duraran entre uno y tres
días (la duración la deben decidir los propios desarrolladores), es decir tendrán
una duración de 3 puntos fijos de duración, esto equivale a 120 horas o 3
semanas ideales de programación. Por lo tanto la cantidad de historias asignadas
a una iteración no debe sobrepasar la suma de las estimaciones de las historias.
Cuadro 6. Planificación de iteraciones
Historia
Iteración
1
2
3
4
5
HU-01
HU-02 HU-03 HU-04
HU-05 HU-06 HU-10
HU-07 HU-08 HU-09 HU-11
HU-12 HU-13 HU-014
Primera iteración. En esta iteración se desarrollara la historia HU-01, el desarrollo
de esta historia va a permitir establecer la funcionalidad básica inicial, examinando
que tipo de consultas son las más apropiadas, la interfaz inicial (panel de consulta
e interfaz de presentación de resultados) y una forma apropiada para la
arquitectura además de establecer cómo será la comunicación entre
componentes.
HISTORIA
HU-01
NOMBRE
Consultar mapa
PRIORIDAD
ESTIMACION
ALTA
3
Segunda iteración. Esta iteración extiende la funcionalidad de la Historia de
usuario implementada en la primera iteración, aportando nuevos elementos en las
interfaces graficas de usuario orientadas a proveer herramientas para la
personalización del resultado de consulta (imagen de mapa), e interfaces entre
componentes para el despliegue de datos (panel de consulta y navegador de
mapa).
81
HISTORIA
HU-02
HU-03
HU-04
NOMBRE
Configurar mapa
Tipo mapa
Ver mapa
PRIORIDAD
MEDIA
MEDIA
MEDIA
ESTIMACION
1
1
1
Tercera iteración. La tercera iteración se centra en extender la funcionalidad de
la HU-04 agregando elementos de desplazamiento (HU-05) y vista de zoom (HU06) además de introducir una funcionalidad totalmente nueva como la herramienta
para impresión de mapa en varios formatos
HISTORIA
HU-05
HU-06
HU-10
NOMBRE
Mover mapa
Navegar mapa
Imprimir mapa
PRIORIDAD
MEDIA
MEDIA
ALTA
ESTIMACION
1
1
1
Cuarta iteración. En esta iteración se introducen las funcionalidades relacionadas
con el manejo de la seguridad, los perfiles de acceso y de identificación de
usuarios. Y se comienza a desarrollar la interfaz para la administración de datos
temáticos.
HISTORIA
HU-07
HU-08
HU-09
HU-11
NOMBRE
PRIORIDAD ESTIMACION
Registrar usuario
BAJA
1
Ingresar al sistema
BAJA
0,5
Salir del sistema
BAJA
0,5
Administrar eje temático
ALTA
1
Quinta iteración. En esta iteración se extiende la interfaz de administración de
datos agregando elementos que permiten gestionar la información de los
indicadores.
82
HISTORIA
NOMBRE
PRIORIDAD
ESTIMACION
HU-12
Administrar variables
ALTA
1
HU-13
Administrar indicadores
ALTA
1
HU-14
Estudio anual
ALTA
1
Planificación de las tareas. Una vez se han organizado las historias de usuario
por iteraciones, es necesario especificar las tareas que han de llevarse a cabo
para lograr desarrollar la historia de usuario propuesta, en el siguiente cuadro se
establecen el conjunto de tareas a desarrollar y la asignación del puntaje (1 punto
= 40 horas).
Las tareas se han clasificado según el tipo de trabajo que debe hacerse y se
dividen en:
Documentación: tareas de investigación, lectura y adquisición de información.
Adaptación: tareas que implican extensión de funcionalidad a elementos
previamente
desarrollados,
adecuación,
instalación,
configuración,
compatibilización.
Desarrollo: tareas que implican el desarrollo de elementos totalmente nuevos.
Verificación: tareas que implican pruebas de funcionamiento a elementos
desarrollados o modificados.
83
Cuadro 12. Planificación de las tareas
Tarea
Descripción tarea
Iteración
Historia
Puntos
Horas
Total
HU
T-01
T-02
T-03
T-04
T-05
T-06
Estudio API php/mapscript
Migrar datos
interfaz de datos
generar mapfiles
Interfaz grafica de consulta
Probar mapfiles
Estudio métodos estadísticos de
clasificación de datos
Herramienta de cálculo intervalos de
datos.
Herramienta de selección de color
Verificación de intervalos
Agregar soporte para mapa diagrama
y mapa coropleta
Permitir selección de tipo de mapa
Interfaz para creación de mapa
diagrama
pruebas de funcionamiento
Estudio framework ka-map
Conectar el panel de consulta con el
navegador de mapas
configurar extensiones limite de los
mapas
implementar mover imagen de mapa
implementar herramienta identificar
implementar herramientas zoom in zoom out
implementar mapa de referencia
implementar Tabla de contenido
registro de usuario
interfaz de registro de usuario
autenticación de usuario
cerrar sesión y eliminación de datos
de sesión
descargar imagen mapa
I
I
I
I
I
I
HU-01
HU-01
HU-01
HU-01
HU-01
HU-01
0,2
0,1
0,4
1
1
0,3
8
4
16
40
40
12
120
II
HU-02
0,3
12
II
II
II
HU-02
HU-02
HU-02
0,4
0,1
0,2
16
4
8
II
II
HU-03
HU-03
0,4
0,2
16
8
II
II
II
HU-03
HU-03
HU-04
0,2
0,2
0,2
8
8
8
II
II
HU-04
HU-04
0,6
0,2
24
8
III
III
III
III
HU-05
HU-05
HU-05
HU-06
0,4
0,4
0,2
0,3
16
16
8
12
III
III
III
III
IV
IV
IV
IV
HU-06
HU-06
HU-06
HU-06
HU-07
HU-07
HU-07
HU-08
0,1
0,1
0,3
0,2
0,4
0,4
0,2
0,5
4
4
12
8
16
16
8
20
IV
III
HU-09
HU-10
0,5
0,1
20
4
T-01
T-02
T-03
T-04
T-01
T-02
T-03
T-04
T-01
T-02
T-03
T-01
T-02
T-03
T-01
T-02
T-03
T-04
T-05
T-01
T-02
T-03
T-01
T-01
T-01
84
40
40
40
40
40
40
20
20
Continuación. Cuadro 12. Planificación de las tareas
Total
HU
Tarea
Descripción tarea
Iteración
Historia
Puntos
Horas
T-02
T-03
T-04
T-01
T-02
diagramas de datos
generar mapa en pdf
interfaz de datos para eje temático
formularios CRUD
interfaz de datos para manejo de
variables
formularios CRUD
indicadores
formularios CRUD
estadística anual
formularios CRUD
III
III
III
IV
IV
HU-10
HU-10
HU-10
HU-11
HU-11
0,2
0,5
0,2
0,2
0,6
8
20
8
16
24
40
V
V
HU-12
HU-12
0,2
0,6
16
24
40
V
V
HU-13
HU-13
0,4
0,6
16
24
40
V
V
V
HU-14
HU-14
HU-14
0,2
0,6
0,2
8
24
8
T-01
T-02
T-01
T-02
T-01
T-02
T-03
TOTAL HORAS
40
40
600
Descripción de tareas realizadas para el desarrollo de la historia de usuario HU01.
Tarea
T-01
T-02
T-03
T-04
Duración(Horas)
8
4
16
40
T-05
T-06
40
12
85
Tarea
Numero tarea:
T-01
Numero historia:
HU-01
Nombre tarea:
Estudio API php/MapScript
Tipo tarea:
Documentar
Puntos estimados:
0,2
Programador responsable:
Francisco Rada, Omar Duarte
Descripción:
Mediante esta tarea se debe obtener conocimiento sobre al API Mapscript
para el lenguaje PHP, en aspectos como: carga de Mapfile, generación
elementos gráficos, metadatos, sistemas de proyecciones, programación de
layers, etiquetas, estilos y generación de Mapfile.
Tarea
Numero tarea:
T-02
Numero historia:
HU-01
Nombre tarea:
migrar datos
Tipo tarea:
Adaptación
Puntos estimados:
0,1
Descripción:
Utilizar la herramienta spit (:shp2pgsl) del programa QUANTUM GIS para
migrar los datos geográficos a la base de datos de indicadores de ORDICOP.
86
Tarea
Numero tarea:
T-03
Numero historia:
HU-01
Nombre tarea:
interfaz de datos
Tipo tarea:
programación
Puntos estimados:
0,4
Descripción:
Se programa una interfaz que permite acceder a los datos en la base de datos
de indicadores.
Tarea
Numero tarea:
T-04
Numero historia:
HU-01
Nombre tarea:
generar Mapfile
Tipo tarea
Desarrollo
Puntos estimados:
1
Programador responsable: Francisco Rada, Omar Duarte
Descripción:
Se programa una clase que permite generar objetos mapfile y guardarlos en un
archivo de texto
87
Tarea
Numero tarea:
T-05
Numero historia:
HU-01
Nombre tarea:
Interfaz grafica de consultas
Tipo tarea
Desarrollo
Puntos estimados:
1
Descripción:
Se crea una interfaz grafica de usuario que permite buscar información en la
base de datos de indicadores para generar una consulta que proporcione datos
a la clase generadora de Mapfile.
Tarea
Numero tarea:
T-06
Nombre tarea:
Probar mapfiles
Numero historia:
HU-01
Tipo tarea
Verificación
Puntos estimados:
0,3
Descripción:
Se verifica que se genere el archivo mapfiles y que la sintaxis de este sea
correcta en otras palabras que al ejecutar el mapfile este genere una imagen
del mapa.
88
Tarea
T-01
T-02
T-03
T-04
Duración(:Horas)
12
16
4
8
Tarea
Numero tarea:
Numero historia:
T-01
HU-02
Nombre tarea:
Estudio de métodos estadísticos de clasificación de datos
Tipo tarea:
Puntos estimados:
Documental
0,3
Descripción:
Se revisa la conceptualización y formulación matemática de los métodos de
clasificación estadística de datos. Se revisan conceptos como: desviación
estándar, media, mediana, moda, intervalos iguales, cuantiles, corte natural.
Tarea
Numero tarea:
Numero historia:
T-02
HU-02
Nombre tarea:
Herramienta de cálculo de intervalos de datos
Tipo tarea
Puntos estimados:
adaptación
0,4
Descripción:
Se desarrolla la funcionalidad para calcular los intervalos de datos a partir de
los datos proveídos por la interfaz de datos. Estos intervalos calculados hacen
parte del mapfile.
89
Tarea
Numero tarea:
T-03
Numero historia:
HU-02
Nombre tarea:
Herramienta de selección de color
Tipo tarea:
Adecuación
Puntos estimados:
0,1
Descripción:
Se configura la herramienta de selección de color en la interfaz grafica de
usuario desarrollada en la tarea T-05 de la HU-01 “interfaz de consulta de
mapa” y se agrega el soporte en el generador de mapfiles para configurar
estilos de color en los layers.
Tarea
Numero tarea:
T-04
Numero historia:
HU-02
Nombre tarea:
Verificar intervalos
Tipo tarea
Verificación
Puntos estimados:
0,2
Descripción:
Se verifica que los intervalos de datos calculados sean correctos en el sentido
de que estos se ajusten a la distribución de los datos.
90
Tarea
T-01
T-02
T-03
T-04
Duración(:Horas)
16
8
8
8
Tarea
Numero tarea:
Numero historia:
T-01
HU-03
Nombre tarea:
Agregar soporte para mapa diagrama
Tipo tarea
Puntos estimados:
Desarrollo
0,4
Descripción:
Se obtienen las estadísticas que poseen más 2 dos valores en el tiempo (año),
para generar un mapa con diagramas.
Tarea
Numero tarea:
Numero historia:
T-02
HU-03
Nombre tarea:
Permitir selección de tipo de mapa
Tipo tarea
Puntos estimados:
Adaptación
0,2
Descripción:
se proporciona un elemento en la interfaz grafica de usuario de consulta de
mapa para crear uno de los tipos de mapas soportados
91
Tarea
Numero tarea:
T-03
Numero historia:
HU-03
Nombre tarea:
Interfaz para creación de mapa diagrama
Tipo tarea
Desarrollo
Puntos estimados:
0,2
Descripción:
se proporciona una interfaz para que el usuario decida el numero de series
(entre 2 y 3) y el año de comienzo en un mapa diagrama, ofrece dos tipos de
diagrama (Barra o torta)
Tarea
Numero tarea:
T-04
Numero historia:
HU-03
Nombre tarea:
Pruebas de funcionamiento
Tipo tarea
verificación
Puntos estimados:
0,2
Descripción:
Se escriben las pruebas unitarias necesarias para la aceptación de los
elementos de programa desarrollados durante la iteración 2.
92
Tarea
T-01
T-02
T-03
Duración(Horas)
8
24
8
Tarea
Numero tarea:
T-01
Numero historia:
HU-04
Nombre tarea:
Estudio framework ka-map
Tipo tarea
documentación
Puntos estimados:
0,2
Descripción:
Revisar el API de la librería ka-map, que permitirá implementar las
herramientas de visualización y manipulación para la cartografía
Tarea
Numero tarea:
Numero historia:
T-02
HU-04
Nombre tarea:
Conectar el panel de consulta con el navegador de mapas
Tipo tarea
Puntos estimados:
Adaptación
0,6
Descripción:
Se muestra la consulta de construcción del mapa en una ventana emergente
que contiene la imagen del mapa fragmentada en teselas.
93
Tarea
Numero tarea:
T-03
Nombre tarea:
Tipo tarea
Numero historia:
HU-04
Puntos estimados:
0,2
Descripción:
Se escriben las pruebas necesarias para validar la creación de la cache del
mapfile y la carga del mapfile en ka-map.
Tarea
T-01
T-02
T-03
Duración(Horas)
16
16
8
Tarea
Numero tarea:
Numero historia:
T-01
HU-05
Nombre tarea:
configurar extensión limite de mapa
Tipo tarea
Puntos estimados:
Adaptación
0,4
Descripción:
Se establecen las escalas mínima y máxima para visualización del mapa, en el
visor ka-map de cartografía.
94
Tarea
Numero tarea:
T-02
Numero historia:
HU-05
Nombre tarea:
configurar mover imagen de mapa ( herramienta pan)
Tipo tarea
Adaptación
Puntos estimados:
0,4
Descripción:
Se configura la herramienta pan que permite mover el lienzo del mapa,
cargando solo las teselas necesarias.
Tarea
Numero tarea:
T-03
Numero historia:
HU-05
Nombre tarea:
Tipo tarea
Verificación
Puntos estimados:
0,2
Descripción:
Se verifican la coherencia de la escala, y la coherencia de las teselas
enviadas al lienzo del mapa, y el tamaño de las teselas.
95
Tarea
T-01
T-02
T-03
T-04
Duración(:Horas)
12
4
4
12
Tarea
Numero tarea:
Numero historia:
T-01
HU-06
Nombre tarea:
configurar herramienta identificar
Tipo tarea
Puntos estimados:
Adaptación
0,3
Descripción:
Se configura la herramienta identificar áreas del mapa, permitiendo consultar
información posando el cursor del mouse sobre la imagen del mapa.
Tarea
Numero tarea:
Numero historia:
T-02
HU-06
Nombre tarea:
configurar herramienta mapa de referencia
Tipo tarea
Puntos estimados:
Adaptación
0,1
Descripción:
Se diseñan las imágenes de mapa de referencia y se establece la extensión
en relación a la escala de la imagen del mapa (EXTENT), se establece el
mapa de referencia en la interfaz de navegación de cartografía.
96
Tarea
Numero tarea:
Numero historia:
T-03
HU-06
Nombre tarea:
configuración de la TDC (:tabla de contenido)
Tipo tarea
Adaptación
Puntos estimados:
0,3
Descripción:
Se establece la Tabla de contenido que permite visualizar el detalle (tipo capa,
nombre capa) de las capas (layers) que componen el mapa y que permiten
manipular las capas (opacar, apagar, cambiar de posición).
Tarea
Numero tarea:
T-04
Numero historia:
HU-06
Nombre tarea:
Tipo tarea
Verificación
Puntos estimados:
0,2
Descripción:
Se verifica el funcionamiento de las herramientas configuradas (identificar,
mapa de referencia, TDC)
97
Tarea
T-01
T-02
T-03
Duración(:Horas)
16
16
8
Tarea
Numero tarea:
Numero historia:
T-01
HU-07
Nombre tarea:
registro de usuario
Tipo tarea
Puntos estimados:
Desarrollo
0,4
Descripción:
Se debe consultar y guardar los datos del usuario que desea utilizar la
aplicación de consulta de mapas.
Tarea
Numero tarea:
T-02
Nombre tarea:
interfaz de registro de usuario
Tipo tarea
Numero historia:
HU-07
Puntos estimados:
0,4
Descripción:
se proporciona una interfaz grafica de usuario para que los visitantes se
registren y puedan acceder a la aplicación (:interfaz de consulta de mapa)
98
Tarea
Numero tarea:
T-03
Nombre tarea:
Tipo tarea
Verificación
Descripción:
Se verifica el registro de usuario.
Numero historia:
HU-07
Puntos estimados:
0,1
Tarea
Duración(:Horas)
T-01
20
Tarea
Numero tarea:
Numero historia:
T-01
HU-08
Nombre tarea:
autenticación de usuario
Tipo tarea
Puntos estimados:
Desarrollo
0,5
Descripción:
Se debe validar el acceso del usuario a la aplicación y se le debe conceder
una sesión en caso de que la validación sea acertada.
99
Tarea
Duración(:Horas)
T-01
20
Tarea
Numero tarea:
Numero historia:
T-01
HU-09
Nombre tarea:
cerrar sesión
Puntos estimados: 0,5
Tipo tarea
Descripción:
Eliminar los datos de sesión de usuario, y direccionar a este fuera de la
aplicación.
Tarea
T-01
T-02
T-03
T-04
Duración(:Horas)
4
8
20
8
100
Tarea
Numero tarea:
T-01
Numero historia:
HU-10
Nombre tarea:
descargar imagen de mapa
Tipo tarea
Desarrollo
Puntos estimados:
0,1
Descripción:
Permitir al usuario guardar la vista actual de la imagen del mapa, en formato de
imagen JPG, PNG o GIF.
Tarea
Numero tarea:
T-02
Numero historia:
HU-10
Nombre tarea:
diagrama de datos
Tipo tarea
Desarrollo
Puntos estimados:
0,2
Descripción:
Generar un diagrama de barras con los datos de la consulta de mapa del
usuario y adicionar este grafico al reporte PDF.
101
Tarea
Numero tarea:
Numero historia:
T-03
HU-10
Nombre tarea:
generar mapa en pdf
Tipo tarea
Puntos estimados:
Desarrollo
0,5
Descripción:
Permitir al usuario guardar el mapa generado en archivo pdf, con un formato de
documento que muestre el titulo, la leyenda, la imagen del mapa, imagen de
mapa referencia, escala, sistema de referencia espacial, diagrama de barras y
tabla de datos.
Tarea
Numero tarea:
T-04
Numero historia:
HU-10
Nombre tarea:
Tipo tarea
Verificación
Puntos estimados:
0,2
Descripción:
Comprobar la generación correcta de los informes en pdf y las imágenes de
mapa solicitados por el usuario
102
Tarea
Duración(Horas)
T-01
T-02
16
24
Tarea
Numero tarea:
Numero historia:
T-01
HU-11
Nombre tarea:
Interfaz de datos para eje temático.
Tipo tarea
Puntos estimados:
Desarrollo
0,4
Descripción:
Proporcionar una interfaz de datos que permita manipular los datos
relacionados a la tabla eje en la base de datos de indicadores.
Tarea
Numero tarea:
Numero historia:
T-02
HU-11
Nombre tarea:
implementar formularios CRUD
Tipo tarea
Puntos estimados:
Desarrollo
0,6
Descripción:
Proporcionar una interfaz grafica de usuario que permita al administrador
manejar la información del eje temático.
103
Tarea
Duración(:Horas)
T-01
T-02
16
24
Tarea
Numero tarea:
Numero historia:
T-01
HU-12
Nombre tarea:
interfaz de datos para manejo de variables
Tipo tarea
Puntos estimados:
Desarrollo
0,2
Descripción:
relacionados a la tabla de variables en la base de datos de indicadores.
Tarea
Numero tarea:
Numero historia:
T-02
HU-12
Nombre tarea:
Tipo tarea
Puntos estimados:
Desarrollo
0,6
Descripción:
manejar la información de las variables socioeconómicas.
104
Tarea
T-01
T-02
Duración(:Horas)
16
24
Tarea
Numero tarea:
Numero historia:
T-01
HU-13
Nombre tarea:
interfaz de datos para manejo de indicadores
Tipo tarea
Puntos estimados:
Desarrollo
0,2
Descripción:
almacenados en la tabla indicadores en la base de datos.
Tarea
Numero tarea:
Numero historia:
T-02
HU-13
Nombre tarea:
Tipo tarea
Puntos estimados:
Desarrollo
0,6
Descripción:
manejar la información de los indicadores de variables.
105
Tarea
T-01
T-02
T-03
Duración(:Horas)
8
24
8
Tarea
Numero tarea:
T-01
Numero historia:
HU-14
Nombre tarea:
interfaz de datos para manejo de estadística anual
Tipo tarea
Desarrollo
Puntos estimados:
0,2
Descripción: Proporcionar una interfaz de datos que permita manipular los
datos almacenados en la tabla estudio_anual en la base de datos de
indicadores.
Tarea
Numero tarea:
T-02
Numero historia:
HU-14
Nombre tarea:
Tipo tarea
Puntos estimados:
Desarrollo
0,6
Descripción: Proporcionar una interfaz grafica de usuario que permita al
administrador manejar la información de los indicadores en la tabla
estudio_anual.
106
Tarea
Numero tarea:
T-03
Numero historia:
HU-14
Nombre tarea:
Puntos estimados:
Verificación
0,2
Descripción:
Realizar pruebas de verificación sobre los elementos desarrollados para las
historias HU-11, HU-12, HU-13, HU-14
Tipo tarea
107
6. CONCLUSIONES
Con la realización del presente proyecto se consiguió implementar un producto
que satisface los requerimientos planteados por ORDICOP, producto que se ha
denominado WebGIS VI el cual es una aplicación de Sistema de Información
Geográfico basada en la web, que combina diferentes tecnologías (MapServer,
PHP/MapScript, AJAX, PostGIS), para la elaboración de mapas temáticos del
Norte de Santander. Que tiene las características deseables de una aplicación
web moderna, como: alta interacción gracias a AJAX, un bajo costo de
implementación y alta usabilidad ya que los usuarios no necesitan aprender
extensos manuales.
WebGIS VI que quiere decir: sistema de información geográfico para variables e
indicadores, es una herramienta útil tanto para el Observatorio como para la
comunidad Norte santandereana, ya que permite evaluar factores clave de las
bases socioeconómicas del Departamento, trasladando a un mapa el valor del de
una serie de variables estadísticas, para poder explicar de una manera muy visual
como afecta la incidencia de dichas variables sobre el territorio.
Con la utilización de este tipo de aplicaciones SIG en internet ya sea para cubrir
funciones de análisis estadístico o para compartir información geográfica se
proporciona un medio para que la gente pueda obtener datos e información
geográfica elaborada de gran calidad, mediante procesos automatizados que de
otra forma, dadas las limitaciones tecnológicas, organizacionales y de
capacitación, serian difíciles de conseguir y elaborar.
108
7. RECOMENDACIONES
Posterior al proceso de desarrollo se plantearon posibles funcionalidades que se
podrían aplicar al proyecto en un futuro, algunas de ellas:
Utilizar un Software estadístico robusto como R-Statistical System: R- proyect es
un software de código abierto que ofrece múltiples capacidades de cálculo y
funciones de estadística sobre datos que pueden estar almacenados en diversas
fuentes, incluyendo la capacidad de interoperar con datos espaciales en
PostgreSQL. Este sistema proveería de mayores capacidades de cálculo así como
de precisión a la hora de realizar estimaciones sobre los indicadores.
Permitir al usuario realizar operaciones espaciales como unión e intersección
sobre varias capas: esta nueva funcionalidad le proporcionaría al usuario nuevas
capacidades de análisis al combinar información de capas de datos de diferentes
indicadores y de diferentes ejes temáticos que le permita observar relaciones entre
variables o analizar causas y efectos entre estas, por ejemplo un usuario podría
ver un mapa de un indicador de violencia combinado con un indicador de pobreza.
Ofrecer consultas a nivel veredal: se podría agregar información temática referente
al ámbito veredal y relacionar esta con la cartografía que ya existe en la base de
datos.
Obtener información desde otras fuentes de datos: conectarse a bases de datos
de otras organizaciones.
Descargar la cartografía en GML, SHP o KML para usuarios avanzados: esta
herramienta seria perfecta para aquellos usuarios que poseen conocimientos en
software SIG y quisieran ampliar el análisis de la información en su estación de
trabajo personal.
109
BIBLIOGRAFÍA
BECK, Kent. Extreme programing explained. Florida: Addison-wesley, 1999. 224 p.
BOSQUE SENDRA, J.
Hall, 1997. 345 p.
Sistemas de información geográfica.
Madrid: Prentice
GIBERT GINESTA, Marc. Ingeniería del software de entornos de software libre.
Barcelona: Universidad abierta de Cataluña, 2005. 326 p.
MESA ARTEAGA, Maria Silvana. Instalación y configuración de un servicio de
mapas online y desarrollo de una interfaz web que permita la visualización de
información geográfica de la ciudad de San José de Cúcuta sobre Internet. San
José de Cúcuta, 2004. 321 p. Trabajo de grado (Ingeniero de Sistemas).
Universidad Francisco de Paula Santander.
Facultad de Ingeniería.
Departamento de Sistemas.
MITCHELL, Tyler. Web mapping illustrated. New York: O`reilly, 2006. 368 p.
MORENO JIMÉNEZ, Antonio. Sistemas y análisis de la información geográfica,
Madrid: Alfaomega, 2006. 940 p.
OBSERVATORIO REGIONAL PARA EL DESARROLLO INTEGRAL Y LA
CONVIVENCIA PACÍFICA DE NORTE DE SANTANDER. Información general del
observatorio de paz. San José de Cúcuta: ORDICOP, 2009. 15 p.
PARRA SÁNCHEZ, Rodolfo. Sistemas de información geográfica base de la
gestión ambiental. Bogotá: Universidad Nacional de Colombia, 1997. 356 p.
ROBINSON, Arthur. Elementos de cartografía. Madrid: John Wiley, 1995. 734 p.
SILBERSCHATZ, Abraham. Fundamentos de base de datos. México: Prentice
Hall, 2003. 564 p.
110
ANEXOS
111
Anexo A. Fase III - diseño
Formulación de la metáfora del sistema. La metáfora del sistema es la visión
que se tiene del funcionamiento del sistema cuando este aun no ha sido
desarrollado, es un panorama que describe la funcionalidad del sistema por parte
del usuario, la siguiente es la definición de la metáfora del sistema:
WebGIS VI, es una aplicación Web a la cual se accede a través de Intranet o
Internet; es un sistema que posibilita la creación y visualización de mapas
temáticos del Departamento Norte de Santander, permitiendo observar la
incidencia de fenómenos sociales, económicos y de derechos humanos en un
mapa.
Arquitectura. Anteriormente se había referido a la metáfora como un instrumento
que permite
identificar los objetos clave y determinar ciertos aspectos
característicos de las interfaces. La metáfora da una forma inicial para la
arquitectura del sistema, esta brinda unas pautas y unas guías básicas acerca de
cómo va a ser la estructura, el funcionamiento y la interacción entre las partes del
software.
Forma para la arquitectura.
Cuando se escoge una forma para la arquitectura
se debe tener en cuenta, la metáfora, los objetivos trazados para el sistema, los de
tipo funcional, como mantenimiento, flexibilidad e interacción con otros sistemas
de información. De igual forma las restricciones derivadas de las tecnologías
disponibles para implementar el sistema. En este aspecto unas arquitecturas son
más recomendables de implementar con ciertas tecnologías mientras que otras
tecnologías no son aptas para determinadas arquitecturas.
Para este caso se opto por aplicar una forma de arquitectura de tres capas, en
este enfoque el que el objetivo primordial es la separación de la lógica de negocios
de la lógica de diseño, separar la capa de datos de la capa de presentación al
usuario. La ventaja principal de este enfoque es que el desarrollo se puede llevar a
cabo en varias capas y en caso de que se deba aplicar algún cambio, sólo se
aplica el cambio a la capa referida.
112
Arquitectura de tres capas de la aplicación.
Capa de presentación: Constituye la interfaz entre el usuario humano y
sistema, esta capa comunica la información al usuario y actúa como receptor,
capturar la información del usuario, realizando durante este proceso el filtrado y
validación del formato de los datos de entrada. Esta capa se comunica solo con
capa de negocio de forma directa.
el
al
la
la
En el caso de WebGIS VI dado que se trata de una aplicación web, esta capa está
constituida por el navegador de Internet del usuario (Internet Explorer, Mozilla
Firefox, etc.), en un nivel distinto.
Capa de negocio: Recibe este nombre porque es en esta capa donde se
establecen todas las reglas del negocio que deben cumplirse, esta capa se
comunica con la capa de presentación, para recibir las solicitudes y presentar los
resultados, y con la capa de datos, para solicitar al gestor de base de datos para
almacenar o recuperar datos de él. También se consideran aquí los programas de
aplicación.
Para la aplicación esta capa está representada por el servidor web Apache el cual
contiene los scripts de servidor en PHP y por otra parte el API MapScript que
permitirá atender las peticiones de generación de objetos geográficos y
transformar estos en imágenes de mapa.
113
Capa de datos: es donde residen los datos y es la encargada de acceder a los
mismos. Está formada por el gestor de bases de datos PostgreSQL extendido
espacialmente con PostGIS, que realiza todo el almacenamiento de datos, recibe
solicitudes de almacenamiento y recuperación de información desde la capa de
negocio.
Elementos que conforman la arquitectura de WebGIS VI
Patrón de diseño MVC. Un patrón de software es una solución generalizada a un
problema de diseño, un patrón se crea para dar respuesta a problemas comunes
en el desarrollo de software y el diseño de sus interfaces, ya que se aplico una
forma de arquitectura por capas, se escogió un patrón de diseño que se adapta a
esta, el patrón MVC (:Modelo-Vista-Controlador).
La forma más sencilla de implementar este patrón es pensando en capas, como
regla, los accesos a la base de datos se hacen en el modelo, la vista y el
controlador no deben de saber si se usa o no una base de datos. El controlador es
el que decide que vista se debe de imprimir y que información es la que se envía.
De esta forma vemos como cada parte de la arquitectura queda separa por cada
capa, controlándose la comunicación entre los componentes.
114
El patrón MVC
•
El Modelo representa la información con la que trabaja la aplicación, es decir,
su lógica de negocio.
•
La Vista transforma el modelo en una página web que permite al usuario
interactuar con ella.
•
El Controlador se encarga de procesar las interacciones del usuario y realiza
los cambios apropiados en el modelo o en la vista.
Vista de procesos. Modelar el proceso de negocio es una parte esencial de
cualquier proceso de desarrollo de software. Permite al analista capturar el
esquema general y los procedimientos que gobiernan el negocio. Este modelo
provee una descripción de dónde se va a ajustar el sistema de software
considerado dentro de la estructura organizacional y de las actividades habituales.
También provee la justificación para la construcción del sistema de software al
capturar las actividades manuales y los procedimientos automatizados habituales
que se incorporarán en nuevo sistema, con costos y beneficios asociados.
115
Descripción del Ambiente de negocio del sistema actual:
Para lograr un
buen resultado en la fase de recopilación de requerimientos es bueno conocer el
funcionamiento actual del negocio, esto se hace para poder ajustar el producto a
la estrategia de trabajo de la organización así mismo posibilita la reutilización de
procesos y medios tecnológicos lo cual va a redundar en un menor costo de
implantación. A continuación se realiza una descripción del flujo trabajo en los
procesos que se relacionan con el objetivo del producto:
a) Cada Eje Consultor interno del Observatorio se encarga de entregar la
información organizada de los indicadores que le corresponde según su
temática o su estudio, esto para cada uno de los municipios con los que trabaja
el Observatorio Regional de Paz.
b) El Ingeniero de Sistemas de ORDICOP recibe esta información de los Ejes
Consultores y la exporta a una base de datos en PostgreSQL para la
alimentación de la misma.
c) Esta información que se encuentra en una base de datos es usada por el
Grupo Técnico de ORDICOP para producir mapas o gráficos que señalen las
dinámicas de trascendencia y de análisis de los diferentes indicadores, ya que
se maneja información desde 1997 para 15 municipios de Norte de Santander.
d) La oficina de Planeación Departamental de Norte de Santander por medio de
un convenio interinstitucional entre La Gobernación de Norte de Santander, La
Universidad francisco de Paula Santander y ORDICOP está comprometida a
entregar al Ingeniero a cargo del Sistema de Información Cartográfico de
ORDICOP, bases de datos de información Cartográfica del Departamento.
e) El Ingeniero de Sistemas de ORDICOP recibe esta información, la trata y la
almacena en como proyecto utilizando el Software ArcView que tiene el
Observatorio Regional de Paz Norte de Santander.
f) El Ingeniero de Sistemas de ORDICOP convierte los mapas que tiene en
formato .SHP en formato .JPG y envía en un CD al Administrador de la página
Web de ORDICOP para que los publique en la sección de mapas, esto con el
fin de mostrarlos y ponerlos al servicio de la comunidad.
116
Diagrama BPM para el proceso de elaboración de cartografía
Vista estática.
Diagrama conceptual: La realización del diagrama de clases está en la
frontera entre el análisis y el diseño. Probablemente es el diagrama UML más
conocido, y permite identificar la estructura de clases del sistema incluyendo las
propiedades y métodos de cada clase. Este diagrama es una vista de alto nivel
que permite modelar los conceptos en el dominio del problema.
117
Diagrama conceptual inicial
Diagrama de clases:
El diagrama de Clases captura la estructura lógica del
sistema - las clases y cosas que constituyen el modelo -. Es un modelo estático,
describiendo lo que existe y qué atributos y comportamiento tiene, más que cómo
se hace algo. Los diagramas de Clases son los más útiles ya que dan una visión
de los aspectos estáticos del sistema, permitiendo realizar la abstracción de un
dominio formalizar el análisis de conceptos, definir una solución de diseño y
construir componentes de software.
Clases de la primera Iteración.
Clase dataConnector: esta clase extiende a la capa de base de datos abstraída
en la librería ADODB, esta clase trata todos los accesos a la base de datos de
indicadores. Implementa solo métodos de consulta de datos.
118
Clase dataConnector
Resultado de Prueba unitaria para la clase dataConnector
Resultado de la prueba para la clase dataConnector:
Test completos: 15 pasados, 0 fallos, 0 excepciones.
119
Prueba unitaria testDataConnector
Clase mapaTematico: esta clase contiene toda la lógica que permite generar
archivos mapfile que más tarde serán transformados en mapas temáticos cuando
sean convertidos en imágenes.
120
Clase mapaTematico.
Resultado de Prueba unitaria para la clase mapaTematico
121
Resultado de la prueba para la clase mapaTematico:
Prueba unitaria testMapaTematico.
Clases de la segunda iteración. Durante esta iteración se extiende la
funcionalidad de la clase mapaTematico agregando las funcionalidades para la
generación de los tipos de mapa coropleta y mapa-diagrama, además se agrega la
funcionalidad para calcular los intervalos estadísticos. También se programa la IU
para el panel de elaboración de mapas en javascript.
Clases de la tercera iteración.
Clase dataChart: esta clase contiene la lógica para recuperar los datos que se
utilizaran para crear un diagrama de barras, que se agregara el reporte PDF.
122
Clase dataChart.
Resultado de Prueba unitaria para la clase dataChart
Resultado de la prueba para la clase dataChart:
123
Prueba unitaria testDataChart.
Clase chart: esta clase contiene la lógica para recuperar los datos que se
utilizaran para crear un diagrama de barras, que se agregara el reporte PDF.
Clase chart.
124
Resultado de Prueba unitaria para la clase chart
Resultado de la prueba para la clase chart:
Prueba unitaria testChart.
125
Clases de la cuarta iteración.
Clase eje: esta clase contiene toda la funcionalidad necesaria para manipular los
datos almacenados en la tabla eje, esta clase permite acceder a dicha tabla para
consultar, guardar, eliminar o modificar valores en la tabla.
Clase eje
Resultado de Prueba unitaria para la clase eje
Resultado de la prueba para la clase eje:
126
Prueba unitaria testEje.
127
Clase variable: esta clase contiene toda la funcionalidad necesaria para
manipular los datos almacenados en la tabla eje, esta clase permite acceder a
dicha tabla para consultar, guardar, eliminar o modificar valores en la tabla.
Clase variable
Resultado de Prueba unitaria para la clase variable
Resultado de la prueba para la clase variable:
128
Prueba unitaria testVariable.
129
Clases de la quinta iteración.
Clase indicador: esta clase contiene toda la funcionalidad necesaria para
manipular los datos almacenados en la tabla indicador, esta clase permite acceder
a dicha tabla para consultar, guardar, eliminar o modificar valores relacionados
con la magnitud del indicador.
Clase indicador
Resultado de Prueba unitaria para la clase indicador
Resultado de la prueba para la clase variable:
130
Prueba unitaria para testIndicador.
Clase estudioAnual: esta clase contiene toda la funcionalidad necesaria para
manipular los datos almacenados en la tabla estudio_anual, esta clase permite
acceder a dicha tabla para consultar, guardar, eliminar o modificar valores que
permitirán asignar estadísticas a los municipios.
131
Clase estudioAnual
Resultado de Prueba unitaria para la clase indicador
Resultado de la prueba para la clase estudioAnual:
132
Prueba unitaria para testEstudioAnual.
133
Vista de datos.
Modelo entidad relación (MER): El modelo de datos entidad-relación (E-R) está
basado en una percepción del mundo real que consta de una colección de objetos
básicos, llamados entidades, y de relaciones entre estos objetos. Una entidad es
una cosa u objeto en el mundo real que es distinguible de otros objetos. Este
modelo es útil para representar la estructura de los datos en una base de datos
relacional.
En el anexo A “diccionario de datos” puede encontrar la referencia de la base de
datos, con la descripción textual de todas las tablas, relaciones y demás
entidades.
Diagrama entidad-relación
134
Vista de interacción.
Diagrama de secuencias: Los diagramas de secuencia se usan para mostrar la
interacción entre los usuarios, las pantallas y las instancias de los objetos en el
sistema. Proveen un mapa secuencial del paso de los mensajes entre los objetos
a lo largo del tiempo. Frecuentemente, estos diagramas se utilizan para ilustrar un
escenario, un conjunto de pasos comunes que se siguen en respuesta a un evento
externo y que genera un resultado. El modelo incluye qué inicia la actividad en el
sistema, qué procesamiento y cambios ocurren internamente y qué salidas se
generan.
Diagrama de secuencias para Consultar mapa
135
Flujo de eventos Consultar mapa
(:1) el usuario visitante accede a la interfaz de consulta de Mapas, (:2:) la UI
utilizando AJAX envía automáticamente una petición al objeto controlFormMapa,
(:3) el objeto controlFormMapa captura la petición de datos y la redirecciona
enviándola al objeto dataConnector ejecutando el método getEjes(), (:4) el objeto
dataConnector accede a la capa de datos y mediante el método getEjes()
encapsula los datos en formato JSON y los envía de vuelta al objeto
controlFormMapa, (:5) el objeto controlFormMapa recibe los datos en JSON y los
envía a la interfaz que hizo la petición, (:6) se captura el evento y se actualiza la
interfaz, (:7) el usuario selecciona uno de los Ejes temáticos de una lista
desplegable, (:8) la UI utilizando el motor AJAX envía una petición con el
parámetro cod_eje al objeto controlFormMapa, (:9) el objeto controlFormMapa
captura la petición y la redirecciona al objeto dataConnector ejecutando el método
getVarsDeEje(:cod_eje), (:10) el objeto dataConnector accede a la capa de datos
y usando el método getVarsDeEje() retorna el conjunto de valores en JSON al
objeto controlFormMapa, (:11) controlFormMapa envía los datos a la interfaz, (:12)
un evento actualiza la interfaz, (:13) el usuario selecciona una variable de una lista
desplegable, (:14) la UI utilizando el motor AJAX envía una petición con los
parámetros cod_eje y cod_var al objeto controlFormMapa, (:15) el objeto
controlFormMapa captura la petición y la redirecciona al objeto dataConnector
ejecutando el método getIndDeVar(:cod_eje, cod_var), (:16) el objeto
dataConnector accede a la capa de datos y usando el método getIndDeVar()
retorna el conjunto de valores en JSON al objeto controlFormMapa, (:17)
controlFormMapa envía los datos a la interfaz, (:18) un evento actualiza la interfaz,
(:19) el usuario selecciona un indicador de una lista desplegable, (:20) la UI
utilizando el motor AJAX envía una petición con los parámetros cod_eje, cod_var y
cod_ind al objeto controlFormMapa, (:21) el objeto controlFormMapa captura la
petición y la redirecciona al objeto dataConnector ejecutando el método
getAnyosDeInd(:cod_eje, cod_var, cod_ind), (:22) el objeto dataConnector accede
a la capa de datos y usando el método getAnyosDeInd () retorna el conjunto de
valores en JSON al objeto controlFormMapa, (:23) controlFormMapa envía los
datos a la interfaz, (:24) el usuario selecciona un año para la estadística de una
lista desplegable, (:25) la UI utilizando el motor AJAX envía una petición con los
parámetros cod_eje, cod_var, cod_ind y anyo al objeto controlFormMapa, (:26) el
objeto controlFormMapa captura la petición y la redirecciona al objeto
dataConnector ejecutando el método getdataStore(:cod_eje, cod_var, cod_ind,
anyo), (:27) el objeto dataConnector accede a la capa de datos y usando el
método getdataStore() retorna el conjunto de valores en JSON al objeto
controlFormMapa, (:28) controlFormMapa envía los datos a la interfaz, (:29) el
usuario selecciona el numero de clases y otros parámetros, (:30)
controlFormMapa captura la petición, (:31) entonces envía a un objeto
motorMapfile junto con los parámetros y el dataStore encapsulados en un array,
(:32) el objeto motorMapfile procesa los datos y genera un mapfile que guarda en
136
el disco duro para luego pasar su ruta al visor ka-Map.
Diagrama de secuencias para Imprimir mapa
Flujo de eventos Imprimir mapa. (:1)El usuario selecciona imprimir mapa de la
interfaz de navegación de mapa y selecciona uno de los formatos, (:2) la UI envía
la petición al objeto print, que recibe como parámetro el tipo de imagen y crea
esta, (:4) el objeto print envía una petición parametrizada de datos al objeto
dataChart, (::5) el objeto dataChart retorna un conjunto de valores en un array,
(::6) el objeto print envía una petición al objeto chart junto con el dataStore, (::7) el
objeto chart retorna una imagen con un diagrama de datos del dataStore recibido,
(::8) el objeto print crea una imagen de la leyenda del mapa, (:9) el objeto print
envía una petición al objeto tcpdf para crear un documento pdf con la imagen del
mapa, la escala , la leyenda de datos y el diagrama, (::10) el objeto tcpdf contesta
la petición, (::11) el objeto print devuelve el mapa en un formato de datos.
137
Diagrama de secuencias para Registro usuario
Flujo de eventos Registro usuario. (::1) el usuario accede a la interfaz y solicita
registrarse, (::2) la UI envía una petición de registro al sistema con los parámetros
entrados por el usuario, (::3) el objeto controlVisitante invoca el método save() del
objeto Visitante para registrar al usuario, (::4) el objeto Visitante confirma la
transacción, (::5) el objeto controlVisitante notifica a la UI acerca de la operación
de registro, (::6) el usuario solicita acceder al sistema, (::7) la UI envía una petición
de inicio de sesión, (::8) el objeto controlFormMapa envía una petición de
autenticación al objeto Visitante, (::9) el objeto visitante permite o deniega el
acceso, (::10) el objeto controlFormMapa notifica a la Ui del resultado de la
operación.
138
Diagrama de secuencias para Agregar eje
Flujo de eventos Agregar eje.
(:1) El usuario Administrador accede a la interfaz de agregar eje, (::2) la IU
Agregar eje envía la petición del código del máximo código eje al objeto
ControlFormEje, (::3) el objeto ControlFormEje recibe la petición y la redirecciona
al objeto Eje ejecutando el método maxEje(::), (::4) el objeto Eje accede a la capa
de datos obteniendo el máximo código eje luego lo encapsula en formato JSON y
retorna el código al objeto controlFormEje, (::5) el objeto controlFormEje recibe el
dato y lo retorna a la interfaz Agregar eje, (::6) la interfaz agregar eje actualiza el
combo eje con el dato recibido, (::7) El usuario selecciona el código del eje ingresa
la descripción del nuevo código y da clic en el botón guardar, (::8) la interfaz
Agregar eje valida los datos del formulario, (::9) si los datos están correctos envía
la petición al objeto controlFormEje para agregar un nuevo eje, (::10) el objeto
controlFormEje recibe la petición de la interfaz y la redirecciona al objeto eje
ejecutando el método saveEje(), (::11) el objeto eje recibe la petición y accede a la
capa de datos para agregar un nuevo eje enseguida retorna una confirmación
(::positiva ó negativa) de la acción, (:12) el objeto controlFormEje recibe la
confirmación y la retorna a la interfaz Agregar eje.
139
Diagrama de secuencias para Modificar eje
Flujo de eventos Modificar eje.
(:1) El usuario Administrador accede a la interfaz Modificar eje, (::2) la interfaz
modificar eje envía la petición ejes al objeto controlFormEje, (::3) el objeto
controlFormEje recibe la petición y la redirecciona al objeto Eje ejecutando el
método getEjes(), (::4) el objeto Eje recibe la petición y accede a la capa de datos
para retornar la lista de ejes encapsulándolos en formato JSON y retornándolos al
objeto controlFormEje, (::5) el objeto controlFormEje recibe los datos y lo retorna a
la interfaz Modificar eje, (::6) la interfaz actualiza el combo cod_eje con los datos
recibidos, (::7) El Administrador selecciona el eje, ingresa la nueva descripción y
da clic en el botón modificar, (::8) la interfaz valida los datos del formulario, (::9) la
interfaz modificar eje realiza la petición de modificar el eje al objeto
controlFormEje, (::10) el objeto controlFormEje recibe la petición y la redirecciona
al objeto Eje ejecutando el método updateEje(::), (::11) El objeto eje recibe la
petición y accede a la capa de datos para modificar la descripción del eje luego
retorna la confirmación de la acción al objeto controlFormEje, (::12) el objeto
controlFormEje recibe la confirmación de la acción y la envía a la interfaz modificar
eje.
140
Diagrama de secuencias para Eliminar eje
Flujo de eventos Eliminar eje.
(:1) El usuario Administrador accede a la interfaz Eliminar eje, (:2) la interfaz
Eliminar eje envía la petición ejes al objeto controlFormEje, (:3) el objeto
método getEjes(), (:4) el objeto Eje recibe la petición y accede a la capa de datos
objeto controlFormEje, (:5) el objeto controlFormEje recibe los datos y lo retorna a
la interfaz Eliminar eje, (:6) la interfaz actualiza el combo cod_eje con los datos
recibidos, (:7) El Administrador selecciona el eje y da clic en el botón eliminar, (:8)
la interfaz valida los datos del formulario, (:9) la interfaz eliminar eje realiza la
petición de eliminar el eje al objeto controlFormEje, (:10) el objeto controlFormEje
recibe la petición y la redirecciona al objeto Eje ejecutando el método deleteEje(),
(:11) El objeto eje recibe la petición y accede a la capa de datos para eliminar el
eje luego retorna la confirmación de la acción al objeto controlFormEje, (:12) el
objeto controlFormEje recibe la confirmación de la acción y la envía a la interfaz
eliminar eje.
141
Diagrama de secuencias para Consultar eje.
Flujo de eventos Consultar eje.
(:1) El usuario Administrador accede a la interfaz Consultar eje, (:2) la interfaz
Consultar eje envía la petición ejes al objeto controlFormEje, (:3) el objeto
método getEjes(), (:4) el objeto Eje recibe la petición y accede a la capa de datos
objeto controlFormEje, (:5) el objeto controlFormEje recibe los datos y lo retorna a
la interfaz Consultar eje, (:6) la interfaz actualiza el datagrid con los datos
recibidos.
142
Diagrama de secuencias para Agregar variable.
Flujo de eventos Agregar variable.
(::1) El usuario Administrador accede a la interfaz de agregar variable, (:2) la IU
Flujo de eventos Agregar variable.
Agregar variable envía la petición de ejes al objeto ControlFormEje, (:3) el objeto
ControlFormEje recibe la petición y la redirecciona al objeto Eje ejecutando el
método getEjes(), (:4) el objeto Eje accede a la capa de datos obteniendo el array
de ejes luego lo encapsula en formato JSON y lo retorna al objeto controlFormEje,
(:5) el objeto controlFormEje recibe los datos y los retorna a la interfaz Agregar
variable, (:6) la interfaz agregar variable actualiza el combo eje con los datos
recibidos, (:7) el usuario selecciona el código del eje, (:8) la interfaz agregar
variable realiza la petición del máximo código de la variable al objeto
143
ControlFormVariable, (:9) el objeto ControlFormVariable recibe la petición y la
redirecciona al objeto variable ejecutando el método getMax(), (:10) el objeto
variable accede a la capa de datos obteniendo el máximo código variable
encapsulando en formato JSON y retornándolo al objeto controlFormVariable,
(:11) el objeto ControlFormVariable recibe el dato y lo retorna a la interfaz agregar
variable, (:12) el administrador selecciona el código de la variable ingresa la
descripción de la nueva variable y da clic en el botón guardar, (:13) la interfaz
valida el formulario, (:14) la interfaz agregar variable realiza la petición de agregar
una nueva variable al objeto ControlFormVariable, (:15) el objeto
ControlFormVariable recibe la petición y la redirecciona al objeto variable
ejecutando el método saveVariable, (:16) el objeto variable accede a la capa de
datos para insertar una nueva variable y retorna la confirmación de la acción al
objeto ControlFormVariable, (:17) el objeto ControlFormVariable recibe la
confirmación y la envía a la interfaz agregar variable.
Diagrama de secuencias para Modificar variable.
Flujo de eventos Modificar variable.
(:1) El usuario Administrador accede a la interfaz de modificar variable, (:2) la IU
modificar variable envía la petición de ejes relacionados con la tabla variable al
objeto ControlFormEje, (:3) el objeto ControlFormEje recibe la petición y la re
144
direcciona al objeto Eje ejecutando el método getEjes(), (:4) el objeto Eje accede a
la capa de datos obteniendo el array de ejes luego lo encapsula en formato JSON
y lo retorna al objeto controlFormEje, (:5) el objeto controlFormEje recibe los datos
y los retorna a la interfaz modificar variable, (:6) la interfaz modificar variable
actualiza el combo eje con los datos recibidos, (:7) el usuario selecciona el código
del eje, (:8) la interfaz modificar variable realiza la petición de las variables
pertenecientes al eje seleccionado al objeto ControlFormVariable, (:9) el objeto
ejecutando el método getVarsDeEje(), (:10) el objeto variable accede a la capa de
datos obteniendo un array con las variables pertenecientes al eje encapsulando en
formato JSON y retornándolo al objeto controlFormVariable, (:11) el objeto
ControlFormVariable recibe los datos y los retorna a la interfaz modificar variable,
(:12) el administrador selecciona el código de la variable ingresa la nueva
descripción y da clic en el botón modificar, (:13) la interfaz valida el formulario,
(:14) la interfaz modificar variable realiza la petición de modificar una variable al
objeto ControlFormVariable, (:15) el objeto ControlFormVariable recibe la petición
y la redirecciona al objeto variable ejecutando el método updateVariable, (:16) el
objeto variable accede a la capa de datos para modificar la variable y retorna la
confirmación de la acción al objeto ControlFormVariable, (:17) el objeto
ControlFormVariable recibe la confirmación y la envía a la interfaz modificar
variable.
145
Diagrama de secuencias para Eliminar variable.
Flujo de eventos Eliminar variable.
(:1) El usuario Administrador accede a la interfaz eliminar variable, (:2) la IU
eliminar variable envía la petición de ejes al objeto ControlFormEje, (:3) el objeto
(:5) el objeto controlFormEje recibe los datos y los retorna a la interfaz eliminar
variable, (:6) la interfaz eliminar variable actualiza el combo eje con los datos
recibidos, (:7) el usuario selecciona el código del eje, (:8) la interfaz eliminar
variable realiza la petición de las variables pertenecientes al eje seleccionado al
objeto ControlFormVariable, (:9) el objeto ControlFormVariable recibe la petición y
la redirecciona al objeto variable ejecutando el método getVarsDeEje(), (:10) el
146
objeto variable accede a la capa de datos obteniendo un array con las variables
pertenecientes al eje encapsulándolo en formato JSON y retornándolo al objeto
controlFormVariable, (:11) el objeto ControlFormVariable recibe los datos y los
retorna a la interfaz eliminar variable, (:12) el administrador selecciona el código
de la variable y da clic en el botón eliminar, (:13) la interfaz valida el formulario,
(:14) la interfaz eliminar variable realiza la petición de eliminar una variable al
objeto ControlFormVariable, (:15) el objeto ControlFormVariable recibe la petición
y la redirecciona al objeto variable ejecutando el método deleteVariable, (:16) el
objeto variable accede a la capa de datos para eliminar la variable y retorna la
confirmación de la acción al objeto ControlFormVariable, (:17) el objeto
ControlFormVariable recibe la confirmación y la envía a la interfaz eliminar
variable.
Diagrama de secuencias para Consultar variable.
Consultar variable. (::1) El usuario Administrador accede a la interfaz Consultar
variable, (:2) la interfaz Consultar variable envía la petición variables al objeto
controlFormVariable, (:3) el objeto controlFormVariable recibe la petición y la
redirecciona al objeto Variable ejecutando el método getVariables(), (:4) el objeto
Variable recibe la petición y accede a la capa de datos para retornar la lista de
variables encapsulándolos en formato JSON y retornándolos al objeto
controlFormVariable, (:5) el objeto controlFormVariable recibe los datos y lo
retorna a la interfaz Consultar variable, (:6) la interfaz actualiza el datagrid con los
datos recibidos.
147
Diagrama de secuencias para Agregar indicador.
Flujo de eventos Agregar indicador. (:1) El usuario Administrador accede a la
interfaz de agregar indicador, (:2) la IU Agregar indicador envía la petición de ejes
presentes en la tabla variable al objeto ControlFormEje, (:3) el objeto
(:5) el objeto controlFormEje recibe los datos y los retorna a la interfaz Agregar
indicador, (:6) la interfaz agregar indicador actualiza el combo eje con los datos
recibidos, (:7) el usuario selecciona el código del eje, (:8) la interfaz agregar
indicador realiza la petición de las variables del eje seleccionado al objeto
redirecciona al objeto variable ejecutando el método getVarsDeEje(), (:10) el
objeto variable accede a la capa de datos obteniendo las variables del eje
encapsulándolos en formato JSON y retornándolos al objeto controlFormVariable,
(:11) el objeto ControlFormVariable recibe los datos y los retorna a la interfaz
agregar indicador, (:12) la interfaz agregar indicador actualiza el combo variable,
(:13) el administrador selecciona el código de la variable, (:14) la interfaz agregar
148
indicador realiza la petición del máximo código indicador para el eje y la variable
previamente seleccionado por el administrador al objeto controlFormIndicador,
(:15) el objeto controlFormIndicador recibe la petición y la redirecciona al objeto
Indicador ejecutando el método maxInd(), (:16) el objeto indicador accede a la
capa de datos obteniendo el máximo código indicador lo encapsula en formato
JSON y lo retorna al objeto controlFormIndicador, (:17) el objeto
controlFormIndicador recibe el dato y lo envía la interfaz agregar indicador, (:18) la
interfaz actualiza el valor del combo código indicador de acuerdo al dato recibido,
(:19) el usuario selecciona el código indicador e ingresa los datos indicador y
descripción luego da clic en el botón guardar, (:20) la interfaz valida el formulario,
(:21) la interfaz agregar indicador realiza la petición de agregar un nuevo indicador
al objeto controlFormIndicador, (:22) el objeto controlFormIndicador recibe la
petición y la redirecciona al objeto indicador ejecutando el método saveIndicador(),
(:23) el objeto indicador accede a la capa de datos para agregar un nuevo
indicador luego retorna la confirmación de la acción al objeto
controlFormIndicador, (:24) el objeto controlFormIndicador recibe la confirmación y
la retorna a la interfaz agregar indicador.
Diagrama de secuencias para Modificar indicador.
149
Flujo de eventos Modificar indicador.
(:1) El usuario Administrador accede a la interfaz de modificar indicador, (:2) la IU
modificar indicador envía la petición de ejes presentes en la tabla indicador al
objeto ControlFormEje, (:3) el objeto ControlFormEje recibe la petición y la
redirecciona al objeto Eje ejecutando el método getEjes(), (:4) el objeto Eje accede
a la capa de datos obteniendo el array de ejes luego lo encapsula en formato
JSON y lo retorna al objeto controlFormEje, (:5) el objeto controlFormEje recibe los
datos y los retorna a la interfaz modificar indicador, (:6) la interfaz modificar
indicador actualiza el combo eje con los datos recibidos, (:7) el usuario selecciona
el código del eje, (:8) la interfaz modificar indicador realiza la petición de las
variables del eje seleccionado al objeto ControlFormVariable, (:9) el objeto
datos obteniendo las variables del eje encapsulándolos en formato JSON y
retornándolos al objeto controlFormVariable, (:11) el objeto ControlFormVariable
recibe los datos y los retorna a la interfaz modificar indicador, (:12) la interfaz
modificar indicador actualiza el combo variable, (:13) el administrador selecciona el
código de la variable, (:14) la interfaz modificar indicador realiza la petición del
indicador asociado a la variable al objeto controlFormIndicador, (:15) el objeto
controlFormIndicador recibe la petición y la redirecciona al objeto Indicador
ejecutando el método getIndDeVar(), (:16) el objeto indicador accede a la capa de
datos obteniendo los indicadores asociados a la variable seleccionada por el
administrador luego los encapsula en formato JSON y los retorna al objeto
controlFormIndicador, (:17) el objeto controlFormIndicador recibe los datos y los
envía la interfaz modificar indicador, (:18) la interfaz actualiza el valor del combo
código indicador de acuerdo al dato recibido, (:19) el usuario selecciona el código
indicador e ingresa la nueva descripción luego da clic en el botón guardar, (:20) la
interfaz valida el formulario, (:21) la interfaz modificar indicador realiza la petición
de modificar la descripción de un indicador al objeto controlFormIndicador, (:22) el
objeto controlFormIndicador recibe la petición y la redirecciona al objeto indicador
ejecutando el método updateIndicador(), (:23) el objeto indicador accede a la capa
de datos para modificar el indicador luego retorna la confirmación de la acción al
objeto controlFormIndicador, (:24) el objeto controlFormIndicador recibe la
confirmación y la retorna a la interfaz modificar indicador.
150
Diagrama de secuencias para Eliminar indicador
Flujo de eventos Eliminar indicador. (:1) El usuario Administrador accede a la
interfaz de eliminar indicador, (:2) la IU eliminar indicador envía la petición de ejes
presentes en la tabla indicador al objeto ControlFormEje, (:3) el objeto
(:5) el objeto controlFormEje recibe los datos y los retorna a la interfaz eliminar
indicador, (:6) la interfaz eliminar indicador actualiza el combo eje con los datos
recibidos, (:7) el usuario selecciona el código del eje, (:8) la interfaz eliminar
indicador realiza la petición de las variables del eje seleccionado al objeto
redirecciona al objeto variable ejecutando el método getVarsDeEje(), (:10) el
objeto variable accede a la capa de datos obteniendo las variables del eje luego
los encapsula en formato JSON y después los retorna al objeto
retorna a la interfaz eliminar indicador, (:12) la interfaz eliminar indicador actualiza
151
el combo variable, (:13) el administrador selecciona el código de la variable, (:14)
la interfaz eliminar indicador realiza la petición del indicador asociado a la variable
al objeto controlFormIndicador, (:15) el objeto controlFormIndicador recibe la
petición y la redirecciona al objeto Indicador ejecutando el método getIndDeVar(),
(:16) el objeto indicador accede a la capa de datos obteniendo los indicadores
asociados a la variable seleccionada por el administrador luego los encapsula en
formato JSON y los retorna al objeto controlFormIndicador, (:17) el objeto
controlFormIndicador recibe los datos y los envía la interfaz eliminar indicador,
(:18) la interfaz actualiza el valor del combo código indicador de acuerdo al dato
recibido, (:19) el usuario selecciona el código indicador luego da clic en el botón
eliminar, (:20) la interfaz valida el formulario, (:21) la interfaz eliminar indicador
realiza la petición de eliminar el indicador al objeto controlFormIndicador, (:22) el
objeto controlFormIndicador recibe la petición y la redirecciona al objeto indicador
ejecutando el método deleteIndicador(), (:23) el objeto indicador accede a la capa
de datos para eliminar el indicador luego retorna la confirmación de la acción al
objeto controlFormIndicador, (:24) el objeto controlFormIndicador recibe la
confirmación y la retorna a la interfaz eliminar indicador.
Diagrama de secuencias para Consultar indicador.
Flujo de eventos Consultar indicador.(:1)El usuario Administrador accede a la
interfaz Consultar indicador, (:2) la interfaz Consultar indicador envía la petición
indicadores al objeto controlFormIndicador, (:3) el objeto controlFormIndicador
recibe la petición y la redirecciona al objeto Indicador ejecutando el método
getIndicadores(), (:4) el objeto Indicador recibe la petición y accede a la capa de
datos para retornar la lista de indicadores encapsulándolos en formato JSON y
retornándolos al objeto controlFormIndicador, (:5) el objeto controlFormIndicador
152
recibe los datos y lo retorna a la interfaz Consultar indicador, (:6) la interfaz
actualiza el datagrid con los datos recibidos.
Diagrama de secuencias para Agregar estudio anual.
Flujo de eventos Agregar estudio anual. (:1) El usuario Administrador accede a
la interfaz de agregar estudio anual, (:2) la IU Agregar estudio anual envía la
petición de ejes presentes en la tabla indicador al objeto ControlFormEje, (:3) el
objeto ControlFormEje recibe la petición y la redirecciona al objeto Eje ejecutando
el método getEjes(), (:4) el objeto Eje accede a la capa de datos obteniendo el
array de ejes luego lo encapsula en formato JSON y lo retorna al objeto
controlFormEje, (:5) el objeto controlFormEje recibe los datos y los retorna a la
interfaz Agregar estudio anual, (:6) la interfaz agregar estudio anual actualiza el
combo eje con los datos recibidos, (:7) el usuario selecciona el código del eje, (:8)
la interfaz agregar estudio anual realiza la petición de las variables del eje
seleccionado al objeto ControlFormVariable, (:9) el objeto ControlFormVariable
153
recibe la petición y la redirecciona al objeto variable ejecutando el método
getVarsDeEje(), (:10) el objeto variable accede a la capa de datos obteniendo las
variables del eje encapsulándolos en formato JSON y retornándolos al objeto
retorna a la interfaz agregar estudio anual, (:12) la interfaz agregar estudio anual
actualiza el combo variable, (:13) el administrador selecciona el código de la
variable, (:14) la interfaz agregar estudio anual realiza la petición del indicador
relacionado a la variable seleccionada por el administrador al objeto
controlFormIndicador, (:15) el objeto controlFormIndicador recibe la petición y la
redirecciona al objeto Indicador ejecutando el método getIndDeVar(), (:16) el
objeto indicador accede a la capa de datos obteniendo los indicadores después los
encapsula en formato JSON y luego los retorna al objeto controlFormIndicador,
(:17) el objeto controlFormIndicador recibe los datos y los envía la interfaz agregar
estudio anual, (:18) la interfaz actualiza el valor del combo código indicador de
acuerdo al dato recibido, (:19) el usuario selecciona el código indicador, (:20) la
interfaz agregar estudio anual realiza la petición de los municipios al objeto
controlFormEstudioAnual, (:21) el objeto controlFormEstudioAnual recibe la
petición y la redirecciona al objeto Estudio anual ejecutando el método
getMunicipios(), (:22) el objeto Estudio Anual accede a la capa de datos
obteniendo los municipios después los encapsula en formato JSON y luego los
retorna
al
objeto
controlFormEstudioAnual,
(:23)
el
objeto
controlFormEstudioAnual recibe los datos y los envía a la interfaz agregar estudio
anual, (:24) la interfaz actualiza el combo municipios, (:25) el administrador
selecciona un municipio, (:26) la interfaz agregar estudio anual realiza la petición
de los años (:dependiendo del eje, la variable, el indicador y el municipio
seleccionado por el administrador, años que no estén en la combinación de estos)
al objeto controlFormEstudioAnual, (:27) el objeto controlFormEstudioAnual recibe
la petición y la redirecciona al objeto Estudio anual ejecutando el método
getAnyos(), (:28) el objeto estudio anual accede a la base de datos obteniendo los
años después los encapsula en formato JSON y luego los retorna al objeto
controlFormEstudioAnual, (:29) el objeto controlFormEstudioAnual recibe los datos
y los envía a la interfaz agregar estudio anual, (:30) la interfaz agregar estudio
anual actualiza el combo años de acuerdo a los datos recibidos, (:31) el
administrador selecciona el año e ingresa la fuente, medida y valor para el nuevo
estudio anual y da clic en el botón agregar, (:32) la interfaz valida el formulario,
(:33) la interfaz agregar estudio anual envía la petición de agregar un nuevo
estudio
anual
al
objeto
(:34)
el
objeto
controlFormEstudioAnual recibe la petición y la redirecciona al objeto estudio
anual ejecutando el método saveEstudioAnual, (:35) el objeto estudio anual
accede a la capa de datos para agregar el nuevo estudio anual luego retorna la
confirmación de la acción al objeto controlFormEstudioAnual, (:36) el objeto
controlFormEstudioAnual recibe la confirmación y la envía a la interfaz agregar
estudio anual.
154
Diagrama de secuencias para Modificar estudio anual.
Flujo de eventos Agregar eje. (:1) El usuario Administrador accede a la interfaz
de modificar estudio anual, (:2) la IU modificar estudio anual envía la petición de
ejes presentes en la tabla estudio anual al objeto ControlFormEje, (:3) el objeto
(:5) el objeto controlFormEje recibe los datos y los retorna a la interfaz modificar
estudio anual, (:6) la interfaz modificar estudio anual actualiza el combo eje con los
datos recibidos, (:7) el usuario selecciona el código del eje, (:8) la interfaz
modificar estudio anual realiza la petición de las variables del eje seleccionado al
objeto ControlFormVariable, (:9) el objeto ControlFormVariable recibe la petición y
la redirecciona al objeto variable ejecutando el método getVarsDeEje(), (:10) el
objeto variable accede a la capa de datos obteniendo las variables del eje
encapsulándolos en formato JSON y retornándolos al objeto controlFormVariable,
(:11) el objeto ControlFormVariable recibe los datos y los retorna a la interfaz
modificar estudio anual, (:12) la interfaz modificar estudio anual actualiza el combo
variable, (:13) el administrador selecciona el código de la variable, (:14) la interfaz
agregar estudio anual realiza la petición del indicador relacionado a la variable
seleccionada por el administrador al objeto controlFormIndicador, (:15) el objeto
controlFormIndicador recibe la petición y la redirecciona al objeto Indicador
155
ejecutando el método getIndDeVar(), (:16) el objeto indicador accede a la capa de
datos obteniendo los indicadores después los encapsula en formato JSON y luego
los retorna al objeto controlFormIndicador, (:17) el objeto controlFormIndicador
recibe los datos y los envía la interfaz modificar estudio anual, (:18) la interfaz
actualiza el valor del combo código indicador de acuerdo al dato recibido, (:19) el
usuario selecciona el código indicador, (:20) la interfaz modificar estudio anual
realiza la petición de los municipios al objeto controlFormEstudioAnual, (:21) el
objeto controlFormEstudioAnual recibe la petición y la redirecciona al objeto
Estudio anual ejecutando el método getMunicipios(), (:22) el objeto Estudio Anual
accede a la capa de datos obteniendo los municipios después los encapsula en
formato JSON y luego los retorna al objeto controlFormEstudioAnual, (:23) el
objeto controlFormEstudioAnual recibe los datos y los envía a la interfaz modificar
estudio anual, (:24) la interfaz actualiza el combo municipios, (:25) el administrador
selecciona un municipio, (:26) la interfaz modificar estudio anual realiza la petición
de los años dependiendo del eje, variable, indicador y municipio previamente
seleccionado por el administrador al objeto controlFormEstudioAnual, (:27) el
Estudio anual ejecutando el método getAnyosEst(), (:28) el objeto estudio anual
accede a la base de datos obteniendo los años después los encapsula en formato
JSON y luego los retorna al objeto controlFormEstudioAnual, (:29) el objeto
controlFormEstudioAnual recibe los datos y los envía a la interfaz modificar
estudio anual, (:30) la interfaz modificar estudio anual actualiza el combo años de
acuerdo a los datos recibidos, (:31) el administrador selecciona el año e ingresa el
nuevo valor para el estudio anual y da clic en el botón modificar, (:32) la interfaz
valida el formulario, (:33) la interfaz modificar estudio anual envía la petición de
modificar el valor del estudio anual al objeto controlFormEstudioAnual, (:34) el
estudio anual ejecutando el método updateEstudioAnual, (:35) el objeto estudio
anual accede a la capa de datos para modificar el nuevo estudio anual luego
retorna la confirmación de la acción al objeto controlFormEstudioAnual, (:36) el
objeto controlFormEstudioAnual recibe la confirmación y la envía a la interfaz
modificar estudio anual.
156
Diagrama de secuencias para Eliminar estudio anual.
Flujo de eventos Eliminar estudio anual.
(:1) El usuario Administrador accede a la interfaz eliminar estudio anual, (:2) la IU
eliminar estudio anual envía la petición de ejes presentes en la tabla estudio anual
157
al objeto ControlFormEje, (:3) el objeto ControlFormEje recibe la petición y la
redirecciona al objeto Eje ejecutando el método getEjes(), (:4) el objeto Eje accede
a la capa de datos obteniendo el array de ejes luego lo encapsula en formato
JSON y lo retorna al objeto controlFormEje, (:5) el objeto controlFormEje recibe los
datos y los retorna a la interfaz eliminar estudio anual, (:6) la interfaz eliminar
estudio anual actualiza el combo eje con los datos recibidos, (:7) el usuario
selecciona el código del eje, (:8) la interfaz eliminar estudio anual realiza la
petición de las variables del eje seleccionado al objeto ControlFormVariable, (:9) el
objeto ControlFormVariable recibe la petición y la redirecciona al objeto variable
datos obteniendo las variables del eje encapsulándolos en formato JSON y
retornándolos al objeto controlFormVariable, (:11) el objeto ControlFormVariable
recibe los datos y los retorna a la interfaz eliminar estudio anual, (:12) la interfaz
eliminar estudio anual actualiza el combo variable, (:13) el administrador
selecciona el código de la variable, (:14) la interfaz agregar estudio anual realiza la
petición del indicador relacionado a la variable seleccionada por el administrador al
objeto controlFormIndicador, (:15) el objeto controlFormIndicador recibe la petición
y la redirecciona al objeto Indicador ejecutando el método getIndDeVar(), (:16) el
objeto indicador accede a la capa de datos obteniendo los indicadores después los
encapsula en formato JSON y luego los retorna al objeto controlFormIndicador,
(:17) el objeto controlFormIndicador recibe los datos y los envía la interfaz eliminar
estudio anual, (:18) la interfaz actualiza el valor del combo código indicador de
acuerdo al dato recibido, (:19) el usuario selecciona el código indicador, (:20) la
interfaz eliminar estudio anual realiza la petición de los municipios al objeto
controlFormEstudioAnual, (:21) el objeto controlFormEstudioAnual recibe la
petición y la redirecciona al objeto Estudio anual ejecutando el método
getMunicipios(), (:22) el objeto Estudio Anual accede a la capa de datos
obteniendo los municipios después los encapsula en formato JSON y luego los
retorna
al
objeto
(:23)
el
objeto
controlFormEstudioAnual recibe los datos y los envía a la interfaz modificar
estudio anual, (:24) la interfaz actualiza el combo municipios, (:25) el administrador
selecciona un municipio, (:26) la interfaz eliminar estudio anual realiza la petición
de los años dependiendo del eje, variable, indicador y municipio previamente
seleccionado por el administrador al objeto controlFormEstudioAnual, (:27) el
Estudio anual ejecutando el método getAnyosEst(), (:28) el objeto estudio anual
accede a la base de datos obteniendo los años después los encapsula en formato
JSON y luego los retorna al objeto controlFormEstudioAnual, (:29) el objeto
controlFormEstudioAnual recibe los datos y los envía a la interfaz eliminar estudio
anual, (:30) la interfaz eliminar estudio anual actualiza el combo años de acuerdo a
los datos recibidos, (:31) el administrador selecciona el año y da clic en el botón
eliminar, (:32) la interfaz valida el formulario, (:33) la interfaz eliminar estudio anual
envía la petición de eliminar el estudio anual al objeto controlFormEstudioAnual,
(:34) el objeto controlFormEstudioAnual recibe la petición y la redirecciona al
objeto estudio anual ejecutando el método deleteEstudioAnual, (:35) el objeto
158
estudio anual accede a la capa de datos para eliminar el estudio anual luego
retorna la confirmación de la acción al objeto controlFormEstudioAnual, (:36) el
objeto controlFormEstudioAnual recibe la confirmación y la envía a la interfaz
eliminar estudio anual.
Diagrama de secuencias para Consultar estudio anual.
Flujo de eventos Consultar estudio anual. (:1) El usuario Administrador accede
a la interfaz Consultar estudio anual, (:2) la interfaz Consultar estudio anual envía
la petición estudios anuales al objeto controlFormEstudioAnual, (:3) el objeto
controlFormEstudioAnual recibe la petición y la redirecciona al objeto estudio
anual ejecutando el método getEstudioAnuales(), (:4) el objeto estudio anual
recibe la petición y accede a la capa de datos para retornar la lista de estudios
anuales luego los encapsula en formato JSON y después los retorna al objeto
controlFormEstudioAnual, (:5) el objeto controlFormEstudioAnual recibe los datos
y lo retorna a la interfaz Consultar estudio anual, (:6) la interfaz actualiza el
datagrid con los datos recibidos.
Esquema navegacional: Para el diseño navegacional no se siguió una
metodología, más bien se procuro mantener la simplicidad en la navegación,
proporcionando una interfaz intuitiva y fácil de utilizar. El siguiente diagrama ilustra
de forma básica el esquema de acceso a las diferentes interfaces.
159
Esquema navegacional.
Vista de despliegue.
Diagrama de despliegue: Los diagramas de despliegue representan los nodos y
sus relaciones. Típicamente, los nodos son conectados por asociaciones de
comunicación tales como enlaces de red, conexiones TCP/IP, microondas, etc.
160
Diagrama de despliegue.
161
Anexo B. Fase IV desarrollo
Codificación. Durante la fase de desarrollo, se decido aplicar un conjunto
específico de tecnologías, esta selección se hizo atendiendo a criterios como
facilidad de aprendizaje, interoperabilidad con otros sistemas, escalabilidad,
rendimiento y tipo de licenciamiento. En la tabla 26 se hace una descripción del
software aplicado.
Software utilizado.
Artefacto Versión
Licencia
ka-map
LGPL
1.0
Descripción
Framework en javascript y PHP/mapscript,
provee de un entorno de trabajo para la
visualización de los mapas generados.
Librería en javascript, utilizada en las
GNU GPL interfaces de usuario, para capturar y
3.0
mostrar información, proporciona un entorno
de trabajo seguro y compatibilidad con
navegadores.
Ext-js
2.1
ADOdb
5.06
BSD and
LGPL
Tcpdf
4.6
GNU GPL
Librería escrita en PHP utilizada para la
2.1
generación de reportes en formato PDF.
Jpgraph
1.09
QPL
Librería escrita en PHP, proporciona
funciones de estandarización de base de
datos
Librería escrita en PHP para la generación
de diagramas
En esta fase se materializa el trabajo iniciado en la fase de planificación, a
continuación se da una vista de alto nivel sobre el funcionamiento de la parte
principal de la aplicación, la cual tiene como tarea construir y desplegar los mapas
creados por el usuario.
162
La figura muestra el funcionamiento de WebGIS VI; todos los datos temáticos son
filtrados y mostrados al usuario mediante una interfaz grafica de usuario, la cual
muestra varias listas desplegables con la información correspondiente a los ejes,
variables e indicadores y el año en que ocurre, además de esto, el usuario
selecciona los diferentes parámetros de configuración como esquema de color,
tipo de mapa y capa base, una vez se obtienen estos datos, el sistema crea un
objeto de la clase mapaTematico el cual mediante el método getMapfile() genera
un archivo mapfile .map que es guardado como temporal y que retorna una URL al
navegador de cartografía ka-Map. Una vez se ha construido el mapfile que
contiene todos los parámetros del mapa, todos los objetos (imagen del mapa,
leyenda y escala) en el mapfile son generados por MapServer, ka-Map fragmenta
la imagen del mapa en mosaicos y las despliega en la parte cliente (navegador
web).
Cómo funciona WebGIS VI.
Comunicación entre el Cliente y el Servidor. AJAX (Asynchronous JavaScript
And XML) es un importante y poderoso modelo de desarrollo de aplicaciones Web
interactivas. Particularmente brinda muchas facilidades para el desarrollo de
aplicaciones SIG en internet. Para la implementación de WebGIS se aplico el
modelo AJAX; que posibilita actualizar el contenido de una página Web, de forma
inmediata, sin tener que recargar la página completa, que de otro modo aplicando
solo tecnología del lado del servidor, por cada acción que el usuario efectué debe
esperar que se cargue una nueva página vía HTTP para obtener un resultado,
163
generando largas esperas y congestión en la red. Gracias a AJAX WebGIS VI
vence el esquema “solicitud-respuesta”. Logrando una mayor interactividad, una
mejor respuesta y se estrechando el vínculo “cliente-aplicación”.
Comunicación entre el cliente y el servidor.
El flujo de comunicación en la aplicación es bastante básico y se describe a
continuación:
•
(1) Una vez se ha cargado completamente la interfaz web, se lanza
automáticamente una petición AJAX por parte del navegador web, esta petición
es contestada con una lista que contiene todos los ejes de investigación que
tienen estadísticas, de modo tal que cada vez que se selecciona un eje
temático se lanza la petición y esta carga una lista de variables a su vez una
lista de indicadores y por ultimo una lista con años para ese indicador.
•
(2) aquí el usuario ya selecciono las estadísticas y otros parámetros tales
como: tipo de mapa, numero de clases o numero de series y el esquema de
color, el usuario pide crear un nuevo mapa, entonces se genera un archivo
mapfile para generar el mapa, la escala el mapa de referencia y otros
elementos que se desplegaran en la interfaz del mapa.
164
•
(3) una vez que el sistema crea el mapa carga la interfaz de navegación de
mapa (ka-Map) con el mapa creado y permitirá realizar consultas y
operaciones básicas sobre el mapa (zoom, identify, query).
Infraestructura de WebGIS VI.
Acceso a datos. Para el acceso a datos se utilizo la librería ADOdb para PHP, ya
que las funciones de acceso a base de datos en PHP no están estandarizadas,
esta librería esconde las diferencias entre cada API de base de datos para que se
pueda cambiar fácilmente de software de base de datos.
Perfiles de conexión. El acceso a la base de datos se realiza con dos perfiles de
acceso, un perfil que concede privilegios de acceso a los administradores, y otro
perfil para los usuarios visitantes. El cuadro muestra uno de los perfiles de
conexión.
165
<?php
/****************************************************************
Configura los parámetros de conexión para el perfil Visitante
*****************************************************************/
DEFINE ('DB_HOST', 'localhost');
DEFINE ('DB_PORT', '5432');
DEFINE ('DB_NAME', 'basededatos');
DEFINE ('DB_USER', 'usuario');
DEFINE ('DB_PASSWORD', 'usuario');
DEFINE ('DSN', 'postgres://'.DB_USER.':'.DB_PASSWORD."@".DB_HOST."/".DB_NAME);
?>
Clase dataConnector. Esta clase ofrece métodos para conectarse y acceder a la
base de datos, para obtener los temas de investigación (ejes), las variables,
indicadores y los años para las estadísticas. Esta clase contiene 7 métodos:
•
getAnyosChart($ejeID, $varID, $indID): este método obtiene una lista de
años para un indicador para mapa tipo chart.
•
getAnyosDeInd($ejeID, $varID, $indID): este método obtiene una lista de
años para un indicador para un mapa tipo coropleta.
•
getDataStore($ejeID, $varID, $indID, $anyo): obtiene un array multimensional
con los datos para el mapa temático y el conjunto de valores.
•
getDataStoreChart($ejeID, $varID, $indID, $anyo): obtiene datos de la base
de datos y los transforma en un array multimensional con los datos para el
mapa temático y el conjunto de valores, este método se aplica cuando el
usuario crea un mapa diagrama (chart).
•
getEjes(): recupera de la base de datos los ejes tema de investigación que
tienen datos relacionados.
•
getIndDeVar($ejeID, $varID):obtiene una lista de indicadores vinculados a una
variable de un eje temático.
•
getVarsDeEje($ejeID): obtiene una lista de variables vinculadas e un eje de
investigación.
166
Instanciación de un objeto de la clase dataConnector.
//construir el conector a la BD
$dataConnector
= new dataConnector();
$dataStore
= $dataConnector->getDataStore( $ejeID, $varID, $indID, $anyo);
Clase mapaTematico. Los datos en la base datos de indicadores obtenidos por
los métodos de la clase dataConnector son encapsulados y pasados a la clase
mapaTematico junto con otros parámetros de entrada. Una vez que se solicita la
creación del mapa, la clase mapaTematico elabora un archivo mapfile, para ello
hay un archivo mapfile base ya definido de modo que este se carga y se modifica
con PHP/MapScript en tiempo de ejecución como se muestra en el cuadro a
continuación.
$jMap = ms_newMapObj(W G_MAPFILE_BASE_PATH);
La clase mapaTematico está conformada por los métodos:
•
colores($n): calcula la gama de colores para los intervalos de datos.
•
generarClasses(): haya los intervalos de datos dependiendo del método de
clasificación.
•
getJenksBreaks($list, $numclass): obtiene los intervalos de datos aplicando
el método de jenks-caspall
•
getMapfile(): carga el mapfile base y le agrega una nueva capa produciendo
un nuevo mapfile.
El archivo mapfile es un archivo de texto plano, que tiene una estructura jerárquica
de objetos como muestra la figura 81, en la cual el objeto map se encuentra en la
parte superior, el objeto map contiene ítems simples y estructurados, los simples
consisten de pares: clave, valor. Los ítems estructurados contienen a su vez otros
ítems simples o estructurados. El mapfile define como se dibujara el mapa, que
167
capas de datos, la ubicación de los datos entre otros.
Estructura jerárquica del mapfile
Proceso de carga del mapa
Para elaborar los mapfiles la clase mapaTematico carga un archivo mapfile base
el cual tiene la configuración primaria que se cargara en todos los mapfiles que se
producirán. Ya cargado el mapfile y dependiendo del tipo de mapa a producir, se
crea una nueva capa que contendrá la representación grafica de los datos. El
script que se muestra a continuación pertenece al mapfile base.
168
Mapfile base
MAP
NAME "mapfile"
# configura el nombre por defecto del mapa
# Map image size
SIZE 600 600
# Configura el tamaño de la imagen que sera dibujada
UNITS METERS
# Configura la unidad de medida , METERS, DD.
EXTENT 944523.403930 1227601.703840 1332524.846070 1534431.296160
PROJECTION
'proj=longlat'
'ellps=WGS84'
'datum=WGS84'
'no_defs'
END
FONTSET "../../data/fonts/fonts.txt"
IMAGECOLOR 242 239 233
IMAGEQUALITY 99
IMAGETYPE gif
REFERENCE
IMAGE refmap2.png
EXTENT 944523.403930 1227601.703840 1332524.846070 1534431.296160
STATUS ON
COLOR -1 -1 -1
OUTLINECOLOR 255 0 0
SIZE 223 213
END
OUTPUTFORMAT
NAME png
DRIVER "GD/PNG"
MIMETYPE "image/png"
IMAGEMODE PC256
EXTENSION "png"
END
LEGEND
STATUS ON
KEYSIZE 18 12
LABEL
TYPE BITMAP
SIZE MEDIUM
COLOR 0 0 89
END
END
WEB
IMAGEPATH 'c:/ms4w/tmp/ms_tmp'
IMAGEURL '/ms_tmp/'
METADATA
'max_extents' 'auto'
'version' '1'
'wms_title' 'Mapas ORDICOP'
'wms_onlineresource' 'http://my.host.com/cgi-bin/mapserv?map=wms.map&'
'wms_rs' 'EPSG:4326'
END
END
SCALEBAR
IMAGECOLOR 255 255 255
LABEL
COLOR 0 0 0
SIZE SMALL
END
SIZE 350 4
COLOR 255 255 255
BACKGROUNDCOLOR 0 0 0
OUTLINECOLOR 0 0 0
UNITS KILOMETERS
INTERVALS 5
STATUS ON
END
END# fin de MAP
169
Una vez se ha cargado el mapfile base, la clase mapaTematico procesa los
parámetros y determina a partir de estos el tipo de mapa que solicito el usuario y
la configuración de ese mapa.
En el caso de ser un mapa de tipo coropleta el siguiente código producirá una
capa de tipo “polygon” que contiene los datos temáticos representados en
coropletas (intervalos de datos), agregando esa capa al mapa.
$geoSQL="the_geom from
(SELECT GE.gid, GE.the_geom, GE.nom_muni, GE.cod_munici, GE.presencia, EA.medida_ind, EA.valor
FROM geo_municipio GE RIGHT JOIN estudio_anual EA ON GE.gid=EA.municipio
WHERE EA.cod_eje=$this->ejeID AND EA.cod_var=$this->varID
AND EA.cod_ind=$this->indID AND EA.anyo= $this->anyo
ORDER BY EA.valor)
as myQuery using srid=-1 using unique gid";
$this->generarClasses(); //invocar el metodo generador de los puntos de corte
$this->colores($this->numClases);
$jLayer = ms_newLayerObj($jMap); // definicion del objeto layer
$jLayer->set( "name", "$this->descMapa"." para "."$this->anyo");
$jLayer->set( "type", MS_LAYER_POLYGON); //establecer el tipo de geometria para la capa
$jLayer->set( "status", MS_ON);//establecer el status de la capa
$jLayer->set( "connectiontype",MS_POSTGIS);//especificar connectiontype
$jLayer->set( "connection",$perfilAcceso);
$jLayer->set( "data",$geoSQL);
$jLayer->set("labelitem", "nom_muni");
$jLayer->set( "group","$this->descMapa"." para "."$this->anyo");
$jLayer->setMetaData("DESCRIPTION","$this->descMapa");
$jLayer->setMetaData("RESULT_FIELDS","cod_munici nom_muni medida_ind valor");
$jLayer->setMetaData("QUERYABLE","true");
$jLayer->setMetaData("fields","cod_munici:Codigo nom_muni:Municipio medida_ind:Medida_indicador
valor:Valor_Indicador");
$jLayer->setMetaData("searchfield","nom_muni");
$jLayer->setMetaData("tile_source", "auto");
for($i=0;$i< $this->numClases; $i++){
$jClass = ms_newClassObj($jLayer);//definir expression y el rango de valores
$inferior = $this->classBreaks[$i]['limInferior'];
$superior = $this->classBreaks[$i]['limSuperior'];
$jClass->set(name, "$inferior : $superior");
$jClass->label->color->setRGB(0,0,0);
$jClass->label->set("font", WG_FONT_STYLE);
$jClass->label->set("type", MS_TRUETYPE);
$jClass->label->set("position", MS_CC);
$jClass->label->set("partials", MS_TRUE);
$jClass->label->set("size", WG_FONT_SIZE-1);
$jClass->label->set("buffer", 1);
$jClass->label->outlinecolor->setRGB(255,255,255);
$jClass->set("template","ttt_query.html");
$jClass->setExpression("(([valor]>= $inferior ) AND ([valor] <= $superior))");
$jStyle = ms_newStyleObj($jClass);//definir el esquema de colores
$jStyle->color->setRGB($this->classColors[$i][0], $this->classColors[$i][1], $this>classColors[$i][2]);
$jStyle->outlinecolor->setRGB(170, 170, 127);
170
El script mostrado en el recuadro representa una capa temática para coropletas
con intervalos de datos, nótese que aquí los intervalos se representan dentro del
objeto CLASS mediante el uso de “EXPRESSION”.
LAY ER
C O N N E C T IO N "u ser= wgis_visitante pa ssw ord= tester d bnam e= indicadores host= localhost"
C O N N E C T IO N T Y PE P O ST G IS
D AT A "the_geom from (SEL EC T G E.gid, G E .the_geom , G E.nom _m un i, G E .cod_m u nici, G E .presencia,
EA .m edida_in d, E A .valor
FR O M geo_ m unicipio G E R IG H T JO IN estudio_anual E A O N G E.gid= E A .m u nicipio
W H ER E E A .cod_eje=1 AN D E A.cod_ var= 3 A N D E A .cod_ind= 1
AN D E A.a nyo= 2008 O R D ER BY E A .valor)
as m yQ uery u sing srid= -1 using u nique gid"
G R O U P "D espla za m iento F orzado para 20 08"
L AB ELIT EM "nom _m u ni"
M ET AD AT A
"D E SC R IPT IO N "
"D espla za m iento F orzado "
"tile_source"
"auto"
"Q UE R Y AB L E"
"true"
"R ES ULT _FIELD S " "cod_m u nici nom _m uni m edida_ ind valor"
"searchfield "
"nom _m u ni"
"fields" "cod_m u nici:C odigo nom _ m uni:M unicipio m edida_ind:M edida_indica dor valor:Valor_Indicador"
EN D
N AM E "D espla za m iento F orzado para 2008"
ST AT U S O N
T Y PE PO LY G O N
UN IT S M ET ER S
C L A SS
N A M E "0 : 11 5"
E XP R ES SIO N (([va lor]> = 0 ) AN D ([valor] < = 115 ))
L AB E L
FO N T "sans"
SIZE 6
T Y PE T R UET Y P E
EN D
ST Y LE
C O LO R 2 55 255 153
O UT LIN EC O LO R 170 17 0 127
SY M B O L 0
EN D
EN D
EN D
Por otro parte si se detecta que el usuario solicito un mapa de tipo mapadiagrama, el siguiente script generara una capa de tipo chart, esta capa
representa un mapa de tipo mapa-diagrama y relaciona a cada entidad geográfica
un diagrama con un numero n de series mayor a uno.
171
$jLayer = ms_newLayerObj($jMap); // definicion del objeto layer
$jLayer->set( "name", "$this->descMapa");
$jLayer->set( "type", MS_LAYER_CHART); //establecer el tipo de geometria para la capa
$jLayer->set( "status", MS_ON);//establecer el status de la capa
$jLayer->set( "connectiontype",MS_POSTGIS);//especificar connectiontype
$jLayer->set( "connection",$perfilAcceso);
$Valores = array_values($this->dataStore['datos']);
$n=count($Valores);
$key=array_search($this->anyo,$Valores);
for($i=$key;$i<($this->numSeries+$key) and $i< $n;$i++){
$anyosChart[]=$Valores[$i];
}
$n =count($anyosChart);
for($i=0;$i<$n;$i++){
$SQL.=", sum(case EA.anyo when '$anyosChart[$i]' then EA.valor else 0 end) as anyo".$anyosChart[$i];
}
$geoSQL="the_geom from (
select G.the_geom,G.gid,G.nom_muni".$SQL."
from estudio_anual EA left join geo_municipio G ON (EA.municipio = G.gid)
where EA.cod_eje=$this->ejeID and EA.cod_var=$this->varID
and EA.cod_ind=$this->indID AND EA.anyo between ".min($anyosChart)."
AND ".max($anyosChart)."
group by G.the_geom,G.gid,G.nom_muni)
as myQuery using srid=-1 using unique gid";
$jLayer->set( "data",$geoSQL);
$jLayer->set( "group","$this->descMapa"." desde "."$this->anyo");
$jLayer->setMetaData("DESCRIPTION","$this->descMapa");
$jLayer->setMetaData("RESULT_FIELDS","nom_muni");
$jLayer->setMetaData("queryable","true");
$jLayer->setMetaData("fields","cod_munici:Codigo");
$jLayer->setMetaData("searchfield","nom_muni");
$jLayer->setMetaData("tile_source", "auto");
$jLayer->setMetaData("opacity", 65);
$jLayer->set("template","ttt_query.html");
if($this->tipoChart=='torta'){$processing="CHART_TYPE=pie";}
else $processing="CHART_TYPE=bar";
$jLayer->setprocessing($processing);
$jLayer->setprocessing("CHART_SIZE=30");
for($i=0;$i< $n; $i++){
$jClass = ms_newClassObj($jLayer);
$jClass->set(name, "Año "."$anyosChart[$i]");
$jStyle = ms_newStyleObj($jClass);//definir el esquema de colores
$jStyle->setbinding(SIZE, "anyo"."$anyosChart[$i]");
if($i==0)$jStyle->color->setRGB(255, 0, 0);//rojo
elseif($i==1)$jStyle->color->setRGB(0, 255, 0);//verde
elseif($i==2)$jStyle->color->setRGB(0, 0, 255);//azul
elseif($i==3)$jStyle->color->setRGB(255, 200, 0);//naranja
elseif($i==4)$jStyle->color->setRGB(255, 0, 255);
Otra capa de datos temáticos representada por la aplicación es la capa de tipo
chart generada por la clase mapaTematico, para esto se producen dos capas, la
capa de fondo tipo “polygon” que contiene las entidades geográficas y la capa
chart propiamente dicha. El cuadro ilustra la anatomía de una capa chart generada
por la clase mapaTematico.
172
LAYER
CONNECTION "user=wgis_visitante password=tester dbname=indicadores host=localhost"
CONNECTIONTYPE POSTGIS
DATA "the_geom from (
select G.the_geom,G.gid,G.nom_muni,
sum(case EA.anyo when '2007' then EA.valor else 0 end) as anyo2007, sum(case
EA.anyo when '2008' then EA.valor else 0 end) as anyo2008
from estudio_anual EA left join geo_municipio G ON (EA.municipio = G.gid)
where EA.cod_eje=1 and EA.cod_var=3 and EA.cod_ind=1
AND EA.anyo between 2007 AND 2008
group by G.the_geom,G.gid,G.nom_muni)
as myQuery using srid=-1 using unique gid"
GROUP "Desplazamiento Forzado desde 2007"
METADATA
"DESCRIPTION" "Desplazamiento Forzado "
"opacity" "65"
"tile_source"
"auto"
"queryable"
"true"
"RESULT_FIELDS" "nom_muni"
"searchfield"
"nom_muni"
"fields" "cod_munici:Codigo"
END
NAME "Desplazamiento Forzado "
PROCESSING "CHART_TYPE=pie"
PROCESSING "CHART_SIZE=30"
STATUS ON
TEMPLATE "ttt_query.html"
TYPE CHART
UNITS METERS
CLASS
NAME "Año 2007"
STYLE
ANGLE 360
COLOR 255 0 0
OPACITY 100
SIZE [anyo2007]
SYMBOL 0
END
END
CLASS
NAME "Año 2008"
STYLE
ANGLE 360
COLOR 0 255 0
OPACITY 100
SIZE [anyo2008]
SYMBOL 0
END
END
END
Bloque de código que genera un nuevo mapfile que contiene la capa con los datos
temáticos (coropleta, mapa-diagrama) el mapfile se guarda en disco y se transfiere
su ubicación
173
$mapFile = "mapf_".time()."_".mt_rand(1,1000).".map";
$mapFilePath=WG_PATH_MAPFILE_GEN.$mapFile;
$errorCode="{success: false, errors: { reason: 'No se pudo
crear mapa..' }}";
if($jMap->save($mapFilePath)==-1) return $errorCode;
else return $mapFilePath;
Desplegando el mapa. Esta parte de la aplicación en el archivo controlFormMapa
instancia un objeto de la clase mapaTematico y le transfiere los datos obtenidos
por la clase dataStore en un array multidimensional llamado $dataStore, y un array
que contiene los parámetros de configuración del mapa. Posteriormente se invoca
el método getMapfile que construye el mapfile y pasa la ubicación de este en el
disco duro, con esta ubicación y otros parámetros como: el nombre de la cache en
disco del mapa, las escalas visibles y el formato del la imagen del mapa, se
produce un array que es almacenado en una variable de sesión que es accedida
por ka-map para crear la cache y construir todos los elementos del mapa. El
fragmento de código a continuación ilustra el proceso.
$map = new mapaTematico($dataStore,$paramArray); /*nuevo mapa*/
$MapfilePath = $map->getMapfile();
if (!file_exists($MapfilePath)) {
echo "{success: false}";
}
else {
$thisTitle= $map->tituloMapa." ".$map->anyo;
$semilla = 'UFPS0123456789';
$szMap= str_shuffle($semilla);
$_SESSION['ArrayConfig'][$szMap]= array(
'title'
=> $thisTitle,
'path'
=> $MapfilePath,
'scales'=> array( 1200000, 900000,500000 ),
'format'=> 'PNG'
);
$_SESSION['szMap']= $szMap;
echo "{success: true}";
}
174
Anexo C. Fase V pruebas
El objetivo de esta fase es detectar y depurar los errores en el software. Para
lograr esto, se establece un plan y conforme a este se realizan una serie de pasos,
en el caso de XP se realizan; pruebas de unidad y pruebas de aceptación, aparte
de las de integración y del sistema. Las pruebas de unidad y de integración se
centran en la verificación funcional de cada módulo y en la incorporación de los
módulos en una estructura de programa. La prueba del sistema valida el software
una vez que se ha incorporado en un sistema superior.
Pruebas de unidad. Los test unitarios ayudan a la refactorización, ya que
asegurarán que los cambios que se hayan introducido en la iteración actual no
afecten a la funcionalidad.
Una prueba unitaria es una forma de probar el correcto funcionamiento de un
módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione
correctamente por separado.
Para que una prueba unitaria sea buena se deben cumplir los siguientes
requisitos:
•
Automatizable: no debería requerirse una intervención manual. Esto es
especialmente útil para integración continúa.
•
Completas: deben cubrir la mayor cantidad de código.
•
Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser
ejecutadas una sola vez. También es útil para integración continua.
•
Independientes: la ejecución de una prueba no debe afectar a la ejecución de
otra.
•
Profesionales: las pruebas deben ser consideradas igual que el código, con la
175
misma profesionalidad, documentación, etc.
Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se
recomienda seguirlos o de lo contrario las pruebas pierden parte de su función. Es
importante darse cuenta de que las pruebas unitarias no descubrirán todos los
errores del código. Por definición, sólo prueban las unidades por sí solas. Por lo
tanto, no descubrirán errores de integración, problemas de rendimiento y otros
problemas que afectan a todo el sistema en su conjunto. Además, puede no ser
trivial anticipar todos los casos especiales de entradas que puede recibir en
realidad la unidad de programa bajo estudio.
Para la ejecución de las pruebas de unidad se aplico el framework SimpleTest el
cual ofrece múltiples test para someter a prueba a las clases, con el objetivo de
verificar el buen funcionamiento de cada uno de los métodos desarrollados.
SimpleTest es un entorno para realizar pruebas de unidad para código
desarrollado en PHP, por lo que no se hace necesario aprender un nuevo lenguaje
para realizar las pruebas, además desarrolla una interfaz similar a Junit por lo que
se hace más familiar su uso.
En SimpleTest los test unitarios son escritos como extensiones de las clases base
de prueba cada uno ampliado con métodos que en realidad contienen el código de
prueba. Cada prueba está escrita para invocar diversas afirmaciones que el
desarrollador espera, como assertEqual() si el resultado es correcto indica que el
método está retornando el resultado que el desarrollador espera es decir el
método utilizado para la prueba está funcionando correctamente. Para el
desarrollo de las pruebas de unidad…véase el numeral 6.3.4…
Pruebas de aceptación. El objetivo de las pruebas de aceptación es validar que
un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho
sistema que determine su aceptación, desde el punto de vista de su funcionalidad
y rendimiento. Las pruebas de aceptación son definidas por el usuario del sistema
y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final
corresponden al usuario.
La validación del sistema se consigue mediante la realización de pruebas de caja
negra que demuestran la conformidad con los requisitos y que se recogen en el
plan de pruebas, el cual define las verificaciones a realizar y los casos de prueba
asociados. Dicho plan está diseñado para asegurar que se satisfacen todos los
176
requisitos funcionales especificados por el usuario teniendo en cuenta también los
requisitos no funcionales relacionados con el rendimiento, seguridad de acceso al
sistema, a los datos y procesos, así como a los distintos recursos del sistema.
177

universidad francisco de paula santander

Transcripción

Documentos relacionados

Programación en C.net

Interfaz con el cliente - The ILO`s Impact Insurance Facility

Interfaz del Cliente - Un Blog de Marketing

José Díaz, pintor | Un maletín marrón

Evaluación voluntaria

Patrones Generales

En la opción uno encontraremos ubicados en la parte

INTERVENCIÓN INTERFAZ Observatorio II María Isabel Vera Vélez