Download Capítulo 1. Introducción

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

Document related concepts

no text concepts found

Transcript

cenidet
Centro Nacional de Investigación y Desarrollo Tecnológico
Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS
Herramienta para la Generación de Estilos Definidos por el
Usuario para su Asociación a Mapas Geográficos y Publicación
en Prototipos de Aplicaciones Web
presentada por
Janet de Jesús García Alba
Ing. en Sistemas Computacionales por el I. T. de la Laguna
como requisito para la obtención del grado de:
Maestría en Ciencias en Ciencias de la Computación
Director de tesis:
Dr. Juan Gabriel González Serna
Co-Director de tesis:
Dr. Joaquín Pérez Ortega
Jurado:
Dr. René Santaolaya Salgado – Presidente
M.C. Andrea Magadán Salazar – Secretario
M.C. Humberto Hernández García – Vocal
Dr. Juan Gabriel González Serna – Vocal Suplente
Cuernavaca, Morelos, México.
20 de Febrero de 2009
DEDICATORIA
A papá Dios:
Por su amor, por guiarme en el camino del bien,
poner a las personas adecuadas en mí camino y
darme fortaleza en todo momento. Sin duda me has
dado más de lo que merezco.
A mi madre Obdulia Alba Flores:
Por su amor, consejos y palabras de aliento. Por
respetar mis decisiones y ser quien nunca desistió en
que toda la familia saliera adelante a pesar de las
adversidades. Este trabajo es suyo madre. La quiero
mucho mamita chula.
A mi padre Juan García López (f):
Por el ejemplo académico que me brindó y sus
consejos de nunca dejar de seguir preparándome. Con
cariño le dedico este trabajo padre.
A mis hermanos Juan Adolfo, Oscar Sergio, José
Guadalupe, Alejandro, Arturo y Denis de Jesús: Por
creer en mí. Por estar cada uno a su manera
respaldándome económica y moralmente para lograr
mis objetivos. Gracias por sus consejos y momentos
agradables. Este trabajo se los dedico con mucho
cariño hermanitos chulos.
A mis cuñadas y amigas Rocío Navarro, Elizabeth
Montaño y Johana Silva:
Por su amistad, consejos y apoyo. Gracias cuñaditas
por los buenos momentos.
A mis sobrinos Moisés Adolfo, Diego David, Juan
Arón y Joselín:
Por traer alegría a la familia con sus ocurrencias y
travesuras. Porque con sus sonrisas cultivaron mi
alegría dándome motivos de seguir adelante. Los
amo.
A mi novio Jesús Fidel Borjas Díaz:
Por los cuidados, enseñanzas y gran paciencia
recibida de manera incondicional estos dos años. Por
su amor y respeto a mis decisiones. Por hacerme reír
a pesar de las circunstancias. Sin tu apoyo no lo
hubiera logrado “pacharrito”. Te amo.
AGRADECIMIENTOS
Este trabajo de investigación no hubiera sido posible realizarlo sin el apoyo del Consejo
Nacional de Ciencia y Tecnología (CONACYT), ya que la beca que me otorgó estos dos años
fue el sustento económico para poder solventar mis estudios de maestría. También quiero
agradecer al Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET) por la
oportunidad que me brindaron de realizar mis estudios de posgrado en sus instalaciones.
En estos dos años de investigación fueron muchas las personas que contribuyeron con sus
observaciones y consejos para que se lograra concluir satisfactoriamente este trabajo. A todos
ustedes les agradezco de todo corazón pero en especial:
A papá Dios por todo el amor que me ha dado, por estar conmigo en todo momento, ser mi
guía y cuidar a mis seres queridos y darles la tranquilidad de que seguía por el camino del bien
a pesar de la distancia.
A mi mamá y hermanos que siempre se han preocupado por mi bienestar. Les agradezco
mucho familia querida por todo lo que me han dado a lo largo de mi vida. Esta meta no se
hubiera concluido sin su amor y apoyo incondicional. Los amo.
A mi padre que a su manera me mostró su amor. Le agradezco por los momentos gratos que
pasamos y su consejo de seguir preparándome.
A mi director de tesis Dr. Juan Gabriel González Serna por su paciencia, buen trato y guiarme
a lo largo de la investigación.
A mis revisores de tesis: Dr. René Santaolaya Salgado, M.C. Andrea Magadán Salazar y al
M.C. Humberto Hernández García por el tiempo dedicado y observaciones constructivas que
enriquecieron el contenido del presente trabajo.
Al personal académico y administrativo de CENIDET, por compartir su conocimiento y buen
trato.
A mis compañeros y amigos de generación: Claudia, Deysy, Lalo y Richard. Por momentos
agradables y formar parte de esta experiencia. En especial a Deysy por aguantarnos
mutuamente durante un año al convivir en la misma casa, por esas pláticas que duraban horas
y por tu apoyo en los trámites de titulación. Sin tu ayuda esto hubiera sido complicado.
A mis compañeros de otras generaciones: Lirio, Adriana, Chucho, Pedro y Daniel de la
generación 2005-2007. Ruby, Janeth, Luis, Omar, Israel y Christian de la generación 20072009. A todos gracias por compartir momentos agradables en el laboratorio de SD.
Quiero hacer un especial agradecimiento a mi novio Jesús Fidel Borjas Díaz, pues su apoyo,
amor y paciencia estos dos años fueron importantes para seguir adelante a pesar de estar lejos
de nuestras familias. Gracias amor por enseñarme a ser independiente y apoyarme en todos los
aspectos.
RESUMEN
Desde los orígenes de la humanidad, el interés del hombre por conocer el entorno que le rodea
y descubrir y dominar nuevos territorios, lo han conducido a elaborar modelos reducidos de
los lugares que ha habitado. Es así como nace la cartografía, como ciencia y arte de
representación del mundo. En principio materializada sobre distintas superficies y con
herramientas variadas, cambiando constantemente al experimentar una serie importante de
innovaciones gracias a los avances tecnológicos que se tienen en el presente.
En el presente es común visualizar mapas publicados en la Web en formato vectorial y ráster.
La mayoría de los usuarios de aplicaciones que contienen información espacial no tienen
necesidades especiales de visualización, pero el grupo de usuarios avanzados que desarrollan
aplicaciones con contenido espacial, les surge la necesidad de gestionar y controlar la forma
en que se visualiza la información espacial de tal manera que facilite su legibilidad. Esta
actividad resulta ser una labor nada amigable para aquellos diseñadores de sitios Web que no
están familiarizados con las especificaciones de estilo proporcionadas por la Open Geospatial
Consortium (OGC).
Por lo anterior, el presente trabajo propone una herramienta generadora de prototipos de
Aplicaciones Web con contenido espacial, basada en la especificación J2EE que permita
proporcionar estilos personalizados a los mapas geográficos y publicarlos de manera sencilla
en Internet. Por lo tanto el objetivo de esta tesis es desarrollar una herramienta de software que
proporcione servicios para diseñar la apariencia e interacción con mapas temáticos.
TABLA DE CONTENIDO
CAPÍTULO 1 INTRODUCCIÓN .............................................................................................. 1
1.1. Introducción ............................................................................................................................. 2
1.2. Descripción del problema......................................................................................................... 2
1.3. Objetivos .................................................................................................................................. 3
1.4. Justificación.............................................................................................................................. 3
1.5. Beneficios ................................................................................................................................. 4
1.6. Alcances del proyecto de tesis ................................................................................................. 5
1.7. Limitaciones del proyecto de tesis ........................................................................................... 5
1.8. Estado de la práctica ................................................................................................................. 6
1.8.1.
Click2Map ........................................................................................................................ 8
1.8.2.
Map24 ............................................................................................................................ 10
1.8.3.
ZoomIn ........................................................................................................................... 10
1.8.4.
MapBuilder..................................................................................................................... 11
1.8.5.
Google Maps .................................................................................................................. 12
1.8.6.
Yahoo Maps ................................................................................................................... 13
1.8.7.
Live Search Maps ........................................................................................................... 13
1.9. Organización del documento .................................................................................................. 15
CAPÍTULO 2 MARCO TEÓRICO ......................................................................................... 17
2.1. Sistemas de Información Geográfica ..................................................................................... 18
2.1.1.
Información ráster .......................................................................................................... 19
2.1.2.
Información vectorial ..................................................................................................... 20
2.2. Open Gesospatial Consortium (OGC) .................................................................................... 21
2.2.1.
Web Map Service(WMS) ............................................................................................... 21
2.2.2.
HTTP GET ..................................................................................................................... 22
2.2.3.
HTTP POST ................................................................................................................... 23
2.2.4.
Operaciones WMS ......................................................................................................... 25
2.2.5.
Styled Layer Descriptor (SLD) ...................................................................................... 29
2.3. Elementos de programación ................................................................................................... 30
2.3.1.
J2EE ............................................................................................................................... 30
2.3.2.
Patrón Modelo-Vista-Controlador.................................................................................. 31
2.3.3.
JAVASCRIPT ................................................................................................................ 33
2.3.4.
AJAX.............................................................................................................................. 34
2.3.5.
XML ............................................................................................................................... 34
CAPÍTULO 3 ANÁLISIS Y DISEÑO ..................................................................................... 37
3.1. ANÁLISIS.............................................................................................................................. 38
3.1.1.
Especificación de requerimientos ................................................................................... 38
3.1.1.1.
Ámbito........................................................................................................................ 38
3.1.1.2.
Perspectiva del producto ............................................................................................ 38
3.1.1.3.
Funciones del producto .............................................................................................. 38
3.1.1.4.
Descripción de las funciones ...................................................................................... 38
3.1.1.5.
Usuarios de la herramienta ......................................................................................... 39
3.1.1.6.
Limitaciones de la herramienta .................................................................................. 39
3.1.2.
Diagramas de casos de uso y diagramas de actividad .................................................... 40
3.1.2.1.
Caso de uso: Registrar Usuario .................................................................................. 41
~i~
3.1.2.2.
Caso de uso: Autentificar Usuario.............................................................................. 42
3.1.2.3.
Caso de uso: Diseñar Mapa ........................................................................................ 43
3.1.2.4.
Caso de uso: Solicitad Mapa ...................................................................................... 45
3.1.2.5.
Caso de uso: Aplicar Estilos ....................................................................................... 46
3.1.2.6.
Caso de uso: Generar Código XML ........................................................................... 48
3.1.2.7.
Caso de uso: Elegir Plantilla de Diseño ..................................................................... 49
3.1.2.8.
Caso de uso: Publicar Aplicación Web ...................................................................... 51
3.1.2.9.
Caso de uso: Visualizar Aplicación Web ................................................................... 52
3.2. DISEÑO ................................................................................................................................. 53
3.2.1.
Diseño arquitectónico ..................................................................................................... 53
3.2.1.1 Clientes ........................................................................................................................... 54
3.2.1.2 Contenedor Web............................................................................................................. 54
3.2.1.3 Herramienta MapWeb Designer ..................................................................................... 54
3.2.1.4 Api visora de mapas ....................................................................................................... 55
3.2.1.5 Servidor de mapas (WMS por sus siglas en inglés). ..................................................... 56
3.2.1.6 Base de Datos (PostgreSQL). ......................................................................................... 56
3.2.2.
Diagramas de clases ....................................................................................................... 56
3.2.2.1.
Clases del caso de uso Registrar Usuario ................................................................... 57
3.2.2.2.
Clases del caso de uso Autentificar Usuario .............................................................. 59
3.2.2.3.
Clases del caso de uso Diseñar Mapa ......................................................................... 61
3.2.2.3.1. Clases del caso de uso Solicitar Mapa........................................................................ 61
3.2.2.3.2. Clases del caso de uso Aplicar Estilos y Generar Código XML ................................ 63
3.2.2.4.
Clases del caso de uso Elegir Plantilla de Diseño y Publicar Aplicación Web .......... 65
3.2.2.5.
Secuencia del Caso de uso Visualizar Aplicación Web ............................................. 67
3.2.3.
Diseño de la Base de Datos. ........................................................................................... 67
CAPÍTULO 4 IMPLEMENTACION ....................................................................................... 69
4.1
Conexión con la base de datos ............................................................................................... 70
4.2
Construcción del catálogo de mapas ...................................................................................... 71
4.3
Lógica de negocio .................................................................................................................. 71
4.4
Consulta de atributos del mapa .............................................................................................. 72
4.5
Construcción documento SLD ............................................................................................... 73
CAPÍTULO 5 PRUEBAS ...................................................................................................... 75
5.1
Resultados de las pruebas....................................................................................................... 77
5.2
Análisis de resultados ........................................................................................................... 101
CAPÍTULO 6 CONCLUSIONES ......................................................................................... 103
ANEXOS ............................................................................................................................ 107
ANEXO A EVALUACIÓN DE APIS VISORAS DE MAPAS ................................................. 109
ANEXO B EVALUACIÓN DE SERVIDORES DE MAPAS ................................................... 125
ANEXO C DISEÑO DE OBJETOS PARA EL DOCUMENTO SLD ...................................... 141
ANEXO D SÍNTESIS DE LA ESPECIFICACIÓN SLD......................................................... 145
ANEXO E PLAN DE PRUEBAS .......................................................................................... 165
REFERENCIAS .................................................................................................................. 177
~ ii ~
INDICE DE FIGURAS
Figura 1.1. Estudio del uso de comercio electrónico en México.............................................................. 3
Figura 1.2. Clasificación de la Geomática respecto al software libre ...................................................... 7
Figura 1.3. Interfaz de usuario de Click2Map .......................................................................................... 9
Figura 1.4. Publicación del mapa creado en Click2Map .......................................................................... 9
Figura 1.5. Interfaz de Map24 ................................................................................................................ 10
Figura 1.6. Interfaz de ZoomIn .............................................................................................................. 11
Figura 1.7. Interfaz de MapBuilder ........................................................................................................ 12
Figura 1.8. Interfaz de Google Maps...................................................................................................... 13
Figura 1.9. Interfaz de Yahoo Maps ....................................................................................................... 14
Figura 1.10. Interfaz de Virtual Earth .................................................................................................... 14
Figura 2.1. Capas que representan la realidad ........................................................................................ 18
Figura 2.2. Organización de la información en el modelo de datos ráster ............................................. 20
Figura 2.3. Información de un pixel ....................................................................................................... 20
Figura 2.4. Objetos geométricos del formato vectorial .......................................................................... 20
Figura 2.5. Resultado de solicitud GET a un WMS ............................................................................... 23
Figura 2.6. Código HTML de formulario para manejo de petición POST............................................. 24
Figura 2.7. Envío de petición HTTP POST............................................................................................ 24
Figura 2.8. Resultado de la petición HTTP POST ................................................................................. 25
Figura 2.9. Resultado de la petición GetCapabilities ............................................................................. 26
Figura 2.10. Resultado de la petición GetMap ....................................................................................... 27
Figura 2.11. Resultado de la petición GetFeatureInfo............................................................................ 29
Figura 2.12. Resultado de una petición al WMS utilizando el parámetro SLD y SLD_BODY ............ 30
Figura 2.13. Aplicaciones multinivel ..................................................................................................... 31
Figura 2.14. Interacción del patrón MVC .............................................................................................. 32
Figura 2.15. Funcionamiento de Struts .................................................................................................. 33
Figura 3.1. Diagrama general de casos de uso del sistema .................................................................... 40
Figura 3.2. Diagrama del caso de uso Registrar Usuario ....................................................................... 41
Figura 3.3. Diagrama de actividad de caso de uso Registrar Usuario .................................................... 42
Figura 3.4. Diagrama del caso de uso Autentificar Usuario................................................................... 42
Figura 3.5. Diagrama de actividad de caso de uso Autentificar Usuario ............................................... 43
Figura 3.6. Diagrama del caso de uso Diseñar Mapa ............................................................................. 44
Figura 3.7. Diagrama de actividad de caso de uso Diseñar Mapa .......................................................... 45
Figura 3.8. Diagrama de actividad de caso de uso Solicitar Mapa......................................................... 46
Figura 3.9. Diagrama de actividad de caso de uso Aplicar Estilos ........................................................ 48
Figura 3.10. Diagrama de actividad de caso de uso Generar Código XML ........................................... 49
Figura 3.11. Diagrama del caso de uso Elegir Plantilla de Diseño ........................................................ 49
Figura 3.12. Diagrama de actividad de caso de uso Elegir Plantilla de Diseño. .................................... 50
Figura 3.13. Diagrama del caso de uso Publicar Aplicación Web. ........................................................ 51
Figura 3.14. Diagrama de actividad del caso de uso Publicar Aplicación Web ..................................... 51
Figura 3.15. Diagrama del caso de uso Visualizar Aplicación Web ...................................................... 52
Figura 3.16. Diagrama de actividad de caso de uso Visualizar Aplicación Web ................................... 53
~ iii ~
Figura 3.17. Arquitectura general del sistema ........................................................................................ 54
Figura 3.18. Aplicación MapWeb Designer........................................................................................... 55
Figura 3.19. Paquetes del sistema MapWeb Designer ........................................................................... 56
Figura 3.20. Diagrama de clases de Registrar Usuario ......................................................................... 58
Figura 3.21. Diagrama de secuencias de Registrar Usuario .................................................................. 59
Figura 3.22. Diagrama de clases de Autentificar Usuario ..................................................................... 60
Figura 3.23. Diagrama de secuencias de Autentificar Usuario .............................................................. 61
Figura 3.24. Diagrama de secuencias de Solicitar Mapa ....................................................................... 62
Figura 3.25. Diagrama de clases de Solicitar Mapa............................................................................... 62
Figura 3.26. Diagrama de clases de Aplicar Estilos y generar código XML ......................................... 64
Figura 3.27. Diagrama de secuencias de Aplicar Estilos y generar código XML .................................. 65
Figura 3.28. Diagrama de clases de Elegir Plantilla de Diseño y Publicar Aplicación Web ................ 66
Figura 3.29. Diagrama de secuencias Elegir Plantilla de Diseño y Publicar Aplicación Web.............. 66
Figura 3.30. Diagrama de Secuencias de Visualizar Aplicación Web .................................................... 67
Figura 3.31. Diagrama Conceptual de la base de datos.......................................................................... 67
Figura 3.32. Diagrama Físico de la base de datos .................................................................................. 68
Figura 4.1. Clases del paquete mx.edu.cenidet.MapWebDesigner.Modelo.BaseDatos ......................... 70
Figura 4.2. Clase del paquete mx.edu.cenidet.MapWebDesigner.Modelo.ContextoCapas.................... 71
Figura 4.3. Clases del paquete mx.edu.cenidet.MapWebDesigner.Modelo.Logica................................ 71
Figura 4.4. Petición AJAX con acceso denegado al Servidor WMS ..................................................... 72
Figura 4.5. Clase del paquete mx.edu.cenidet.MapWebDesigner.Modelo.Proxy................................... 73
Figura 4.6. Petición AJAX con acceso denegado al Servidor WMS ..................................................... 73
Figura 5.1. Interfaz en la que se proporcionan los datos del usuario ..................................................... 77
Figura 5.2. Usuario registrado en la base de datos del sistema .............................................................. 77
Figura 5.3. Interfaz mostrada al registrar adecuadamente al usuario ..................................................... 78
Figura 5.4. Interfaz mostrada al ingresar un login registrado................................................................. 78
Figura 5.5. Ingreso al sistema................................................................................................................. 79
Figura 5.6. Interfaz de rechazo al ingreso del sistema ........................................................................... 80
Figura 5.7. Interfaz de error de conexión con la base de datos .............................................................. 80
Figura 5.8. Catálogo de mapas ............................................................................................................... 81
Figura 5.9. Visualización del mapa solicitado ....................................................................................... 82
Figura 5.10. Estado del mapa antes de ser estilizado ............................................................................. 83
Figura 5.11. Mapa después de aplicarle la configuración de línea sólida .............................................. 83
Figura 5.12. Mapa después de aplicarle la configuración de línea punteada ......................................... 84
Figura 5.13. Mapa de México antes de ser personalizado ...................................................................... 85
Figura 5.14. Mapa de México con estilo personalizado ......................................................................... 85
Figura 5.15. Puntos del mapa de México antes de ser personalizado .................................................... 86
Figura 5.16. Puntos con estilo personalizado ......................................................................................... 86
Figura 5.17. Puntos personalizados utilizando un gráfico...................................................................... 87
Figura 5.18. Mapa de México antes de personalizar el texto ................................................................. 88
Figura 5.19. Mapa con personalización de texto utilizando la ubicación PointPlacement. ................... 88
Figura 5.20. Mapa de México antes de aplicar la configuración de texto .............................................. 89
~ iv ~
Figura 5.21. Mapa de México que muestra el estilo de texto con rotación ............................................ 89
Figura 5.22. Mapa de la vialidad de Cuernavaca antes de aplicar estilo de texto .................................. 90
Figura 5.23. Mapa con personalización de texto utilizando la ubicación LinePlacement...................... 90
Figura 5.24. Mapa de Morelos que muestra la estilización del texto ..................................................... 91
Figura 5.25. Documento SLD ................................................................................................................ 92
Figura 5.26. Mapa que muestra el estilo descrito en el documento SLD ............................................... 92
Figura 5.27. Variable tempText que contiene la plantilla de aplicación Web y el mapa solicitado....... 93
Figura 5.28. Carpeta Web del usuario .................................................................................................... 93
Figura 5.29. Plantilla de estilo publicado en la Web .............................................................................. 94
Figura 5.30. Interfaz para iniciar sesión ................................................................................................. 95
Figura 5.31. Interfaz de opciones a elegir en una sesión activa ............................................................. 95
Figura 5.32. Interfaz del catálogo de mapas que provee el WMS .......................................................... 96
Figura 5.33. Mapa de México sin estilos definidos por el usuario ......................................................... 96
Figura 5.34. Estilización de puntos ........................................................................................................ 97
Figura 5.35. Estilización de líneas ......................................................................................................... 97
Figura 5.36. Estilización de polígonos ................................................................................................... 98
Figura 5.37. Estilización de texto ........................................................................................................... 98
Figura 5.38. Documento XML que describe los estilos definidos por el usuario .................................. 99
Figura 5.39. Elección de plantilla Web .................................................................................................. 99
Figura 5.40. Publicación del mapa en plantilla de aplicación Web...................................................... 100
Figura 5.41. Publicaciones realizadas por el usuario ........................................................................... 100
Figura A.1. Referencia a la librería msCross ....................................................................................... 110
Figura A.2. Definición de elemento DIV y solicitud a servidor de la NASA ...................................... 111
Figura A.3. Visualización de mapas..................................................................................................... 111
Figura A.4. Referencia a la librería OpenLayers.................................................................................. 112
Figura A.5. Creación de objeto mapa ................................................................................................... 112
Figura A.6. Solicitud al servidor Geoserver utilizando OpenLayers ................................................... 112
Figura A.7. Adición de la capa México al objeto map ......................................................................... 113
Figura A.8. Elemento DIV con identificador map ............................................................................... 113
Figura A.9. Llamada de la función init() .............................................................................................. 113
Figura A.10. Mapa de México visualizado utilizando OpenLayers ..................................................... 113
Figura A.11. Visualización de mapas con Ka-Map.............................................................................. 115
Figura A.12. Creación de petición a WMS. ......................................................................................... 116
Figura A.13. Definición de elemento DIV ........................................................................................... 116
Figura A.14. Definición de función init()............................................................................................. 116
Figura A.15. Invocación de función init() ............................................................................................ 116
Figura A.16. Mapa visualizado en WMS JavaScript Library .............................................................. 117
Figura A.17. Referencia a la librería Mapbuilder.js ............................................................................. 118
Figura A.18. Configuraciones utilizadas en documentos HTML o JSP............................................... 118
Figura A.19. Trozo de código XML del archivo config.xsd ................................................................ 119
Figura A.20. Archivo de configuración ............................................................................................... 119
Figura A.21. Trozo de código XML del archivo demisWorldMap.xml .............................................. 120
~v~
Figura A.22. Mapa visualizado en Mapbuilder .................................................................................... 120
Figura A.23. Gráfico comparativo de la evaluación de las APIs ......................................................... 122
Figura A.24. Resultados de la evaluación de APIs .............................................................................. 123
Figura B.1. Mapa visualizado en Degree. ........................................................................................... 127
Figura B.2. Ingreso a Configuración. ................................................................................................... 128
Figura B.3. Inicio de sesión en Geoserver............................................................................................ 128
Figura B.4. Ingreso a los datos de Geoserver. ...................................................................................... 128
Figura B.5. Configuración de espacio de nombres. ............................................................................. 129
Figura B.6. Creación del espacio de nombres. ..................................................................................... 129
Figura B.7. Visualización del espacio de nombre México creado. ...................................................... 129
Figura B.8. Creación de un nuevo almacén de datos. .......................................................................... 130
Figura B.9. Editor del almacén de datos .............................................................................................. 130
Figura. B.10. Entidades disponibles en Geoserver ............................................................................... 131
Figura B.11. Entidades disponibles en Geoserver ................................................................................ 131
Figura B.12. Visualización del mapa de México en Geoserver ........................................................... 132
Figura B.13. Archivo .map ................................................................................................................... 135
Figura B.14. Archivo de inicialización ejemplo2.html ........................................................................ 135
Figura B.15. Mapa visualizado en MapServer ..................................................................................... 136
Figura B.16. Gráfico comparativo de la evaluación de los servidores de mapas ................................. 137
Figura B.17. Resultados de la evaluación de servidores de mapas ...................................................... 140
Figura C.1. Diagrama de objetos SLD ................................................................................................. 142
Figura C.2. Diagrama de clases SLD ................................................................................................... 143
Figura D.1. Esquema SLD del elemento raíz ....................................................................................... 146
Figura D.2. Esquema de elemento NamedLayer .................................................................................. 147
Figura D.3. Esquema de elemento UserLayer ..................................................................................... 147
Figura D.4. Esquema de elemento RemoteOWS .................................................................................. 148
Figura D.5. Esquema XML para el elemento LayerFeatureConstraints ............................................. 148
Figura D.6. Ejemplo de capa definida por el usuario ........................................................................... 149
Figura D.7. Esquema XML del estilo definido por el usuario ............................................................. 149
Figura D.8. Ejemplo de UserStyle........................................................................................................ 150
Figura D.9. Esquema XML de FeatureTypeStyle ................................................................................ 150
Figura D.10. Esquema XML del elemento Rule .................................................................................. 151
Figura D.11. Esquema XML de LegendGraphic ................................................................................. 151
Figura D.12. Esquema XML para MinScaleDenominator y MaxScaleDenominator .......................... 152
Figura D.13. Ejemplo de Filter y ElseFilter ......................................................................................... 152
Figura D.14. Esquema XML de la simbolización Lineal ..................................................................... 153
Figura D.15. Esquema XML de Geometry .......................................................................................... 153
Figura D.16. Ejemplo de uso de Geometry .......................................................................................... 153
Figura D.17. Esquema XML de Stroke ................................................................................................ 154
Figura D.18. Esquema XML de CssParameter ................................................................................... 154
Figura D.19. Esquema XML de GraphicFill ....................................................................................... 154
Figura D.20. Esquema XML de GraphicStroke ................................................................................... 155
~ vi ~
Figura D.21. Ejemplo de LineSymbolizer ............................................................................................ 155
Figura D.22. Resultado al aplicar la simbolización LineSymbolizer definida en la figura (D.21) ....... 155
Figura D.23. Esquema XML de PolygonSymbolizer ........................................................................... 155
Figura D.24. Esquema XML de Fill .................................................................................................... 156
Figura D.25. Ejemplo de estilización poligonal ................................................................................... 156
Figura D.26. Resultado de la definición mostrada en la figura (D.25) ................................................ 156
Figura D.27. Esquema XML de PointSymbolizer ................................................................................ 156
Figura D.28. Esquema XML de Graphic y ExternalGraphic .............................................................. 157
Figura D.29. Esquema XML Mark ...................................................................................................... 158
Figura D.30. Ejemplo de estilización Puntual ...................................................................................... 158
Figura D.31. Resultado de la definición mostrada en la figura (D.30) ................................................ 158
Figura D.32. Esquema XML de TextSymbolizer.................................................................................. 159
Figura D.33. Esquema XML de Font................................................................................................... 159
Figura D.34. Esquema XML de LabelPlacement, PointPlacement y LinePlacement ......................... 160
Figura D.35. Esquema XML de AnchorPoint ...................................................................................... 160
Figura D.36. Valores que puede tomar AnchorPoint ........................................................................... 160
Figura D.37. Esquema XML de Halo .................................................................................................. 162
Figura D.38. Ejemplo de simbolización Texto ..................................................................................... 163
Figura D.39. Resultado de la definición mostrada en la figura (D.38) ................................................ 163
~ vii ~
INDICE DE TABLAS
Tabla 1.1. Comparativa de las aplicaciones Web estudiadas con la propuesta. ..................................... 15
Tabla 2.1. Caracteres reservados en WMS para una cadena de consulta ............................................... 21
Tabla 2.2. Estructura de petición HTTP GET ........................................................................................ 22
Tabla 2.3. Parámetros para la solicitud GetCapabilities ........................................................................ 25
Tabla 2.4. Parámetros para la solicitud GetMap .................................................................................... 26
Tabla 2.5. Parámetros para la solicitud GetFeatureInfo ........................................................................ 28
Tabla 3.1. Descripción de caso de uso Registrar Usuario ...................................................................... 41
Tabla 3.2. Descripción del caso de uso Autentificar Usuario ................................................................ 42
Tabla 3.3. Descripción de caso de uso Diseñar Mapa ............................................................................ 44
Tabla 3.4. Descripción de caso de uso Solicitar Mapa ........................................................................... 45
Tabla 3.5. Descripción de caso de uso Aplicar Estilos .......................................................................... 46
Tabla 3.6. Descripción de caso de uso Generar Código XML ............................................................... 48
Tabla 3.7. Descripción de caso de uso Elegir Plantilla de Diseño ......................................................... 50
Tabla 3.8. Descripción de caso de uso Publicar Aplicación Web .......................................................... 51
Tabla 3.9. Descripción de caso de uso Visualizar Aplicación Web ....................................................... 52
Tabla 3.10. Simbología utilizada en diagramas de secuencias............................................................... 57
Tabla 5.1. Caso de prueba MAPWEBDE-01.01 Registro de usuarios .................................................. 77
Tabla 5.2. Caso de prueba MAPWEBDE-01.02 Autentificación al sistema ......................................... 79
Tabla 5.3. Caso de prueba MAPWEBDE-01.03 Rechazo al inicio de sesión........................................ 79
Tabla 5.4. Caso de prueba MAPWEBDE-01.04 Acceso al sistema ...................................................... 81
Tabla 5.5. Caso de prueba MAPWEBDE-02 Solicitud y visualización de mapas................................. 82
Tabla 5.6. Caso de prueba MAPWEBDE-03.01 Estilizar líneas ........................................................... 82
Tabla 5.7. Caso de prueba MAPWEBDE-03.02 Estilizar polígonos ..................................................... 84
Tabla 5.8. Caso de prueba MAPWEBDE-03.03 Estilizar puntos .......................................................... 86
Tabla 5.9. Caso de prueba MAPWEBDE-03.04 Estilizar texto ............................................................. 87
Tabla 5.10. Caso de prueba MAPWEBDE-03.05 Generación de Código XML ................................... 91
Tabla 5.11. Caso de prueba MAPWEBDE-04 Asociar mapa a plantilla de página Web ...................... 93
Tabla 5.12. Caso de prueba MAPWEBDE-05 Publicación de la página Web ...................................... 93
Tabla 5.13. Caso de prueba MAPWEBDE-06 Visualización de la página Web ................................... 94
Tabla 5.14. PRUEBA DE INTEGRACION-Funcionamiento general del sistema ................................ 95
Tabla A.1. Navegadores soportados por Ka-Map ................................................................................ 114
Tabla A.2. Definición de criterios ........................................................................................................ 120
Tabla A.3. Asignación de ponderaciones a cada criterio ..................................................................... 121
Tabla A.4. Asignación de calificaciones a cada API de acuerdo a los criterios ................................... 121
Tabla A.5. Obtención de productos por criterio .................................................................................. 121
Tabla A.6. Obtención de sumatorias por API ...................................................................................... 121
Tabla A.7. Asignación de ponderaciones a cada criterio ..................................................................... 123
Tabla A.8. Matriz de evaluación .......................................................................................................... 124
Tabla B.1. Abstracto de etiquetas usadas en MapServer ..................................................................... 134
Tabla B.2. Definición de criterios ........................................................................................................ 136
Tabla B.3. Asignación de ponderaciones a cada criterio ..................................................................... 136
~ viii ~
Tabla B.4. Asignación de calificaciones a cada servidor de mapas de acuerdo a los criterios ............ 137
Tabla B.5. Obtención de productos por criterio .................................................................................. 137
Tabla B.6. Obtención de sumatorias por WMS.................................................................................... 137
Tabla B.7. Asignación de ponderaciones a cada criterio ..................................................................... 138
Tabla B.8. Comparativa de servidores ................................................................................................. 139
Tabla D.1. Ejemplos de ubicaciones puntuales .................................................................................... 161
Tabla D.2. Ejemplos de desplazamientos............................................................................................. 161
Tabla D.3. Ejemplos de rotación .......................................................................................................... 161
Tabla D.4. Ejemplos de localización lineal .......................................................................................... 162
Tabla E.1. Elementos de prueba ........................................................................................................... 167
Tabla E.2. Descripción de las tareas de prueba .................................................................................... 168
Tabla E.3. Requisitos ambientales ....................................................................................................... 169
Tabla E.4. Casos de prueba .................................................................................................................. 170
~ ix ~
GLOSARIO
AdSense
Es un sistema de publicidad de Google que hace coincidir los anuncios con el
contenido de un sitio. Estos anuncios están administrados por Google y generan
ingresos basándose en los clics de los visitantes de la página y en las
visualizaciones de la misma [ADSENSE, 2008].
API
Interfaz de Programación de Aplicaciones (Application Programming Interface
por sus siglas en inglés). Es el conjunto de funciones y procedimientos que
ofrece cierta biblioteca para ser utilizada por otro software como una capa de
abstracción. Representa una interfaz de comunicación entre componentes de
software [WIKIAPI, 2007].
Capa
Unidad básica de información geográfica que puede solicitarse a un servidor
como un mapa [LOPEZ, 2006].
Cartografía La cartografía es la creación, la producción y el estudio de mapas. Se considera
una subdisciplina de la geografía [LEARNER 2003].
CVS
Valores Separados por Coma (Comma-Separated Values por sus siglas en
inglés) es un tipo de documento sencillo para representar datos en forma de
tabla, en la que las columnas se separan por comas y las filas por saltos de línea
[RFC4180, 2005].
ESRI
Instituto de Investigación de Sistemas Ambientales (Enviromental Systems
Research Institute por sus siglas en inglés) es una empresa dedicada al
desarrollo y comercialización de Sistemas de Información Geográfica [ESRI,
2008].
Geomática
Es el término científico moderno que hace referencia a un conjunto de ciencias
en las cuales se integran los medios para la captura, tratamiento, análisis,
interpretación, difusión y almacenamiento de información geográfica. También
llamada información espacial o geoespacial. El término «geomática» está
compuesto por dos ramas "GEO" por Geoide, y MATICA por Informática, Es
decir estudio del Geoide o globo terrestre a través de la informática [DESIGE,
2008].
GeoRSS
Es un conjunto de estándares para representar información geográfica y está
construido dentro de la familia de estándares RSS [GEORSS, 2007].
GML
Lenguaje de Marcado Geográfico (Geography Markup Language por sus siglas
en inglés) es una gramática XML para transportar y expresar información
geográfica [OGCGML, 2007].
KML
Lenguaje de Marcas de KeyHole (Keyhole Markup Language por sus siglas en
inglés), es una gramática XML y un formato de archivo para la creación de
modelos y el almacenamiento de funciones geográficas como puntos, líneas,
imágenes, polígonos y modelos que se muestran en Google Earth, Google Maps
y otras aplicaciones [POKML, 2008].
~x~
Mapa
Representación de dos dimensiones de la distribución espacial de fenómenos o
de objetos. Por ejemplo, un mapa puede demostrar la localización de ciudades,
de gamas de la montaña, de los ríos, o de los tipos de roca en una región dada.
La mayoría de los mapas son planos, haciendo su producción, almacenamiento
y manipulación relativamente fácil. Los mapas presentan su información al
espectador en una escala reducida. Son más pequeños que el área que
representan y usan las relaciones matemáticas para mantener relaciones
geográficas proporcionalmente exactas entre los puntos. Los mapas muestran la
información usando los símbolos que se identifican en una leyenda
[LEWOTSKY, 2004].
MathML
El Lenguaje de Marcado Matemático (Mathematical Markup Language por sus
siglas en inglés) es un lenguaje de marcado basado en XML cuyo objetivo es
expresar notación matemática de forma que distintas máquinas puedan
entenderla, para su uso en combinación con XHTML en páginas Web y para
intercambio de información entre programas de tipo matemático [WIKIMATH,
2009].
Mashup
Aplicación Web híbrida que usa contenido de otras aplicaciones Web para crear
un nuevo contenido completo. El contenido de un mashup normalmente
proviene de sitios Web de terceros a través de una interfaz pública o usando una
API [WIKIMASH, 2009].
OGC
El Consorcio Geoespacial Abierto (Open Geospatial Consortium por sus siglas
en inglés) es un consorcio internacional de la industria conformado por 369
compañías, agencias gubernamentales y universidades cuyo fin es la definición
de estándares abiertos e interoperables dentro de los Sistemas de Información
Geográfica para facilitar el intercambio de la información geográfica en
beneficio de los usuarios [OGC, 2008].
RSS
Es una familia de los formatos XML para el intercambio de información.
Muchos sitios Web dinámicos, en especial Weblogs, proporcionan RSS para
difundir noticias o intercambiar contenido [GEORSS, 2007].
SGML
Lenguaje de Marcado General Normalizado (Standard Generalized Markup
Language por sus siglas en inglés) utilizado para especificar las reglas de
etiquetado de documentos [W3CSGML, 2009]
ShapeFile
Formato de tipo vectorial desarrollado por la compañía ESRI que almacena
elementos geográficos y atributos asociados a ellos. Está compuesto por
archivos .shp, .shx y .dbf [WIKISHP, 2008]
Sistema de
Referencia
Un sistema de referencia es un conjunto de coordenadas espacio-tiempo que
se requieren para poder determinar la posición de un punto [EDNEW, 2009].
SLD
Descriptor de Estilo de Capa (Styled Layer Descriptor por sus siglas en inglés)
es un esquema XML propuesto por la OGC como lenguaje estándar para
describir los estilos que dan apariencia a un mapa [OGCSLD, 2002].
~ xi ~
WMS
Servicio de Mapas en Web (Web Map Service por sus siglas en inglés) es una
especificación definida por la OGC caracterizada por ser un servicio que provee
mapas a través de la Web. Estos mapas tienen como fuente de información
datos vectoriales y ráster [OGCWMS, 2002].
WFS
Servicio de Fenómenos en Web (Web Feature Service por sus siglas en inglés)
es un servicio que permite consultar objetos geográficos regresando el resultado
de la consulta en formato GML [OGCWFS, 2002].
Widget
Pequeña aplicación o programa que realiza una función concreta, generalmente
de tipo visual, dentro de otras aplicaciones o sistemas operativos. Los widgets
pueden ser relojes vistosos en pantalla, nota, calculadoras, calendarios, agendas
o juegos [WIKIWIDG, 2009]
~ xii ~
CAPÍTULO 1
INTRODUCCIÓN
En el presente capítulo se expone la problemática que se abordó, el objetivo, la
justificación, beneficios, alcances y limitaciones del proyecto de tesis. Además se
muestra la investigación del estado del arte realizado y la organización general del
documento.
Capítulo 1 Introducción
1.1.
Introducción
Desde hace muchos siglos el hombre ha representando su entorno a través de mapas
plasmados en materiales como: tablillas de arcilla, seda y papel. A través de los años los
métodos de representación de mapas fueron mejorando y dieron lugar a la ciencia que hoy se
conoce como la ciencia cartográfica.
Gracias a los avances tecnológicos y científicos que se han desarrollado en las últimas
décadas, la cartografía ha mejorado de manera sorprendente con la incorporación de nuevas
tecnologías denominadas Sistemas de Información Geográfica (GIS, Geographic Information
System por sus siglas en inglés), los cuales han permitido que las aplicaciones y utilidades
informáticas visualicen mapas geográficos de diferentes temáticas y permitan realizar
consultas espaciales a través de la computadora.
Por otro lado, Internet se ha convertido en un medio ideal para la publicación de mapas
geográficos, esto ha sido posible gracias al surgimiento de los Servicios de Mapas por Internet
(WMS, Web Map Service por sus siglas en inglés), quienes han permitido publicar mapas
digitales en formatos vectorial y ráster (en el capítulo 2 de marco teórico se describen cada
uno de estos formatos). En particular, los mapas vectoriales, antes de ser publicados pasan por
un proceso de estilización en el que se asignan propiedades como color, tamaño y estilo a cada
uno de los elementos representados en el mapa (por ejemplo: puntos, líneas y polígonos).
Dicho proceso se convierte en una tarea compleja debido a que no existen herramientas que
permitan estilizar mapas en un ambiente Web, por lo que el diseñador de mapas se vale de
herramientas de escritorio que a menudo suelen ser muy complicadas.
Por lo anterior y para dar una solución estándar (siguiendo la especificación SLD de la OGC),
surge la idea de crear una herramienta de software estilizadora de mapas que demuestre, que
es posible crear estilos personalizados por el diseñador de manera sencilla. Estos estilos se
verán reflejados mediante un archivo SLD basado en XML, el cual describirá detalladamente
los estilos aplicados a cada uno de los puntos, líneas y polígonos representados en un mapa
vectorial. Como resultado, se obtendrá un archivo SLD independiente del mapa vectorial
visualizado, el cual será asociado al mapa base al momento de ser publicado en un Servidor de
Mapas.
1.2.
Descripción del problema
Existen herramientas de escritorio y APIs tanto propietarias como libres para la creación y
estilización de mapas. Lo que respecta a las herramientas de escritorio gratuitas, proporcionan
al usuario funciones para la consulta, edición y creación de planos. Son herramientas
complejas de utilizar y requieren instalarse en la máquina local. En cuanto a las APIs de
código abierto, proporcionan funciones que permiten manipular y visualizar mapas en
Internet, pero no se ha encontrado una aplicación que implemente funciones destinadas a la
estilización de mapas utilizando un API de código libre. Es por lo anterior que el problema
que dio origen a la presente tesis se centra en que no se han encontrado aplicaciones Web que
contengan tanto mapas geográficos como interfaces que permitan diseñar la apariencia del
mapa y la interacción con el mismo, debido a la falta de aplicaciones que faciliten y
automaticen la integración de estas dos cosas.
Página 2
Capítulo 1 Introducción
1.3.
Objetivos
Contribuir a la creación de prototipos de aplicaciones Web de forma rápida, mediante la
implementación de una herramienta de software que proporcione servicios que permitan
diseñar la apariencia e interacción con mapas temáticos utilizando el estándar XML y APIs de
código abierto que incluyan servicios de acceso a servidores de mapas. El diseño y la
implementación de esta herramienta deben proporcionar servicios de interacción asíncronos
(AJAX) para optimizar la solicitud de mapas vectoriales a los servidores de mapas.
Objetivos específicos:
 Seleccionar un servidor de mapas de software libre con la finalidad de utilizarlo como
gestor de mapas.
 Utilizar componentes que permitan la interacción con mapas, por ejemplo, zoom in,
zoom out y paneo.
 Colaborar con la configuración de objetos contenidos en mapas, como son: texto,
polígonos, líneas y puntos. A estos objetos se les deben definir el color, ancho de línea,
tipo de línea, contorno de las líneas de polígonos, color de relleno, nivel de
transparencia, y tipo de letra.
 Generar de forma automática un archivo XML que describa los estilos que definen la
apariencia del mapa. Realizando esto de acuerdo a las propiedades asignadas a los
objetos punto, línea, polígono y texto del mapa
1.4.
Justificación
De acuerdo a estadísticas publicadas por la Asociación Mexicana de Internet (AMIPCI), el uso
de la industria de Internet en México se mantiene en crecimiento. Según el estudio realizado
en el rubro de comercio electrónico, el crecimiento registrado del año 2006 al 2007 fue de un
78% equivalente a un importe de 955 millones de dólares en ventas electrónicas.
Pronosticando un 70% de crecimiento para el año 2008 (ver figura 1.1).
Figura 1.1. Estudio del uso de comercio electrónico en México.
FUENTE: Asociación Mexicana de Internet (AMIPCI)
Página 3
Capítulo 1 Introducción
Lo anterior pone en evidencia que el desarrollo y uso de aplicaciones Web han mantenido su
crecimiento y con el pasar de los años, van buscando información más precisa en términos de
datos de ubicación que enriquezcan y visualicen sus servicios. Con los avances tecnológicos
actuales, es posible mostrar esta información a través de mapas para que los usuarios puedan
fácilmente ubicar y visualizar objetos, lugares de interés además de otros servicios vía Web
dependiendo de la temática del mapa. Para realizar esto, existen APIs y herramientas
disponibles en la Web de manera gratuita que proporcionan el servicio de visualización de
mapas.
La importancia de los mapas va desde saber donde se encuentra cierto servicio, hasta el de
salvar la vida a toda una población. Por ejemplo, un mapa de carreteras es una guía que
proporciona información de cómo llegar a otro lugar, un mapa meteorológico ayuda a los
científicos a ubicar dónde y hacia dónde van los huracanes, tornados, incendios, etc. Y con
ello poder alertar a la gente para que evacuen las zonas de riesgos y se salven vidas.
Por naturaleza el ser humano diferencia objetos por su forma, tamaño y también por su color.
Por ello la interpretación de un mapa no es sencilla si no posee colores y claves que describan
los objetos utilizados en un mapa. En particular la presente tesis se enfocó en la aplicación de
estilos a objetos punto, línea, polígono y texto de mapas vectoriales.
Por otra parte, desde el enfoque del diseñador de aplicaciones Web, existen aspectos
importantes que se mencionan a continuación y dieron pauta a la factibilidad de esta
investigación.
Para crear un mapa con las APIs disponibles de código abierto, se requiere de asimilar cada
una de ellas y después utilizar sólo las funciones que se necesiten de la API elegida. En esta
parte se requiere de tiempo suficiente para poder conocer la API e implementar el código que
permitirá la visualización del mapa.
Una vez que se tienen los mapas visualizados, resulta necesario diseñar la apariencia del mapa
de acuerdo a las necesidades que se presenten. Esta etapa resulta una limitante más, que
retarda la realización de mapas de manera rápida, pues la edición se hace de forma manual
insertando líneas de código en un archivo XML.
Existen herramientas de escritorio que permiten diseñar la apariencia de mapas geográficos,
pero estas herramientas aplican el estilo directamente en los archivos vectoriales. La
desventaja de esto es que si un usuario modifica el estilo del mapa a sus necesidades, otro
usuario que utilice el mismo mapa visualizará las modificaciones del usuario anterior.
1.5.
Beneficios
El beneficio principal que se obtuvo de la presente tesis es una aplicación Web que
proporciona las siguientes funciones:
 Componentes de estilo: estos componentes permiten aplicar estilos definidos por el
usuario a objetos tipo punto, línea, polígono y texto de un mapa. Todo esto haciéndolo
de manera transparente para el usuario, es decir, sin tener que introducir ni una sola
línea de código.
Página 4
Capítulo 1 Introducción
 Generación de archivo SLD: la estilización aplicada al mapa se refleja en un archivo
XML que cumple con la especificación SLD definida por la OGC.
 Publicación del mapa en la Web: permite que el usuario al terminar de estilizar el
mapa, pueda seleccionar una plantilla de un catálogo de aplicaciones Web para que el
usuario publique su mapa estilizado.
 Solicitud de mapas a un servidor de mapas: la aplicación se comunica con un servidor
WMS para conocer los mapas y sistemas de referencias que provee. Esto con el
objetivo de construir un catálogo de mapas ordenado que se le proporciona al usuario
para elegir los mapas que desea estilizar.
1.6.
Alcances del proyecto de tesis
El trabajo de tesis tiene los siguientes alcances:
 Se proporciona una aplicación Web que utiliza funciones de un API de código libre
para interactuar con mapas de manera que se puede hacer zoom in, zoom out, paneo y
habilitar y deshabilitar capas.
 La aplicación Web desarrollada proporciona los siguientes servicios:
o Un conjunto de componentes Web para la configuración de objetos contenidos
en los mapas como son: texto, líneas, polígonos y puntos. A estos objetos
geográficos se les puede definir color de línea, ancho de línea, tipo de línea,
color de relleno de los polígonos, nivel de transparencia, tipo de letra entre
otros.
o Se permite generar un archivo XML que cumple con la especificación SLD el
cual describe los estilos aplicados al mapa geográfico.
o Se proporciona un catálogo de plantillas de aplicaciones Web el cual permite
asociar el mapa estilizado con la plantilla para posteriormente publicarlo en
Internet.
 La aplicación Web utiliza AJAX para la comunicación con el servidor de mapas y está
programada siguiendo el patrón MVC de java (struts) bajo la especificación J2EE para
facilitar su mantenimiento.
1.7.
Limitaciones del proyecto de tesis
El trabajo de tesis contempla las siguientes limitaciones:
 La aplicación corre sobre plataformas convencionales (máquinas de escritorio, laptops
y tablet’s pc).
 Los mapas manipulados en la aplicación son de tipo vectorial.
 La visualización de los mapas es en dos dimensiones.
 La aplicación no crea los mapas contenidos en el servidor de mapas.
 La temática de los mapas es de trazos carreteros y municipales.
 En la investigación no se contempla el desempeño y tiempos de respuesta de las APIs
y servidores manipuladores de información espacial.
 La investigación se aboca únicamente a proyectos de software libre que administran
información espacial.
Página 5
Capítulo 1 Introducción
1.8.
Estado de la práctica
La investigación del estado de la práctica cubre dos aspectos: el primero es entender el
contexto en el que se trabajó, para ello se hace una descripción sobre la clasificación de
proyectos de software libre disponibles para la manipulación de información espacial. Y el
segundo aspecto abarca la investigación de aplicaciones Web relacionadas con la presente
tesis.
Abordando el primer punto en la investigación del estado de la práctica se encontraron muchas
herramientas manipuladoras de información espacial.
Los proyectos que se encuentran en Geomática se clasifican en [MONTESINOS, 2007]:
Proyectos del lado del servidor. En este grupo se encuentran los servidores de bases de
datos geográficas, servidores de mapas y herramientas de metadatos.
Proyectos del lado del cliente. Este rubro se conforma por clientes pesados
(herramientas de escritorio) y clientes ligeros (APIs).
Servidores de bases de datos geográficas
Las bases de datos geográficas son similares a las relacionales con la diferencia que en la
primera se puede almacenar geometría. La OGC proporciona la especificación Simple
Features que describe el conjunto de tipos de datos y funciones que debe cumplir una base de
datos geográfica. Dentro de este grupo en la parte de software libre se encuentran PostGIS,
FireBird y MySQL Spatial (MySQL se ofrece con una licencia dual pues es GPL y es
distribuido a las empresas con licencia propietaria).
Servidores de mapas
Los servidores de mapas permiten publicar cartografía en la Web para que los usuarios puedan
interaccionar con información geográfica a través de Internet. La OGC proporciona la
especificación Web Map Service que describe los servicios que debe proporcionar un servidor
de mapas. Los proyectos de software libre que se han desarrollado para este grupo son UMN
MapServer, GeoServer, Degree y MapGuide OpenSource [MONTESINOS, 2007].
Herramientas de metadatos
Los servidores de catálogos son aplicaciones que permiten publicar en la red un conjunto de
metadatos sobre diferentes conjuntos de datos. Estos catálogos son expuestos como un portal
que permite hacer búsquedas mediante diferentes criterios. Los proyectos de software libre
que se han desarrollado bajo este rubro son Geonetwork y CaMDEdit [MONTESINOS, 2007].
Clientes pesados
Los clientes pesados son todas las aplicaciones de escritorio que han sido útiles para la gestión
de información geográfica. Las funciones que se tienen con estas herramientas son las de
edición, análisis y explotación de información geográfica. Existen muchos proyectos de
software libre en esta clasificación pero los más representativos son: Grass, Quantum GIS,
Página 6
Capítulo 1 Introducción
gvSIG, Saga y Sextante, MapWindow, World Wind, Open Jump , Kosmo, ILWIS y uDig
[MONTESINOS, 2007].
Clientes ligeros
Los clientes ligeros surgieron con la aparición de los servidores de mapas. Proporcionan un
conjunto de componentes o funciones que permiten a los desarrolladores de aplicaciones Web
crear páginas Web o aplicaciones Web con contenido espacial. Los proyectos más
representativos desarrollados bajo este rubro son: Ka-Map, Chamelon, CartoWeb,
OpenLayers, Mapbender, MapBuilder, msCross y WMS Java Script Library [MONTESINOS,
2007].
En la figura (1.2) se muestra de manera ilustrativa la clasificación mencionada anteriormente.
Figura 1.2. Clasificación de la Geomática respecto al software libre
De acuerdo a la clasificación anterior y tomando en cuenta los objetivos de la tesis. El presente
trabajo de tesis abarca la parte de servidores de mapas y clientes ligeros.
La segunda parte que conforma el estado de la práctica es la investigación de aplicaciones
Web que se relacionan con la presente tesis. En este estudio se encontraron un gran número de
aplicaciones Web que fueron desarrolladas en su mayoría utilizando la API de Google Maps y
Yahoo Maps. Las diferencias más sobresalientes que se encontraron entre las aplicaciones
fueron las temáticas que manejaban (clima, ruta de maratones, deportes, procedimientos
electorales, lugares de pesca, etc.), ya que en todos los sitios se permitían hacer búsquedas
sobre el mapa, calcular rutas e insertar puntos de interés (POIs), pero pocas aplicaciones
permitía exportar los objetos insertados en el mapa a archivos KML. No se encontraron
Página 7
Capítulo 1 Introducción
aplicaciones que permitieran estilizar los objetos del mapa visualizado, sólo se facilitaban
componentes que permitían dibujar líneas y polígonos sobre los mapas visualizados.
A continuación se exponen algunas aplicaciones Web disponibles en Internet que permiten
manipular información espacial, se describen sus característica más sobresalientes y se
mencionan las desventajas que presentan con el presente trabajo.
1.8.1. Click2Map
Es una aplicación Web que permite crear y publicar mapas de Google en línea. Cualquier
persona con acceso a Internet puede crear1 y publicar sus mapas en Internet sin tener que
codificar ni una sola línea de código [CLICK2MAP, 2008].
Servicios que proporciona:
1. Creación ilimitada de mapas con controles para manipularlo (“zoom in”, “zoom
out”, “paneo” y visualización del mapa en satelital, vectorial e hibrido).
2. Inserción ilimitada de marcadores que se pueden añadir en el mapa y permite
dibujar líneas y polígonos sobre el mapa con estilos definidos por el usuario.
3. Personalización de iconos de los marcadores.
4. Publicación del mapa como una página Web HTML.
5. Permite establecer cualquier mapa creado como widget ya que proporciona un
pequeño código en HTML el cual se puede copiar y pegar en una página Web
personal.
6. Si el usuario posee una cuenta de Adsense puede crear banners para poner
anuncios sobre sus mapas.
7. Permite borrar los anuncios de la página Web generada.
8. Importa o exporta marcadores de CSV, KML, GeoRSS y archivos XML.
9. Proporciona un API Web en la que se pueden manipular los marcadores de los
mapas en aplicaciones personales.
Click2Map gestiona cuatro tipos de usuarios: bronze, silver, gold y platinium.
Los usuarios de tipo bronze son aquellos que pueden utilizar el sistema de manera gratuita
pero limitado a las primeras cuatro funciones presentadas en la lista anterior. Los usuarios tipo
silver, gold y platinium son usuarios que pagan mensualmente una cantidad en dólares que van
desde los $9 dólares hasta $39 dólares para gozar de los demás servicios.
En la figura (1.3) se muestra la interfaz que proporciona la aplicación Click2Map.
1
El termino crear no significa que el usuario dibuja el mapa, sino que a partir de los mapas de Google el usuario
elige que porción del mapa o extensión territorial desea visualizar en la página Web que genera click2map. Esa
extensión territorial es un nuevo mapa que manipula la aplicación y por lo tanto lo considera como un mapa
creado por el usuario.
Página 8
Capítulo 1 Introducción
Figura 1.3. Interfaz de usuario de Click2Map
En la figura (1.4) se muestra el mapa creado en Click2Map y publicado en la Web.
Figura 1.4. Publicación del mapa creado en Click2Map
La principal desventaja de esta aplicación con la que se desarrolló, es que el usuario debe
pagar una cantidad mensual para poder utilizar el mapa generado como widget de una página
personal. Utiliza los mapas de Google y por lo tanto no los puede estilizar, lo único que puede
realizar el usuario es insertar y administrar POIs personalizados.
Página 9
Capítulo 1 Introducción
1.8.2. Map24
Es un buscador de direcciones disponible en la Web de manera gratuita [MAP24, 2008].
Servicios que proporciona:
1. Realiza búsquedas de direcciones y de puntos de interés.
2. Permite el cálculo de rutas.
3. Guarda un máximo de 10 direcciones en la libreta de direcciones de cada usuario.
4. Las direcciones antes de ser almacenadas pueden ser modificadas por el usuario.
5. Envía direcciones vía correo electrónico con un máximo de 10 remitentes.
6. Permite ver los mapas en tres dimensiones.
7. No permite agregar puntos de interés ni direcciones de empresas.
8. Proporciona dos tipos de mapas: estáticos y dinámicos.
9. Proporciona controles para manipular el mapa: “zoom in”, “zoom out”, “paneo” y
visualización de mapas en formato ráster y vectorial.
En la figura (1.5) se muestra la interfaz de map24.
Figura 1.5. Interfaz de Map24
La desventaja de esta aplicación es que únicamente se enfoca a realizar búsquedas sobre el
mapa y por lo tanto no ofrece el servicio de estilización y publicación de los mapas en una
página Web que contengan el mapa estilizado.
1.8.3. ZoomIn
Esta aplicación Web proporciona los siguientes servicios [ZOOMIN, 2007]:
1. Permite realizar búsquedas de direcciones.
2. Explora lugares cercanos a un punto.
3. Los usuarios inscritos pueden realizar comentarios acerca de un lugar.
4. Permite subir fotografías a un lugar en específico.
Página 10
Capítulo 1 Introducción
5.
Los usuarios pueden crear grupos o agregarse a uno existente.
La desventaja que presenta este sitio es que no permite que los usuarios estilicen los mapas y
que puedan usar estos mapas en una aplicación Web. Sólo se aboca a la inserción de puntos
con documentos asociados.
En la figura (1.6) se ilustra la interfaz de ZoomIn.
Figura 1.6. Interfaz de ZoomIn
1.8.4. MapBuilder
Es una aplicación gratuita vía Web que permite crear mapas de Google Maps.
[MAPBUILDER, 2007].
Servicios que proporciona:
1. Búsquedas de direcciones sobre el mapa.
2. Añade marcas sobre el mapa especificando información acerca del punto como
son: título, descripción, dirección, coordenadas y tipo de marca.
3. Genera código JavaScript y HTML para colocar el mapa en una aplicación Web
personal.
4. Los mapas creados se guardan en la cuenta del usuario.
5. Proporciona mecanismos para manipular el mapa. (“zoom in”, “zoom out” y
“paneo”)
La figura (1.7) muestra la interfaz de ésta aplicación web.
Página 11
Capítulo 1 Introducción
Figura 1.7. Interfaz de MapBuilder
Al igual que las aplicaciones anteriores MapBuilder se limita a realizar inserciones de
marcadores sobre los mapas proporcionados por Google Maps y no permite cambiar las
especificaciones de estilo de los mapas visualizados.
1.8.5. Google Maps
API gratuita de Google lanzada el 6 de octubre de 2005 la cual ofrece las siguientes
características [WIKIGMAPS, 2007]:
Capacidad de hacer acercamientos y alejamientos para mostrar el mapa.
Permite hacer búsquedas de direcciones.
Calcular la ruta optima entre dos puntos.
Ride Finder (ubicador de vehículo) en el cual una persona puede ubicar un taxi o un
transporte público en una gran ciudad en tiempo real.
Además de lo anterior permite integrar los mapas en sitios Web que usan JavaScript. Se
pueden dibujar marcadores y líneas sobre el mapa. [GOOGLEMAPS, 2007]
La principal desventaja de esta aplicación, es el de la estilización personalizada de los mapas,
ya que Google Maps no permite que los usuarios cambien las propiedades de color y tamaño
de los objetos que se muestran en el mapa.
En la figura (1.8) se muestra la interfaz de Google Maps.
Página 12
Capítulo 1 Introducción
Figura 1.8. Interfaz de Google Maps
1.8.6. Yahoo Maps
Es una aplicación libre en línea que ofrece los siguientes servicios [YAHOOMAPS, 2007]:
1. Realizar búsquedas en los mapas proporcionados por Yahoo.
2. Visualizar el tránsito en vivo sobre las ciudades.
3. Guardar el mapa en una página Web asociada a la cuenta del usuario.
4. Enviar el mapa por correo electrónico.
5. Imprimir los mapas.
La disponibilidad de estos servicios abarca Estados Unidos y Canadá.
La desventaja de esta herramienta con respecto a la que se implementó es que Yahoo Maps no
permite la estilización de los mapas en línea y sólo se pueden consultar los mapas que provee
por default.
En la figura (1.9) se muestra la interfaz de Yahoo Maps.
1.8.7. Live Search Maps
Es una aplicación Web desarrollada por Microsoft y sus principales funciones son
[MICROSIFTLIVE, 2008]:
1. Visualiza imágenes en 2D y 3D (si se instala un plugin)
2. Permite insertar puntos de interés, dibujar líneas y polígonos definiendo un estilo
personalizado y exportar estos objetos a un archivo KML.
3. Realiza búsquedas de direcciones.
4. Calcula la ruta más corta entre dos puntos.
En la figura (1.10) se muestra la interfaz de Virtual Earth.
Página 13
Capítulo 1 Introducción
Figura 1.9. Interfaz de Yahoo Maps
Figura 1.10. Interfaz de Virtual Earth
A continuación en la tabla (1.1) se muestra la comparativa de los trabajos relacionados con
el trabajo de tesis, el cual a partir de aquí se le hará referencia con el nombre de MapWeb
Designer (Design of maps in web).
Página 14
Capítulo 1 Introducción
Tabla 1.1. Comparativa de las aplicaciones Web estudiadas con la propuesta.
Aplicaciones
Web
Visualización
de mapas
Click2Map
Sí
Map24
ZoomIn
Map Builder
Sí
Sí
Sí
Google Maps
Sí
Yahoo Maps
Sí
Live Search
Maps
Sí
MapWeb
Designer
(TESIS)
Sí
Estilización de
LINEAS del
mapa basado
en XML
Estilización de
POLIGONOS del
mapa basado
en XML
Estilización de
TEXTO del
mapa basado
en XML
Publicación del
mapa en una
página Web
elegida por el
usuario
No, sólo dibuja
líneas con
estilos definidos
por el usuario
No, sólo dibuja
polígonos con
estilos definidos
por el usuario.
No
Si, publica el
mapa pero el
usuario no elige
la página Web
No
No
No
No
No
No
No
No
No
No
No
Sí
No
No
No
Sí
No
No, sólo dibuja
líneas sobre el
mapa y los
exporta a KML
No
No, sólo dibuja
polígonos sobre
el mapa y los
exporta a KML
No
Sí
No
No
Sí
Sí
Sí
Sí
Estilización de
PUNTOS del
mapa basado
en XML
No, sólo
permite la
personalización
de POIs
insertados
sobre el mapa
No
No
No
No, utiliza KML
para describir
los POIS
insertados
No
No, únicamente
inserta puntos
de interés y los
exporta a KML
Sí
1.9. Organización del documento
Los siguientes capítulos del documento de tesis se organizan de la siguiente manera:
Capítulo 2 Marco Teórico. Se describen los conceptos teóricos sobre las tecnologías
involucradas en el desarrollo de la tesis.
Capítulo 3 Análisis y Diseño. En este capítulo se describe la fase de análisis y diseño realizado
y para ello se presentan los casos de uso, diagramas de actividad, diagramas de clases y
diagramas de secuencia que se requirieron para el desarrollo del sistema.
Capítulo 4 Implementación. Se explica el funcionamiento general del sistema.
Capítulo 5 Pruebas. Se presentan los resultados de las pruebas realizadas al sistema.
Capítulo 6 conclusiones. En este capítulo se presentan las conclusiones, aportaciones de la
tesis y los trabajos futuros.
Al final del documento se presenta la sección de anexos los cuales se organizan como sigue:
en el anexo A se describe la evaluación de las APIs de código libre. En el anexo B se muestra
la evaluación de los servidores de mapas, en el anexo C se presenta el modelo de objetos y el
modelo de clases del documento SLD, en el anexo D se expone la especificación SLD y en el
anexo E se presenta el plan de pruebas.
Página 15
Capítulo 1 Introducción
Página 16
CAPÍTULO 2
MARCO TEÓRICO
En este capítulo se describen conceptos elementales de las tecnologías involucradas
en el desarrollo de la presente tesis.
Capítulo 2 Marco Teórico
2.1.
Sistemas de Información Geográfica
Un Sistema de Información Geográfica (GIS, en su acrónimo inglés) es un sistema informático
integrado que permite el almacenamiento, mapeo, manipulación y análisis de datos
geográficos o espaciales. Puede presentar la información en diferentes capas temáticas
almacenándolas de manera independientemente, permitiendo trabajar con ellas de manera
rápida y sencilla, y facilitando al profesional la posibilidad de relacionar la información
existente a través de la topología de los objetos, con el fin de generar otra nueva que no se
podría obtener de otra forma [VON, 2005].
En la figura (2.1) se observan varias capas que son puestas unas sobre otras para poder
representar con mayor exactitud a la realidad.
Figura 2.1. Capas que representan la realidad
Los sistemas de información geográfica requieren de varios componentes para poder funcionar
correctamente. Estos componentes son una colección organizada de hardware, software, datos
geográficos y personal. Diseñados para capturar, almacenar, manipular, analizar y desplegar
en todas sus formas la información geográficamente referenciada con el fin de resolver
problemas complejos de planificación y gestión [VON, 2005].
Hardware. Es el equipo donde opera el GIS. Hoy en día los programas GIS se pueden
ejecutar en gran número de equipos que van desde servidores hasta computadoras portátiles
usados en red o trabajando en modo desconectado [CARMONA, 2007].
Software. Los programas GIS proveen las funciones y las herramientas necesarias para
almacenar, analizar y desplegar la información geográfica. Los principales componentes de los
programas son [CARMONA, 2007]:
Herramientas para la entrada y manipulación de la información geográfica.
Un sistema de manejador de base de datos (DBMS)
Herramientas que permitan búsquedas geográficas, análisis y visualización.
Interface gráfica para el usuario (GUI) para acceder fácilmente a las herramientas.
Página 18
Capítulo 2 Marco Teórico
Datos geográficos. La parte más importante de un sistema de información geográfico son sus
datos. Los datos geográficos y tabulares pueden ser adquiridos por quien implementa el
sistema de información, así como por terceros que ya los tienen disponibles. El sistema de
información geográfico integra los datos espaciales con otros recursos de datos y puede
incluso utilizar los manejadores de base de datos más comunes para manejar la información
geográfica [CARMONA, 2007].
Personal. La tecnología de los GIS está limitada si no se cuenta con el personal que opera,
desarrolla y administra el sistema y que establece planes para aplicarlo en problemas del
mundo real [CARMONA, 2007].
Una segunda definición más concreta es la que se proporciona en [LBSPRO, 2007]: Un
sistema de información geográfico brinda funcionalidades para análisis y consultas espaciales.
Los tipos de preguntas que puede responder un GIS son las siguientes [LBSPRO, 2007]:
¿Qué se encuentra en...? (Pregunta de ubicación. Qué existe en una ubicación
particular)
¿Dónde está...? (Pregunta condicional. Qué ubicación satisface ciertas condiciones)
¿Cuáles datos están relacionados...? (Pregunta relacional. Analiza la relación espacial
entre objetos de atributos geográficos)
¿Qué pasaría si...? (Pregunta de simulación. Computa y despliega una ruta óptima, un
terreno apropiado, una área de riesgo para desastres basado en un modelo)
Existen dos tipos de información que manipulan los sistemas GIS:
Información ráster.
Información vectorial.
2.1.1. Información ráster [SARRIA,2007]
El modelo de GIS ráster o de retícula se centra en las propiedades del espacio más que en la
precisión de la localización. Divide el espacio en celdas regulares donde cada una de ellas
representa un único valor. Una capa en formato ráster está compuesta por cuatro elementos
fundamentales:
La matriz de datos la cual se almacena en un archivo como una lista de valores
numéricos.
Información geográfica acerca de la matriz de datos y de su posición en el espacio
(número de columnas, número de filas, coordenadas de las esquinas de las capas y
resolución o tamaño de pixel en latitud y en longitud).
Tabla de colores que permite decidir de qué color se pintará cada celdilla en la
pantalla.
En el formato ráster cuanto mayor sean las dimensiones de las celdas (resolución) menor es la
precisión o detalle en la representación del espacio geográfico.
En la figura (2.2) se muestra cómo se organiza la información ráster y en la figura (2.3) se
ilustra con mayor detalle la organización de la información contenida en un pixel de una
imagen rasterizada.
Página 19
Capítulo 2 Marco Teórico
Figura 2.2. Organización de la información en el modelo de datos ráster
Figura 2.3. Información de un pixel
2.1.2. Información vectorial
Al contrario de lo que ocurre en el formato ráster, el formato vectorial define objetos
geométricos (puntos, líneas y polígonos) mediante la codificación explícita de sus
coordenadas. Los puntos se codifican en formato vectorial por un par de coordenadas en el
espacio, las líneas como una sucesión de puntos conectados y los polígonos como líneas
cerradas o como un conjunto de líneas que constituyen las diferentes fronteras del polígono.
Este formato resulta especialmente adecuado para la representación de entidades reales
ubicadas en el espacio (carreteras, ríos, parcelas de cultivo). El formato ráster resulta más
adecuado cuando se manejan datos que suponen un valor promediado sobre una extensión
territorial que se considera homogénea, por ejemplo estadísticas municipales, clima, zonas de
riesgo [SARRIA, 2007].
En la figura (2.4) se ilustran los objetos geométricos utilizados por el formato vectorial.
Figura 2.4. Objetos geométricos del formato vectorial
Página 20
Capítulo 2 Marco Teórico
2.2.
Open Gesospatial Consortium (OGC)
El Open Geospatial Consortium (OGC)es un consorcio internacional de la industria
conformado por 369 compañías, agencias gubernamentales y universidades que participan en
un proceso de consenso para desarrollar especificaciones de interconexión disponibles al
público. Las especificaciones OpenGis soportan soluciones interoperables para sistemas de
información geográfica y sistemas basados en localización con el objetivo de que los
desarrolladores de este tipo de tecnologías creen servicios e información espacial útiles y
disponibles a toda clase de aplicaciones [OGC, 2008].
Del conjunto de especificaciones que define la OGC, la especificación Styled Layer
Descriptor (SLD) y la Web Map Service fueron las que se estudiaron para desarrollar la
presente tesis.
2.2.1. Web Map Service(WMS)
Un Web Map Service (WMS por sus siglas en inglés) produce mapas en forma dinámica a
partir de información geográfica vectorial o ráster presentando la información como imágenes
digitales susceptibles de ser visualizadas en pantalla. La visualización de la imagen suele ser
en formato ráster: PNG, GIF o JPEG, y ocasionalmente, se representan como información
vectorial en formato Scalable Vector Graphics (SVG) o Web Computer Graphics Metafile
(WebCGM).
Los mapas visualizados pueden sobreponerse unos a otros, siempre y cuando los parámetros
geográficos y tamaño de salida sean los mismos. El uso de formatos que permiten fondo
transparente (por ejemplo GIF y JPEG) facilita la visualización simultánea de estos mapas.
Un WMS, acepta peticiones HTTP de aplicaciones cliente. La petición HTTP contiene la
solicitud de un mapa siguiendo la especificación WMS definida por la OGC. El WMS procesa
la solicitud y responde con el correspondiente mapa codificado en el formato indicado en la
petición y con el estilo de visualización solicitado. [BRISABOA, 2007]
Las peticiones HTTP pueden ser tipo GET o POST. Un servidor puede ofrecer uno o ambos
métodos siendo la petición GET una petición obligatoria y la petición POST una petición
opcional hablando en términos de implementación de WMSs.
De acuerdo a la especificación URL (IETF RFC 2396) se reservaron un conjunto de caracteres
especiales que estructuran la cadena de la petición al WMS.
A continuación en la tabla (2.1) se describe el significado de cada caracter especial
introducido en la URL de la petición HTTP.
Tabla 2.1. Caracteres reservados en WMS para una cadena de consulta
Fuente: tomado de [OGC, 2002]
Caracter
Uso Reservado
Indica el inicio de la cadena de consulta.
?
Separador entre parámetros de la cadena de
&
consulta.
Indica la separación entre el nombre y valor de
=
un parámetro.
Página 21
Capítulo 2 Marco Teórico
/
:
,
Separador entre tipo MIME y subtipo en formato
parámetro valor.
Separador entre nombres de espacio y el
identificador de los SRS.
Separa valores individuales en la lista de
parámetros (como BBOX, LAYERS y STYLES en
una solicitud GetMap).
2.2.2. HTTP GET [OGCWMS, 2002]
Para realizar una petición GET, debe indicarse la URL del servicio junto con los parámetros
adicionales que se deseen añadir. La estructura es: http ó https, seguido del nombre de la
máquina o una dirección numérica, opcionalmente se indica el número de puerto, y finalmente
la ruta y el signo de interrogación “?”, el cual es obligatorio. Los parámetros del servicio se
añaden después del signo de interrogación finalizando con un “&”. Cada operación está
formada por parámetros obligatorios y otros optativos que puede ejecutarse desde cualquier
navegador.
En la tabla (2.2) se describe cómo se debe estructurar la cadena de solicitud de mapas
utilizando el método GET.
Tabla 2.2. Estructura de petición HTTP GET
Fuente: tomado de [OGCWMS, 2002]
Componente URL
Descripción
http://host[:port]/path[?{name[=value]&}]
URL prefijo de operación del servicio. [] Denotan
0 ó 1 ocurrencias de una parte opcional; {}
denotan 0 o más ocurrencias.
name=value&
Uno o más parámetros de nombre/valor, tal
como se define para cada operación.
Un ejemplo de solicitud GET de un mapa es la siguiente [DIGECA, 2008]:
http://ovc.catastro.meh.es/Cartografia/WMS/ponenciasWMS.aspx?SERVICE=WMS&SRS=EPSG:23
030&REQUEST=GETMAP&bbox=426500,4448300,430500,4451300&width=400&height=300&forma
t=PNG&transparent=No
El resultado de la petición anterior se ilustra en la figura (2.5).
Página 22
Capítulo 2 Marco Teórico
Figura 2.5. Resultado de solicitud GET a un WMS
Fuente: Tomado de [DIGECA, 2008]
2.2.3. HTTP POST
Cuando se utiliza este método, el mensaje de solicitud es formulado en un documento XML.
Ejemplo [CSGRIP, 2008]:
Para realizar la petición HTTP POST se requiere enviar desde un formulario la URL del
servicio y el documento XML que describa los parámetros de la solicitud.
En la figura (2.6) se muestra el código del formulario que enviará la solicitud HTTP POST y
en la figura (2.7) se muestra la ejecución del formulario en el que se ingresa la URL del
servicio y el código XML que describe los parámetros de la solicitud.
Una vez enviada la petición al servidor, éste procesa la solicitud y regresa como resultado el
mapa que se muestra en la figura (2.8).
Página 23
Capítulo 2 Marco Teórico
Figura 2.6. Código HTML de formulario para manejo de petición POST
Fuente: tomado de [CSGRIP, 2008]
Figura 2.7. Envío de petición HTTP POST
Fuente: tomado de [CSGRIP, 2008]
Página 24
Capítulo 2 Marco Teórico
Figura 2.8. Resultado de la petición HTTP POST
2.2.4. Operaciones WMS [OGCWMS, 2002]
El estándar WMS define dos modos de operar: WMS básico y WMS de consulta.
El WMS básico debe soportar los elementos básicos de servicio (versión, peticiones y
respuestas HTTP, valores numéricos y booleanos, determinados formatos de salida, sistemas
de coordenadas, parámetros de consulta y de respuesta, y excepciones), la operación
GetCapabilities y la operación GetMap. Clasifica la información que posee en capas y ofrece
un número determinado de estilos, con los cuales se pueden visualizar dichas capas. Este
estándar internacional WMS únicamente soporta capas y estilos definidos, no incluye
mecanismos de simbolización por parte del usuario.
El WMS de consulta debe satisfacer todos los requerimientos de un WMS básico y también
soportar la operación GetFeatureInfo.
A continuación se describen las operaciones soportadas por los WMSs.
 GetCapabilities (Obligatoria)
GetCapabilities ofrece información humanamente legible acerca de las características
del servicio (metadatos), es decir, permite obtener metadatos acerca del WMS
implementado, de las funcionalidades soportadas por el servicio, e información
específica sobre las capas de información geográfica disponibles. La información es
devuelta al cliente codificada en un documento XML. Los parámetros para realizar la
petición GetCapabilities se muestran en la tabla (2.3).
Tabla 2.3. Parámetros para la solicitud GetCapabilities
Fuente: tomado de [OGCWMS, 2002]
Parámetro de solicitud
Obligatoriedad
Descripción
VERSION=versión
Opcional
Versión de la especificación OGC.
Tipo de servicio al que va dirigida la
SERVICE=WMS
Obligatorio
petición.
Página 25
Capítulo 2 Marco Teórico
REQUEST=GetCapabilities
Obligatorio
UPDATESEQUENCE=string
Opcional
Nombre de la operación.
Secuencia de números o cadena de
caracteres para el control de la
consistencia del caché. Este valor se
incrementa cuando se realizan cambios
en el “Capabilities”.
Ejemplo [CSGWMS2008]:
A continuación se muestra la solicitud de las características del servicio “IDEE-Base”.
El resultado de la petición se observa en la figura (2.9).
http://www.idee.es/wms/IDEE-Base/IDEEBase?VERSION=1.1.0&REQUEST=GetCapabilities&SERVICE=WMS
Figura 2.9. Resultado de la petición GetCapabilities
 GetMap (Obligatoria)
Esta operación proporciona como resultado un mapa el cual refleja una imagen de los
datos almacenados. La tabla (2.4) describe cada parámetro necesario para realizar una
petición GetMap.
Tabla 2.4. Parámetros para la solicitud GetMap
Fuente: tomado de [OGCWMS, 2002]
Parámetro de solicitud
Obligatoriedad
Descripción
VERSION
REQUEST=GetMap
LAYERS=lista de capas
Obligatorio
Obligatorio
Obligatorio
STYLES=lista de estilos
Obligatorio
SRS=namespace:identificador
Obligatorio
Versión de la especificación OGC.
Nombre de la petición.
Lista de una o más capas, separadas por comas.
Estilo de visualización por capa requerida,
separados por comas.
Sistema de Referencia Espacial.
Página 26
Capítulo 2 Marco Teórico
Esquinas de ámbito (inferior izquierda, superior
derecha) en unidades SRS.
WIDTH=ancho
Obligatorio
Ancho del mapa en pixeles.
HEIGHT=alto
Obligatorio
Alto del mapa en pixeles.
FORMAT=formato de salida
Obligatorio
Formato de salida del mapa.
Transparencia
del
fondo
del
mapa
TRANSPARENT=TRUE|FALSE
Opcional
(default=FALSE).
Valor del color de fondo RGB en Hexadecimal
BGCOLOR=color_value
Opcional
(default=0xFFFFFF).
Formato en el que el WMS informa de las
EXCEPTOPNS=exceptions_format
Opcional
excepciones (default=XML).
TIME=time
Opcional
Valor del tiempo en las capas deseadas.
ELEVATION=elevation
Opcional
Elevación de las capas deseadas.
Los siguientes parámetros son utilizados sólo por WMSs que soportan la especificación SLD
SLD=url del sld
Opcional
URL del documento SLD.
Estilo definido por el usuario codificado de
SLD_BODY=sld codificado
Opcional
manera que pueda enviarse por la URL.
URL del Web Feature Service para proporcionar
WFS=url del wfs
Opcional
características de simbolización mediante SLD.
BBOX=minx,miny,maxx,maxy
Obligatorio
Ejemplo [CSGWMS, 2008]:
A continuación se muestra un ejemplo de solicitud en la que se pide visualizar las
capas Relieve, Hidrografía y Transporte del servicio IDEE-Base.
http://www.idee.es/wms/IDEE-Base/IDEEBase?VERSION=1.1.0&REQUEST=GetMap&LAYERS=Relieve,Hidrografia,transporte&STYL
ES=default&SRS=EPSG:4230&BBox=3.4650655,40.4137,3.62939155,44.13107&WIDTH=1000&HEIGHT=1000&FORMAT=image/jpeg
El mapa resultante se ilustra en la figura (2.10).
Figura 2.10. Resultado de la petición GetMap
Página 27
Capítulo 2 Marco Teórico
 GetFeatureInfo (Opcional)
GetFeatureInfo es una operación que captura y proporciona información contenida en
un mapa, tal como el valor de un objeto en una posición determinada. Es sólo
soportada por aquellas capas que tienen el atributo queryable=1 que ha sido definido o
heredado.
Un cliente no puede emitir una solicitud GetFeatureInfo para capas que tienen el
atributo queryable=0.
En la tabla (2.5) se describe los parámetros para realizar una petición GetFeatureInfo.
Tabla 2.5. Parámetros para la solicitud GetFeatureInfo
Fuente: tomado de [OGCWMS, 2002]
Componentes
Obligatoriedad
Descripción
VERSION=versión
REQUEST=GetFeatureInfo
Obligatorio
Obligatorio
Parámetros del mapa
Obligatorio
QUERY_LAYERS=lista de capas
Obligatorio
INFO_FORMAT=formato de
salida
Opcional
FEATURE_COUNT=número
Opcional
X=pixel_column
Obligatorio
Y=pixel_row
Obligatorio
EXCEPTIONS=exception_format
Opcional
Versión de la especificación OGC.
Nombre de la petición.
Copia parcial de una petición de mapas que genera
el mapa del cual se quiere obtener información.
Lista de una o más capas, sobre las que se realiza la
consulta, separadas por comas.
Formato de respuesta de la información sobre el
objeto (MIME type).
Número de objetos sobre los que se devuelve
información (default=1).
Coordenada X del objeto en el Mapa, en pixeles
(medido desde la esquina superior izquierda=0).
Coordenada Y del objeto en el Mapa, en pixeles
(medido desde la esquina superior izquierda=0).
Formato en el que el WMS informa de las
excepciones (default=application/vnd.ogc.se.xml).
Ejemplo [CSGWMS2008]:
A continuación se muestra una solicitud HTTP GET que solicita las características de
un vértice de la capa redroi (Red de Orden Inferior) situado en el pixel x=250, y=300
del servicio Sistema de Referencia.
http://www.idee.es/wms/IDEE-Referencia/IDEEReferencia?SERVICES=WMS&VERSION=1.1.0&REQUEST=GetFeatureInfo&LAYERS=redro
i&STYLES=default&SRS=EPSG:4230&BBox=-5.4650655,38.4137,1.62939155,42.13107&WIDTH=400&HEIGHT=500&FORMAT=image/png&OPAQUE&QUER
Y_LAYERS=redroi&FEATURE_COUNT=1&X=250&Y=300
El resultado de la solicitud anterior se ilustra en la figura (2.11).
Página 28
Capítulo 2 Marco Teórico
Figura 2.11. Resultado de la petición GetFeatureInfo
2.2.5. Styled Layer Descriptor (SLD) [OGCSLD, 2002]
Es una especificación de la OGC (ver anexo D) que permite producir mapas con estilos
definidos por el usuario. Para poder utilizar esta especificación es necesario que el WMS
soporte los SLD.
Para conocer que un servidor de mapas soporta los SLD se requiere hacer una petición
GetCapabilities y en el archivo de respuesta verificar que la etiqueta
<UserDefinedSymbolization> contenga el atributo SupportSLD con valor de 1. Y en caso de
que se requiera crear capas y estilos definidos por el usuario, los atributos UserLayer y
UserStyle deben tener un valor de 1.
Para introducir un estilo personalizado se utilizan dos parámetros:
SLD: se guarda el nuevo estilo en formato XML y se le llama mediante una URL.
Ejemplo:
http://www.idee.es/BCN25OWS/ogcwebservice?REQUEST=GetMap&VERSION=1.1.0&SERVICE=WMS&SRS=EPSG:43
26&BBOX=-5.93125,37.33968,5.87504,37.3865&WIDTH=1000&HEIGHT=833&FORMAT=image/gif&SLD=http://www.idee.es/
SLD/prueba.xml
SLD_BODY: incluye el archivo que define el nuevo estilo. Para cargarlo es necesario
codificar el texto XML de forma que pueda enviarse vía URL.
http://www.idee.es/BCN25-OWS/ogcwebservice?REQUEST=GetMap&VERSION=1.1.0&
SERVICE=WMS&SRS=EPSG:4326&BBOX=-5.93125,37.33968,-5.87504,37.3865&WIDTH=
1000&HEIGHT=833&FORMAT=image/gif&SLD_BODY=%3CStyledLayerDescriptor+version
%3D%221%2E0%2E0%22%0D%0Axmlns%3D%22http%3A%2F%2Fwww%2Eopengis%2
Enet%2Fsld%22%0D%0Axmlns%3Axlink%3D%22http%3A%2F%2Fwww%2Ew3%2Eorg%
2F1999%2Fxlink%22+xmlns%3Axsi%3D%22http%3A%2F%2Fwww%2Ew3%2Eorg%2F
Página 29
Capítulo 2 Marco Teórico
2001%2FXMLSchema%2Dinstance%22%0D%0Axsi%3AschemaLocation%3D%22http%3A
%2F%2Fschemas%2Eopengis%2Enet%2Fsld%2F1%2E0%2E0%2FStyledLayerDescriptor
%2Exsd%22+xmlns%3Ase%3D%22http%3A%2F%2Fwww%2Eopengis%2Enet%2Fse%22
+xmlns%3Abcn%3D%22http%3A%2F%2Fwww%2Eign%2Ees%2Fbcn25%22%3E+%0D%
0A%3CNamedLayer%3E%0D%0A%3CName%3EViaComunicacionLinea%3C%2FName%3
E%0D%0A%3CUserStyle%3E%0D%0A%3CFeatureTypeStyle%3E%0D%0A%3Cse%3A
FeatureTypeName%3Ebcn%3AViaComunicacionLinea%3C%2Fse%3AFeatureTypeName
%3E%0D%0A%3CRule%3E%0D%0A%3CLineSymbolizer%3E%0D%0A%3CStroke%3E%0
D%0A%3CCssParameter+name%3D%22stroke%22%3E%23aaaaff%3C%2FCssParameter
%3E%0D%0A%3CCssParameter+name%3D%22stroke%2Dwidth%22%3E5%2E0%3C%2F
CssParameter%3E%0D%0A%3C%2FStroke%3E%0D%0A%3C%2FLineSymbolizer%3E%
0D%0A%3C%2FRule%3E%0D%0A%3C%2FFeatureTypeStyle%3E%0D%0A%3C%2F
UserStyle%3E%0D%0A%3C%2FNamedLayer%3E%0D%0A%3C%2F
StyledLayerDescriptor%3E
El resultado de las peticiones anteriores es el mismo, lo que difiere es la forma de
solicitar el mapa. En la figura (2.12) se muestra el resultado de las peticiones
anteriores.
Figura 2.12. Resultado de una petición al WMS utilizando el parámetro SLD y SLD_BODY
2.3.
Elementos de programación
2.3.1. J2EE
Aunque Java ofrece servicios muy potentes, el lenguaje Java por sí sólo no es capaz de
conocer los requerimientos de un sistema empresarial, ya que se requiere de una plataforma
capaz de proporcionar los siguientes servicios:
Habilidad de almacenar datos en distintas bases de datos comerciales.
Distribuir la aplicación en más de una computadora.
Soportar transacciones.
Soportar aplicaciones distribuidas multihilo.
Página 30
Capítulo 2 Marco Teórico
Por estas razones se define la especificación J2EE la cual permite diseñar y desarrollar
aplicaciones empresariales de manera rápida.
La especificación J2EE permite implementar aplicaciones empresariales usando Java y
tecnologías de Internet y define los siguientes componentes:
Los que se ejecutan en el cliente (clientes Web, applets y aplicaciones de escritorio).
Los que se ejecutan en el servidor (Java Servlets y JavaServlet Pages).
Componentes de negocio que se ejecutan en el servidor (Enterprise Java Beans).
Los componentes J2EE se escriben en lenguaje Java y se compilan de la misma manera que
cualquier programa. La diferencia entre componentes J2EE y clases Java estándar es que los
primeros son agrupados en una aplicación J2EE. Se verifica que estén bien formados y que
cumplan con la especificación J2EE y se despliegan en el servidor J2EE para ser controlados y
gestionados [ARMSTRONG, 2007].
Una aplicación J2EE no está atada a un producto o interfaz de programación de un fabricante
y puede constar de tres o cuatro niveles, como lo muestra la figura (2.13).
Figura 2.13. Aplicaciones multinivel
Fuente: tomado de [ARMSTRONG, 2007]
2.3.2. Patrón Modelo-Vista-Controlador [FERNANDEZ, 2004]
Modelo-Vista-Controlador (MVC) es un patrón de diseño aportado por el lenguaje SmallTalk
a la Ingeniería de Software con el objetivo de mejorar la reusabilidad. El paradigma MVC
consiste en dividir las aplicaciones en tres partes: controlador, modelo y vista.
El controlador es el encargado de redirigir o asignar una aplicación a cada petición; el
controlador debe poseer de algún modo un mapa de correspondencias entre peticiones y
respuestas.
El modelo es la lógica de una aplicación. Una vez que se realizan las operaciones de lógica de
negocio necesarias, se devuelve el flujo al controlador y éste devuelve los resultados a una
vista asignada.
La vista es el medio por el cual se muestran los resultados del modelo al usuario.
Página 31
Capítulo 2 Marco Teórico
El procesamiento del MVC se lleva a cabo entre los tres componentes. El controlador recibe
una orden y decide quién la lleva a cabo en el modelo. Una vez que el modelo termina sus
operaciones devuelve el flujo al controlador y éste envía el resultado a la capa de presentación
(vista).
En la figura (2.14) se ilustra la interacción entre el modelo, la vista y el controlador.
Figura 2.14. Interacción del patrón MVC
Fuente: tomado de [FERNANDEZ, 2004]
En la actualidad se pueden encontrar diferentes implementaciones del patrón MVC y una de
ellas es el Framework Open Source Struts de Java.
 Framework Open Source Struts [APACHE,2008]
Struts es un framework OpenSource basado en Java que simplifica el desarrollo de
aplicaciones Web e implementa el modelo MVC. Es compatible con la especificación
J2EE y básicamente está construido sobre las tecnologías de servlets y JSPs.
Utilizando Struts nunca se llega a una página de la capa de presentación directamente.
Esto es, en la URL nunca se llega a una página JSP o HTML a través de su nombre.
Funcionamiento de Struts
El flujo que sigue Struts inicia cuando el navegador genera una solicitud. Ésta es
atendida por el controlador (un servlet especializado). El mismo se encarga de
analizar la solicitud, seguir la configuración programada en su XML (strutsconfig.xml) y llamar al Action correspondiente pasándole los parámetros enviados. El
Action instanciará y/o utilizará los objetos de negocio (modelo) necesarios para
concretar la tarea. Según el resultado que retorne el Action, el controlador derivará la
generación de la interfaz (vista) a una o más JSPs, las cuales podrán consultar los
objetos del modelo para mostrar información de los mismos.
Página 32
Capítulo 2 Marco Teórico
A continuación la figura (2.15) ilustra el flujo que sigue Struts.
Figura 2.15. Funcionamiento de Struts
Fuente: tomado de [FERNANDEZ, 2004]
2.3.3. JAVASCRIPT [EGUILUZ, 2008]
JavaScript es un lenguaje de programación que se utiliza principalmente para crear páginas
Web dinámicas.
Una página Web dinámica es aquella que incorpora efectos como texto que aparece y
desaparece, animaciones, acciones que se activan al pulsar botones y ventanas con mensajes
de aviso al usuario.
Técnicamente, JavaScript es un lenguaje de programación interpretado, por lo que no es
necesario compilar los programas para ejecutarlos. En otras palabras, los programas escritos
con JavaScript se pueden probar directamente en cualquier navegador sin necesidad de
procesos intermedios.
A pesar de su nombre, JavaScript no guarda ninguna relación directa con el lenguaje de
programación Java. Legalmente, JavaScript es una marca registrada de la empresa Sun
Microsystems.
La integración de JavaScript y XHTML es muy flexible, ya que existen al menos tres formas
para incluir código JavaScript en las páginas web.
 Incluir JavaScript en el mismo documento XHTML.
<script type="text/javascript">
alert("Un mensaje de prueba");
</script>
 Definir JavaScript en un archivo externo.
<script type="text/javascript" src="/js/codigo.js"></script>
 Incluir JavaScript en los elementos XHTML
<p onclick="alert('Un mensaje de prueba')">Un párrafo de texto.</p>
Página 33
Capítulo 2 Marco Teórico
2.3.4. AJAX [CRANE, 2006]
Asynchronous JavaScript And XML (JavaScript y XML asíncronos), es un nombre
relativamente reciente acuñado por Jesse James Garrett.
Ajax es una técnica de desarrollo Web para crear aplicaciones interactivas. Éstas se ejecutan
en el cliente, es decir, en el navegador del usuario, y mantiene comunicación asíncrona en
segundo plano con el servidor. De esta forma, es posible realizar cambios sobre la misma
página sin necesidad de recargarla. Esto significa aumentar la interactividad, velocidad y
usabilidad en la misma. AJAX es una combinación de cuatro tecnologías ya existentes:
JavaScript. JavaScript es un lenguaje scripting de propósito general diseñado para ser
embebido dentro de aplicaciones. En un Web Browser, el intérprete de JavaScript
permite la interacción con muchas de las capacidades incorporadas en los navegadores.
Las aplicaciones de Ajax se escriben en JavaScript.
Cascading Style Sheets (CSS). Las hojas de estilo ofrecen una manera para definir los
estilos visuales reutilizables para los elementos de las páginas Web. Estos ofrecen un
camino poderoso y simple para definir y aplicar uniformemente estilos visuales. En
una aplicación Ajax, el estilo de una interfaz de usuario puede ser modificada a través
de CSS.
Document Object Model (DOM). El DOM presenta la estructura de páginas Web como
un conjunto de objetos programables que pueden ser manipulados con JavaScript. El
scripting de DOM permite a las aplicaciones Ajax modificar “al vuelo” las interfaces
del usuario con gran eficacia rediseñando partes de la página.
XMLHttpRequest. El objeto XMLHttpRequest permite intercambiar datos
asincrónicamente con el servidor Web. En algunos frameworks y en algunas
situaciones concretas, se usa un objeto iframe en lugar del XMLHttpRequest para
realizar dichos intercambios.
2.3.5. XML [GUTIERREZ, 2000]
XML es un estándar internacional desarrollado por un grupo de trabajo XML (conocido como
el Comité de Revisión Editorial de SGML) formado bajo el auspicio del World Wide Web
Consortium (W3C) en 1996. XML, lenguaje de marcas extensible (eXtensible Markup
Language por sus siglas en inglés) es un metalenguaje extensible de etiquetas desarrollado por
el World Wide Web Consortium (W3C). Es una simplificación y adaptación del SGML y
permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a su
vez un lenguaje definido por SGML). Por lo tanto XML no es realmente un lenguaje en
particular, sino una manera de definir lenguajes para diferentes necesidades. Algunos de estos
lenguajes que usan XML para su definición son XHTML, SVG, MathML.
Características básicas de XML
XML se ha pensado para trabajar en la web. Una posible consecuencia es que puede
utilizarse con protocolos y mecanismos que ya funcionan, como HTTP, MIME y los
URL. No necesita ningún requerimiento adicional.
Página 34
Capítulo 2 Marco Teórico
Cualquier documento XML es compatible también con SGML, incluso la mayoría de
las aplicaciones de SGML pueden convertirse en XML. Esta propiedad condiciona
algunos aspectos de XML y hace que incluya algunas restricciones.
A diferencia de otros lenguajes de marcado existentes, como los que utilizan la
mayoría de los editores de texto, el marcado de XML, es perfectamente legible para los
humanos. Esta característica implica que no se necesitan herramientas especiales para
leerlos y modificarlos, bastan editores de textos básicos.
El diseño de XML es formal y conciso. Muy al contrario de lo que ocurre con otras
especificaciones como la de SGML y HTML, la especificación de XML es
especialmente corta. Como base de la especificación de XML se ha utilizado una
gramática clara concisa y compacta.
La especificación junto con los estándares asociados (Unicode y ISO/IEC 10646 para
caracteres, internet RFC 1766 para las marcas de identificación de lenguaje, ISO 639
para los códigos de nombre de lenguaje, ISO 3166 para los códigos de nombre de
país), provee toda la información necesaria para entender XML versión 1.0.
XML es un estándar internacional, lo que asegura su amplia difusión.
XML es extensible, es aplicable a un sinfín de situaciones diferentes.
XML sigue la tendencia actual en el mundo de la programación y es orientado a
objetos.
Página 35
Capítulo 2 Marco Teórico
Página 36
CAPÍTULO 3
ANÁLISIS Y DISEÑO
En este capítulo se detalla el análisis y diseño realizado para desarrollar el sistema.
Para ello se presenta el documento de especificaciones y posteriormente los
diagramas de casos de uso, diagramas de actividad, diagramas de secuencia y
diagramas de clases.
Capítulo 3 Análisis y Diseño
3.1.
ANÁLISIS
La obtención de los requisitos es parte de la fase de análisis del proceso de desarrollo de
software. Esta fase se vale de todo un proceso de descubrimiento, refinamiento, modelado y
especificación. Los requisitos son la descripción de los servicios proporcionados por el
sistema. En esta sección, se expone el documento de especificación de requerimientos y los
modelos (diagramas de casos de uso y diagramas de actividad) que se desarrollaron durante el
análisis de requisitos con la finalidad de comprender mejor el sistema que se desarrolló.
3.1.1. Especificación de requerimientos
A continuación se describen los requerimientos que se establecieron para el desarrollo del
sistema.
3.1.1.1.
Ámbito
MapWeb Designer será una herramienta de software destinada a la generación de páginas
Web que contengan mapas de tipo vectorial dentro de un entorno que integre la estilización de
mapas geográficos con la publicación del mapa estilizado en la Web. Toda esta infraestructura
estará diseñada para su funcionamiento en la Web y constará de cinco módulos principales:
Control de usuarios.
Componentes para la estilización de los mapas.
Generación de código XML siguiendo el estándar SLD, el cual define la estilización de
los mapas.
Catálogo de plantillas Web.
Publicación de páginas Web.
3.1.1.2.
Perspectiva del producto
A partir del problema y los objetivos planteados para esta tesis, se requiere el desarrollo de
una herramienta generadora de prototipos de páginas Web, que contengan mapas geográficos
y que facilite su estilización siguiendo las especificaciones de estilo definidos por la OGC.
3.1.1.3.
Funciones del producto
La herramienta MapWeb Designer deberá realizar las siguientes funciones básicas:
1. Gestión de usuarios.
2. Proporcionar componentes para el diseño y manipulación de mapas.
3. Proporcionar un catálogo de plantillas Web para la publicación del mapa.
4. Interacción con el servidor WMS para la recuperación de mapas, los cuales serán
mostrados en el visor de mapas de MapWeb Designer.
5. Publicación de la aplicación Web.
3.1.1.4.
Descripción de las funciones
1. Debido a que MapWeb Designer será una herramienta disponible en la Web, es
necesario controlar el acceso de los usuarios que ingresen al sistema. Para realizar esto,
Página 38
Capítulo 3 Análisis y Diseño
los usuarios diseñadores de aplicaciones Web, tendrán la opción de registrarse al
sistema y autentificarse una vez que se encuentren registrados.
2. Los componentes para la manipulación y diseño de mapas serán:
a. Edición de líneas: el diseñador podrá personalizar líneas dentro del mapa,
asignándole propiedades como color de línea, tipo de línea y ancho de línea.
b. Edición de polígonos: el diseñador podrá personalizar los contornos de línea de
los polígonos presentes en el mapa. Las propiedades que podrá personalizar
son: el color del contorno de la línea, el ancho del contorno de la línea y el
color de relleno del polígono.
c. Edición de puntos: El diseñador podrá personalizar la apariencia de los puntos
que contenga el mapa, es decir, podrá modificar su tamaño, color y orientación.
d. Zoom in: será un componente que tanto el diseñador como el usuario final,
podrán utilizar para hacer acercamientos sobre el mapa y así visualizar
elementos pequeños.
e. Zoom out: este componente será el que permitirá realizar alejamientos para
tener una visión más general del mapa y podrá ser utilizado tanto por el
diseñador como por el usuario final.
f. Paneo: este componente facilitará al diseñador y al usuario final, el poder
desplazarse a lo largo y ancho del mapa que estén manipulando.
g. Generación de código XML: la herramienta generará un archivo XML que
contendrá la estilización del mapa definida por el diseñador. Este archivo
seguirá las especificaciones de estilo establecidas por la OGC.
Para aumentar la interactividad con la aplicación, se utilizará AJAX para facilitar ésta
tarea.
3. MapWeb Designer manejará una serie de plantillas de aplicaciones Web las cuales
permitirán tener en diversas orientaciones el mapa estilizado.
4. MapWeb Designer tendrá la opción de interactuar con un servidor WMS (Web Map
Service por sus siglas en inglés) para la recuperación de mapas.
5. Cuando el diseñador de la aplicación Web haya finalizado su tarea de diseño en
MapWeb Designer, podrá publicar el mapa con la finalidad de que sea visible en la
Web. Para realizar esta labor, el sistema tendrá que copiar los archivos
correspondientes en el contenedor Web.
3.1.1.5.
Usuarios de la herramienta
a) Diseñador: es el encargado de diseñar la apariencia de los mapas, la interfaz de la
aplicación Web y la publicación de la misma.
b) Usuario final: se refiere a todos los usuarios que ingresan a través de la Web a las
publicaciones realizadas por los diseñadores.
3.1.1.6.
Limitaciones de la herramienta
1. Sólo se utilizarán herramientas de software libre.
2. La visualización de los mapas será en dos dimensiones.
Página 39
Capítulo 3 Análisis y Diseño
3.
4.
5.
6.
7.
8.
Únicamente se estilizarán mapas en formato vectorial.
Se trabajarán con mapas de servicios municipales y/o servicios carreteros.
La herramienta estará pensada para trabajar en plataformas convencionales.
El manejador de la base de datos que se utilizará será PostgreSQL.
La herramienta estará programada en Java siguiendo la especificación J2EE.
El diseño de la apariencia de los mapas se verá reflejado en un archivo XML que siga
la especificación SLD independiente, es decir, los archivos vectoriales no serán
modificados, si no que se les asociará como capa o “mascara” la estilización contenida
en el archivo SLD.
3.1.2. Diagramas de casos de uso y diagramas de actividad
A continuación se muestran los diagramas de casos de uso y diagramas de actividad, los cuales
ilustran la funcionalidad general del sistema que se desarrolló.
En la figura (3.1) se muestra el diagrama de casos de uso general del sistema. Se consideraron
como funciones principales las que a continuación se mencionan:
1. Registrar usuarios.
2. Autentificación de usuario.
3. Diseñar Mapa.
4. Elegir plantilla de diseño.
5. Publicar aplicación Web.
6. Visualizar aplicación Web.
uc Principal
Herramienta para la Generación de Estilos Definidos por el
Usuario para su Asociación a Mapas Geográficos y Publicación
en Prototipos de Aplicaciones Web
CU-1 Registrar
Usuario
CU-2 Autentificar
Usuario
CU-3 Diseñar Mapa
Diseñador
CU-4 Elegir Plantilla
de Diseño
Usuario Final
CU-5 Publicar
Aplicación Web
CU-6 Visualizar
Aplicación Web
Figura 3.1. Diagrama general de casos de uso del sistema
Página 40
Capítulo 3 Análisis y Diseño
3.1.2.1.
Caso de uso: Registrar Usuario
La figura (3.2) muestra el caso de uso Registrar Usuario. Este caso de uso describe el proceso
para registrar usuarios al sistema. La descripción del caso se muestra en la tabla (3.1) y su
diagrama de actividad se ilustra en la figura (3.3).
uc CU-1 Registrar Usuario
CU-1 Registrar
Usuario
Diseñador
Figura 3.2. Diagrama del caso de uso Registrar Usuario
Tabla 3.1. Descripción de caso de uso Registrar Usuario
ID:
Nombre del caso
de uso:
Actores:
Descripción:
Precondiciones:
Postcondiciones:
Escenario de
éxito 1:
Escenario de
fracaso 1:
Escenario de
fracaso 2:
CU-1
El diagrama de actividades que incluye los escenarios de éxito y
fracaso se muestra en la figura (3.3).
Registrar Usuario
Diseñador, MapWeb Designer
Permite a los diseñadores registrarse en el sistema con el objetivo de obtener un nombre de usuario
(login) y contraseña (password) para acceder al sistema MapWeb Designer.
Los actores deberán de tener en su navegador la página principal de MapWeb Designer y dar clic en
el botón Registrarse.
Se insertarán los datos del diseñador en la base de datos PostgreSQL y cada usuario contará con un
login y password personal.
1. El diseñador introduce datos personales.
2. El diseñador introduce el login y password deseado.
3. El sistema realiza la conexión con la base de datos.
4. El sistema busca en la base de datos un login idéntico al introducido por el diseñador.
5. El login no está duplicado por lo que el sistema registra los datos del diseñador en la base de
datos.
6. Terminar proceso.
1. El diseñador introduce datos personales.
2. El diseñador introduce el login y password deseado.
3. El sistema realiza la conexión con la base de datos.
4. El sistema busca en la base de datos un login idéntico al introducido por el diseñador.
5. El sistema encuentra un usuario registrado con el login introducido por el diseñador y ocurre un
error.
6. Notificar el error al diseñador.
7. Terminar proceso.
1. El diseñador introduce datos personales.
2. El diseñador introduce el login y password deseado.
3. El sistema realiza la conexión con la base de datos.
4. No es posible establecer conexión con la base de datos.
5. Se notifica el error.
6. Terminar proceso.
Incluye:
Suposiciones:
Página 41
Capítulo 3 Análisis y Diseño
act DA-CU1 Registrar Usuario
Inicio
Introducir datos
personales
Diseñador
Introducir el login y
passw ord deseado
Notificar duplicación
de login
Notificar error
Si
MapWeb Designer
No
¿Base de
datos
disponible?
Realizar la conexión
con la base de datos
Si
Buscar login
duplicado
¿login duplicado?
No
Registrar datos en la
base de datos
Fin
Figura 3.3. Diagrama de actividad de caso de uso Registrar Usuario
3.1.2.2.
Caso de uso: Autentificar Usuario
La figura (3.4) muestra el caso de uso Autentificar Usuario. La descripción del caso de uso se
muestra en la tabla (3.2) y su respectivo diagrama de actividad en la figura (3.5).
uc CU-2 Autentificar Usuario
CU-2 Autentificar
Usuario
Diseñador
Figura 3.4. Diagrama del caso de uso Autentificar Usuario
Tabla 3.2. Descripción del caso de uso Autentificar Usuario
ID:
Nombre del caso
de uso:
Actores:
Descripción:
Precondiciones:
Postcondiciones:
Escenario de
éxito 1:
CU-2
El diagrama de actividades que incluye los escenarios de éxito y
fracaso se muestra en la figura (3.5).
Autentificar Usuario
Diseñador, MapWeb Designer
Permite que los diseñadores registrados ingresen al sistema MapWeb Designer una vez que hayan
introducido su login y password correctos.
Para ingresar al sistema el diseñador debe estar registrado en el sistema.
Se logrará entrar al sistema MapWeb Designer.
1. El diseñador introduce el login.
2. El diseñador introduce el password.
3. El sistema realiza la conexión con la base de datos.
4. El sistema verifica que el login y password sean correctos.
5. El login y el password son correctos por lo que el sistema permite el acceso.
6. Terminar proceso.
Página 42
Capítulo 3 Análisis y Diseño
Escenario de
fracaso 1:
Escenario de
fracaso 2:
Incluye:
Suposiciones:
1.
2.
3.
4.
5.
6.
1.
2.
7.
3.
4.
5.
El diseñador introduce el login.
El diseñador introduce el password.
El sistema realiza la conexión con la base de datos
El sistema verifica que el login y password sean correctos.
El login y el password no son correctos por lo que el sistema rechaza el acceso.
Terminar proceso.
El diseñador introduce el login.
El diseñador introduce el password.
El sistema realiza la conexión con la base de datos.
No es posible establecer conexión con la base de datos.
Notificar error.
Terminar proceso.
Se supone que el diseñador ya se ha registrado en el sistema.
act DA-CU2 Autentificar Usuario
Inicio
Diseñador
Introducir Login
Notificar error
Introducir
Passw ord
Rechazar ingreso al
sistema
MapWeb Designer
Realizar la conexión
con la base de datos
¿Base de
datos
disponible?
No
No
Si
Validar login y
passw ord
¿Login y
password
correctos?
Si
Ingresar al
sistema
Fin
Figura 3.5. Diagrama de actividad de caso de uso Autentificar Usuario
3.1.2.3.
Caso de uso: Diseñar Mapa
La figura (3.6) presenta el caso de uso Diseñar Mapa y los casos de uso involucrados. Las
descripciones de cada caso de uso se muestran en las tablas (3.3), (3.4), (3.5) y (3.6) y sus
respectivos diagramas de actividad se muestran en las figuras 3.7, 3.8, 3.9 y 3.10.
Página 43
Capítulo 3 Análisis y Diseño
uc CU-3 Diseñar Mapa
CU-3.1 Solicitar
Mapa
«include»
CU-3 Diseñar Mapa
CU-3.3 Generar
Código XML
Diseñador
«include»
«include»
CU-3.2 Aplicar
Estilos
Figura 3.6. Diagrama del caso de uso Diseñar Mapa
Tabla 3.3. Descripción de caso de uso Diseñar Mapa
ID:
Nombre del caso
de uso:
Actores:
Descripción:
Precondiciones:
Postcondiciones:
Escenario de
éxito 1:
Escenario de
fracaso 1:
Escenario de
fracaso 2:
Incluye
Suposiciones:
CU-3
El diagrama de actividades que incluye los escenarios de éxito y
fracaso se muestra en la figura (3.7).
Diseñar Mapa
Diseñador, MapWeb Designer
Permite a los diseñadores configurar opciones de estilo para estilizar un mapa.
MapWeb Designer debe realizar la petición GetCapabilities al WMS para construir el catálogo de
mapas y mostrarlo al diseñador para que elija el mapa que desea estilizar. El mapa a estilizar debe
mostrarse en el visor de mapas.
Se obtendrá un mapa estilizado.
1. El sistema realiza la petición GetCapabilities al WMS.
2. El sistema lee el archivo GetCapabilities que el WMS devuelve y a partir de la información
construye el catálogo de mapas.
3. El diseñador elige del catálogo el mapa que desea estilizar.
4. El sistema construye la cadena de solicitud y envía la petición al WMS.
5. El WMS responde con la imagen del mapa solicitado y el sistema lo muestra en el visor de
mapas.
6. El diseñador aplica estilos al mapa por medio de opciones de estilo que el sistema le presenta
al diseñador.
7. El sistema genera el código XML que corresponde a las configuraciones de estilo definidas por
el usuario.
8. Terminar proceso.
1. El sistema realiza la petición GetCapabilities al WMS.
2. El sistema lee el archivo GetCapabilities que el WMS devuelve y a partir de la información
construye el catálogo de mapas.
3. Ocurrió un error al momento de construir el catálogo. El catálogo no está disponible.
4. Notificar el error al diseñador.
5. Terminar proceso.
1. El sistema realiza la petición GetCapabilities al WMS.
2. El sistema lee el archivo GetCapabilities que el WMS devuelve y a partir de la información
construye el catálogo de mapas.
3. El diseñador elige del catálogo el mapa que desea estilizar.
4. El sistema construye la cadena de solicitud y envía la petición al WMS.
5. El WMS no responde y el sistema no muestra el mapa en el visor de mapas.
6. Notificar error al diseñador.
7. Terminar proceso.
CU-3.1 Solicitar Mapa, CU-3.2 Aplicar Estilos.
Las opciones de estilo son facilitadas al diseñador para que configure el estilo de los objetos
mostrados en el mapa. Los objetos abarcan puntos, líneas, polígonos y texto.
Página 44
Capítulo 3 Análisis y Diseño
act DA-CU3 Diseñar Mapa
Inicio
Realizar petición
GetCapabilities al WMS
MapWeb Designer
¿Catálogo
de mapas
disponible?
No
Leer archiv o GetCapabilities y
construir el catálogo de mapas
¿Mapa
Visualizado?
Si
No
Si
Generar Código
XML
Diseñador
Construir cadena de
solicitud y env iar la
petición al WMS
Elegir del catálogo el
mapa a estilizar
Estilizar Mapa
Notificar error
Fin
Figura 3.7. Diagrama de actividad de caso de uso Diseñar Mapa
3.1.2.4.
Caso de uso: Solicitad Mapa
En la tabla (3.4) se describe el caso de uso Solicitar Mapa y en la figura (3.8) se ilustra su
respectivo diagrama de actividad.
Tabla 3.4. Descripción de caso de uso Solicitar Mapa
ID:
Nombre del caso
de uso:
Actores:
Descripción:
Precondiciones:
Postcondiciones:
Escenario de
éxito 1:
Escenario de
fracaso 1:
CU-3.1
El diagrama de actividades que incluye los escenarios de éxito y
fracaso se muestra en la figura (3.8)
Solicitar Mapa
Diseñador, MapWeb Designer
Solicita un mapa proveniente de un servidor WMS.
El diseñador debe de indicar que mapa desea solicitar.
Se muestra el mapa solicitado en el visor de mapas de la aplicación MapWeb Designer.
1. El diseñador selecciona el mapa que desea visualizar.
2. El sistema construye la cadena de solicitud que contiene el nombre del mapa que seleccionó
el diseñador.
3. El sistema envía la cadena de solicitud al servidor WMS.
4. El WMS responde la solicitud devolviendo la imagen del mapa solicitado.
5. Se muestra el mapa en el visor de mapas de la aplicación y el diseñador lo visualiza.
6. Terminar proceso.
1. El diseñador selecciona el mapa que desea visualizar.
7. El sistema construye la cadena de solicitud que contiene el nombre del mapa que seleccionó
el diseñador.
2. El sistema envía la cadena de solicitud al servidor WMS.
3. Ocurre un error, el servidor WMS no está disponible.
4. El mapa no se visualiza en el visor de mapas.
5. Terminar proceso.
Página 45
Capítulo 3 Análisis y Diseño
act DA-CU3.1 Solicitar Mapa
Diseñador
Inicio
Seleccionar el mapa que
se desea v isualizar
Visualizar mapa
solicitado
Visualizar error
MapWeb Designer
Si
Construir la cadena
de solicitud
¿Mapa
Visualizado?
No
Notificar que el
recurso no está
disponible
Env iar petición
GetMap al WMS
Fin
Figura 3.8. Diagrama de actividad de caso de uso Solicitar Mapa
3.1.2.5.
Caso de uso: Aplicar Estilos
La tabla (3.5) describe el caso de uso Aplicar Estilos y la figura (3.9) muestra su
correspondiente diagrama de actividad.
Tabla 3.5. Descripción de caso de uso Aplicar Estilos
ID:
Nombre del caso
de uso:
Actores:
Descripción:
Precondiciones:
Postcondiciones:
Escenario de
éxito 1:
Escenario de
éxito 2:
CU-3.2
El diagrama de actividades que incluye los escenarios de éxito y
fracaso se muestra en la figura (3.9)
Aplicar estilos
Diseñador, MapWeb Designer
Permite configurar componentes para aplicarle estilos a los mapas visualizados.
El mapa debe ser mostrado en el visor de mapas.
Se obtendrá un mapa estilizado de acuerdo a las necesidades del diseñador.
1. El diseñador selecciona el tipo de geometría a estilizar (punto, línea, polígono o texto).
2. El diseñador configura las opciones de estilo que se le presentan.
3. El diseñador aplica el estilo configurado.
4. El sistema genera el documento SLD que describe el estilo configurado por el diseñador.
5. El sistema construye y envía una solicitud GetMap al WMS.
6. El WMS responde la solicitud con el mapa estilizado.
7. El diseñador visualiza el cambio de estilo del mapa.
8. Terminar proceso.
1. El diseñador selecciona el tipo de geometría a estilizar (punto, línea, polígono o texto).
2. La geometría tipo texto es seleccionada por el diseñador.
3. El diseñador hace clic sobre un objeto del mapa.
4. El sistema obtiene las coordenadas X,Y del mapa.
5. El sistema construye y envía una petición GetFeatureInfo al WMS.
Página 46
Capítulo 3 Análisis y Diseño
Escenario de
fracaso 1:
Escenario de
fracaso 2:
Escenario de
fracaso 3:
Incluye
Suposiciones:
6. El WMS responde la solicitud devolviendo los atributos.
7. El diseñador configura las opciones de estilo que se le presentan.
8. El diseñador aplica el estilo configurado.
9. El sistema genera el documento SLD que describe el estilo configurado por el diseñador.
10. El sistema construye y envía una solicitud GetMap al WMS.
11. El WMS responde la solicitud con el mapa estilizado.
12. El diseñador visualiza el cambio de estilo del mapa.
13. Terminar proceso.
1. El diseñador selecciona el tipo de geometría a estilizar (punto, línea, polígono o texto).
2. El diseñador configura las opciones de estilo que se le presentan.
3. El diseñador aplica el estilo configurado.
4. El sistema genera el documento SLD que describe el estilo configurado por el diseñador.
5. El sistema construye y envía una solicitud GetMap al WMS.
6. El WMS no responde, ocurre un error.
7. Se notifica el error al diseñador.
8. Terminar proceso.
1. El diseñador selecciona el tipo de geometría a estilizar (punto, línea, polígono o texto).
2. La geometría tipo texto es seleccionada por el diseñador.
3. El diseñador hace clic sobre un objeto del mapa.
4. El sistema obtiene las coordenadas X,Y del mapa.
5. El sistema construye y envía una petición GetFeatureInfo al WMS.
6. El WMS no responde o no encontró atributos sobre las coordenadas X,Y.
7. Se notifica el error al diseñador.
8. Terminar proceso.
1. El diseñador selecciona el tipo de geometría a estilizar (punto, línea, polígono o texto).
2. La geometría tipo texto es seleccionada por el diseñador.
3. El diseñador hace clic sobre un objeto del mapa.
4. El sistema obtiene las coordenadas X,Y del mapa.
5. El sistema construye y envía una petición GetFeatureInfo al WMS.
6. El WMS responde la solicitud devolviendo los atributos.
7. El diseñador configura las opciones de estilo que se le presentan.
8. El diseñador aplica el estilo configurado.
9. El sistema genera el documento SLD que describe el estilo configurado por el diseñador.
10. El sistema construye y envía una solicitud GetMap al WMS.
11. El WMS no responde la solicitud, ocurre un error.
12. Se notifica el error al diseñador.
13. Terminar proceso.
CU-3.3 Generar código XML.
Se supone que el usuario ha ingresado al sistema.
Se supone que cuando el sistema realiza una petición GetMap al WMS, envía como parámetro el
documento SLD que contiene las configuraciones de estilo realizadas por el diseñador.
Se supone que el WMS asocia el estilo definido en el documento SLD al mapa solicitado por el
diseñador.
Cuando el sistema realiza una petición GetFeatureInfo, el sistema ingresa las coordenadas X,Y
obtenidas del lugar donde el diseñador hizo clic sobre el mapa. Estas coordenadas son enviadas
como parámetro a la petición GetFeatureInfo con el objetivo de obtener los atributos asociados a
esas coordenadas.
Página 47
Capítulo 3 Análisis y Diseño
act DA-CU3.2 Aplicar Estilos
Diseñador
Inicio
Seleccionar tipo de
geometría a estilizar (punto,
línea, polígono o texto)
Configurar propiedades
de estilo
Hacer click sobre
un obj eto del mapa
Aplicar estilo
Visualización del mapa
estilizado
Obtener coordenadas X,Y del mapa
Generacion del
documento SLD
No
MapWeb Designer
Notificar Error
¿Geometría
tipo texto
seleccionada?
Si
Construir y env iar petición
GetFeatureInfo al WMS
Construcción y env ío de
petición GetMap al WMS
Si
¿WMS
responde
solicitud?
¿WMS
responde
solicitud?
No
No
Si
Fin
Figura 3.9. Diagrama de actividad de caso de uso Aplicar Estilos
3.1.2.6.
Caso de uso: Generar Código XML
En la tabla (3.6) se describe el caso de uso Generar Código XML y en la figura (3.10) se
muestra su correspondiente diagrama de actividad.
Tabla 3.6. Descripción de caso de uso Generar Código XML
ID:
Nombre del caso
de uso:
Actores:
Descripción:
Precondiciones:
Postcondiciones:
Escenario de éxito
1:
Escenario fracaso
1:
CU-3.3
El diagrama de actividades que incluye los escenarios de éxito y
fracaso se muestra en la figura (3.10)
Generar código XML
Diseñador, MapWeb Designer, WMS.
Genera el código XML (cumpliendo con la especificación SLD) cada vez que el diseñador aplica un
nuevo estilo al mapa.
El mapa a estilizar debe estar visualizado en el visor de mapas.
Se obtendrá un archivo XML que sigue el estándar SLD el cual contiene los estilos aplicados al mapa.
1. El diseñador configura opciones de estilo.
2. El sistema genera el documento SLD de acuerdo a las configuraciones de estilo realizadas por el
diseñador.
3. El sistema construye y envía la petición GetMap al WMS.
4. El WMS procesa la solicitud enviando como respuesta el mapa con el estilo asociado.
5. El diseñador visualiza el estilo configurado sobre el mapa.
6. Terminar proceso.
1. El diseñador configura opciones de estilo.
2. El sistema genera el documento SLD de acuerdo a las configuraciones de estilo realizadas por el
diseñador.
Página 48
Capítulo 3 Análisis y Diseño
3.
4.
5.
1.
2.
Escenario de
fracaso 2:
3.
4.
5.
6.
Ocurre un error al construir el documento SLD.
Se notifica el error al diseñador.
Terminar proceso.
El diseñador configura opciones de estilo.
El sistema genera el documento SLD de acuerdo a las configuraciones de estilo realizadas por el
diseñador.
El sistema construye y envía la petición GetMap al WMS.
Ocurre un error, el WMS no responde.
Se notifica el error al diseñador.
Terminar proceso.
Incluye:
Suposiciones:
act DA-CU3.3 Generar Código XML
WMS
MapWeb Designer
Diseñador
Inicio
Configurar opciones
de estilo
Construir SLD de acuerdo a
las configuraciones de estilo
realizadas por el diseñador
Mostrar SLD
asociado al mapa
Notificar Error
¿SLD
creado?
No
No
Construir y env iar la
petición GetMap al WMS
con el nombre del mapa y el
SLD generado como
parámetros
Si
¿Respuesta
del WMS
recibida?
Si
Procesar solicitud
GetMap
Fin
Figura 3.10. Diagrama de actividad de caso de uso Generar Código XML
3.1.2.7.
Caso de uso: Elegir Plantilla de Diseño
En la figura (3.11) se muestra el caso de uso Elegir Plantilla de Diseño, la descripción del
caso de uso en la tabla (3.7) y su respectivo diagrama de actividad se ilustran en la figura
(3.12).
uc CU-4 Elegir Plantilla de Diseño
CU-4 Elegir Plantilla
de Diseño
Diseñador
Figura 3.11. Diagrama del caso de uso Elegir Plantilla de Diseño
Página 49
Capítulo 3 Análisis y Diseño
Tabla 3.7. Descripción de caso de uso Elegir Plantilla de Diseño
ID:
Nombre del caso
de uso:
Actores:
Descripción:
Precondiciones:
Postcondiciones:
Escenario de
éxito 1:
Escenario de
fracaso 1:
Escenario de
fracaso 2:
Suposiciones:
El diagrama de actividades que incluye los escenarios de éxito y
fracaso se muestra en la figura (3.12)
CU-4
Elegir plantilla de diseño
Diseñador, MapWeb Designer
Provee un catálogo de aplicaciones Web para que el diseñador pueda elegir una de ellas y asociarla al
mapa estilizado anteriormente.
El diseñador debe haber sido autentificado anteriormente.
Se generará la aplicación Web seleccionada con el mapa estilizado.
1. El diseñador visualiza el catálogo de plantillas de aplicaciones Web.
2. El diseñador selecciona la plantilla que desea.
3. Se genera la plantilla seleccionada con el mapa asociado.
4. Terminar proceso.
1. El diseñador no visualiza el catálogo de plantillas de páginas Web.
2. Se notifica error.
3. Terminar proceso.
1. El diseñador visualiza el catálogo de plantillas de páginas Web.
2. El diseñador selecciona la plantilla que desea.
3. Se produce un error al generar la plantilla seleccionada.
4. Se notifica el error.
5. Terminar proceso.
Se supone que el diseñador ya terminó de estilizar el mapa para asociarlo a la plantilla seleccionada.
act DA-CU4 Elegir plantilla de Diseño
Inicio
Diseñador
¿Catálogo
de plantillas
visualizado?
No
Notificar Error
Si
Seleccionar Plantilla
MapWebDesigner
No
Generar plantilla con
mapa asociado
¿Plantilla
Generada?
Si
Fin
Figura 3.12. Diagrama de actividad de caso de uso Elegir Plantilla de Diseño.
Página 50
Capítulo 3 Análisis y Diseño
3.1.2.8.
Caso de uso: Publicar Aplicación Web
En la figura (3.13) se muestra el caso de uso Publicar Aplicación Web, la descripción del caso
de uso se muestra en la tabla (3.8) y su respectivo diagrama de actividad se ilustra en la figura
(3.14).
uc CU-5 Publicar Aplicación Web
CU-5 Publicar
Aplicación Web
Diseñador
Figura 3.13. Diagrama del caso de uso Publicar Aplicación Web.
Tabla 3.8. Descripción de caso de uso Publicar Aplicación Web
Descripción:
Precondiciones:
Postcondiciones:
Escenario de éxito
1:
Escenario de
fracaso 1:
Suposiciones:
Publicar aplicación Web
Diseñador, MapWeb Designer
Permite publicar la aplicación Web en el contenedor Web con la finalidad de que sea visible en la red
de Internet.
El diseñador debió haber elegido una plantilla de página Web.
Se copian los archivos correspondientes al contenedor Web.
1. El sistema copia los archivos necesarios a la carpeta Web del diseñador.
2. Los archivos se copian correctamente.
3. El sistema redirige a la dirección donde se publicaron los archivos.
4. Terminar proceso.
1. El sistema copia los archivos necesarios a la carpeta Web del diseñador.
2. Ocurre un error al copiar los archivos en el contenedor Web remoto.
3. Se notifica el error.
4. Terminar proceso.
Se supone que el diseñador ha terminado de estilizar el mapa.
act DA-CU5 Publicar Aplicación Web
Inicio
MapWeb Designer
Nombre del caso
de uso:
Actores:
El diagrama de actividades que incluye los escenarios de éxito y
fracaso se muestra en la figura (3.14)
CU-5
Copiar Archiv os a
Contenedor Web
¿Archivos
Copiados
Correctamente?
Si
Redirigir a página
publicada
No
Diseñador
ID:
Notificar Error
Fin
Figura 3.14. Diagrama de actividad del caso de uso Publicar Aplicación Web
Página 51
Capítulo 3 Análisis y Diseño
3.1.2.9.
Caso de uso: Visualizar Aplicación Web
En la figura (3.15) se muestra el caso de uso Visualizar Aplicación Web, la descripción del caso de uso
se muestra en la tabla (3.9) y el diagrama de actividad se presenta en la figura (3.16).
uc CU-6 Visualizar Aplicación Web
CU-6 Visualizar
Aplicación Web
Diseñador
Usuario Final
Figura 3.15. Diagrama del caso de uso Visualizar Aplicación Web
Tabla 3.9. Descripción de caso de uso Visualizar Aplicación Web
ID:
Nombre del caso
de uso:
Actores:
Descripción:
Precondiciones:
Postcondiciones:
Escenario de éxito
1:
Escenario de
fracaso 1:
Escenario de
fracaso 2:
CU-6
El diagrama de actividades que incluye los escenarios de éxito y
fracaso se muestra en la figura (3.16).
Visualizar aplicación Web
Diseñador, usuario final, navegador Web.
Visualiza la página Web publicada anteriormente en un navegador.
Los archivos de la aplicación Web deben de estar publicados en el contenedor Web.
Se visualizará la aplicación Web publicada.
1. Se abre el navegador.
2. Se introduce el path de la página Web publicada en el navegador.
3. Se despliega la página Web correctamente en el navegador.
4. Terminar proceso.
1. Se abre el navegador.
2. Se introduce el path de la página Web publicada en el navegador.
3. No se visualiza la aplicación Web.
4. Se notificar error.
5. Terminar proceso
1. Se tiene la aplicación publicada.
2. Se abre el navegador.
3. Se introduce el path de la página Web publicada en el navegador.
4. Se visualiza la página Web sin el mapa.
5. Se notifica error.
6. Terminar proceso.
Página 52
Capítulo 3 Análisis y Diseño
act DA-CU6 Visualizar Aplicación Web
Diseñador/Usuario
Inicio
Abrir Nav egador
WMS
MapWeb Designer
Contenedor Web
Procesar la solicitud http
Introducir el path de la
página Web publicada
en el nav egador
¿Aplicación
Disponible?
Si
Env iar petición GetMap
almacenada en la
aplicación publicada
Notificar Error
No
No
¿Respuesta
del WMS
recibida?
Si
Procesar solicitud
GetMap
Fin
Figura 3.16. Diagrama de actividad de caso de uso Visualizar Aplicación Web
3.2.
DISEÑO
En el proceso de ingeniería de software, una vez que se especifica y analizan los requisitos del
sistema se procede a realizar el diseño. En esta fase se toma en cuenta el análisis de requisitos
para poder describir de forma técnica el funcionamiento del sistema.
En la presente sección de diseño, se muestra el diseño arquitectónico que representa los
componentes con los que interactúa el sistema. Después se presentan los diagramas de clases
(para representar la estructura del sistema mostrando los atributos, métodos y relaciones) y
diagramas de secuencias (para mostrar las interacciones entre objetos). Finalmente para
describir la forma en que se organizan los datos que almacena el sistema, se expone el diseño
de la base de datos mediante el diagrama entidad relación.
3.2.1. Diseño arquitectónico
El proceso de diseño arquitectónico está relacionado con el establecimiento de un marco
estructural básico que identifica los principales componentes de un sistema y las
comunicaciones entre estos componentes. Hacer explícita la arquitectura del sistema en una
etapa temprana del desarrollo del sistema, requiere realizar algún análisis. [SOMMERVILLE,
2005]
De acuerdo a la descripción del problema de la tesis, se definió la arquitectura general del
sistema que muestra los componentes con los cuales interactúa. En la figura (3.17) se muestra
la arquitectura del sistema.
Página 53
Capítulo 3 Análisis y Diseño
Figura 3.17. Arquitectura general del sistema
3.2.1.1 Clientes
El cliente es la terminal de computadora desde la cual se solicita el servicio de la herramienta
MapWeb Designer por medio de peticiones HTTP. Por lo general quien solicitará el servicio
será un diseñador de aplicaciones Web. Los usuarios finales son quienes únicamente
visualizan la aplicación Web en Internet.
3.2.1.2 Contenedor Web
Debido a que la herramienta a desarrollar es visible en Internet, ésta debe estar almacenada en
un contenedor Web. Éste contenedor es el encargado de gestionar las solicitudes de los
diseñadores.
3.2.1.3 Herramienta MapWeb Designer
La herramienta generadora de páginas Web con mapas geográficos, contiene una API visora
para manipular los mapas, además proporciona componentes para la configuración de la
apariencia del mapa visualizado y una serie de plantillas de páginas Web en la que se publica
el mapa estilizado.
Los mapas visualizados y manipulados en la herramienta son solicitados a un WMS por medio
de las siguientes operaciones:
Petición GetCapabilities: MapWeb Designer realiza una petición GetCapabilities al
servidor de mapas (WMS) con la finalidad de obtener los servicios que provee. Para
ello se implementaron clases que permiten leer la respuesta del servidor WMS para
construir el catálogo de mapas que se le muestra al usuario (diseñador).
Petición GetMap: la herramienta contiene una API que permite visualizar los mapas
provenientes del WMS. Esta API en colaboración con MapWeb Designer realiza la
Página 54
Capítulo 3 Análisis y Diseño
petición GetMap al WMS para visualizar los mapas con los estilos aplicados por el
diseñador.
Petición GetFeatureInfo: la API visualizadora de mapas y el proxy que se implementó
en MapWeb Designer, permiten realizar la comunicación con el WMS para obtener
atributos asociados a los objetos punto, línea y polígono del mapa. Esto con el objetivo
de aplicar estilos a objetos específicos del mapa.
 El desarrollo de la aplicación MapWeb Designer sigue la especificación J2EE y la
implementación del patrón MVC de Java, por lo que se programó la aplicación en Java
utilizando Struts [APACHE, 2008]. Siguiendo el patrón MVC en la figura (3.18) se
muestra cómo se organiza la aplicación.
Figura 3.18. Aplicación MapWeb Designer
3.2.1.4 Api visora de mapas
Como su nombre lo indica, es un API que permite visualizar los mapas que se solicitan al
servidor de mapas. Se realizó una evaluación de las APIS más representativas con la finalidad
de elegir la más adecuada (ver anexo A).
Página 55
Capítulo 3 Análisis y Diseño
3.2.1.5 Servidor de mapas (WMS por sus siglas en inglés).
La función principal de este servidor es permitir consultar y recuperar mapas que tienen como
fuente de información datos vectoriales. Este servidor responde las peticiones http solicitadas
por la aplicación MapWeb Designer, devolviendo el mapa correspondiente a la solicitud.
Nota: el WMS es un servidor de consulta (que implementa las operaciones GetMap,
GetCapabilities y GetFeatureInfo). Para elegir el servidor adecuado se evaluaron los
servidores de mapas más representativos (ver anexo B).
3.2.1.6 Base de Datos (PostgreSQL).
En ella se encuentra almacenada información relacionada con los usuarios registrados en el
sistema. Esta información abarca datos personales de los usuarios, los mapas y estilos
generados por los mismos. En las figuras (3.31) y (3.32) del documento, se muestra el
diagrama conceptual y físico de la base de datos.
3.2.2. Diagramas de clases
Para diseñar el sistema MapWeb Designer se siguió el patrón Modelo-Vista-Controlador. Por
ello se crearon tres paquetes:
Paquete mx.edu.cenidet.MapWebDesigner.Modelo: este paquete guarda todas las
clases que implementan la lógica de negocio.
Paquete mx.edu.cenidet.MapWebDesigner.Vista: agrupa las clases que heredan de
ActionForm y que tienen como objetivo almacenar información proveniente de
formularios presentados al usuario.
Paquete mx.edu.cenidet.MapWebDesigner.Acciones: agrupa las clases que heredan
de la clase Action y que tienen como objetivo invocar a las clases del modelo y la vista
para controlar el flujo de la información.
Figura 3.19. Paquetes del sistema MapWeb Designer
Página 56
Capítulo 3 Análisis y Diseño
La relación existente entre los paquetes anteriores es de dependencia (ver figura 3.19). El
paquete mx.edu.cenidet.MapWebDesigner.Acciones requiere invocar objetos del paquete
mx.edu.cenidet.MapWebDesigner.Vista para obtener datos provenientes de la interfaz de usuario y
posteriormente invocar objetos del paquete mx.edu.cenidet.MapWebDesigner.Modelo para procesar
los datos de mx.edu.cenidet.MapWebDesigner.Vista y devolver un resultado.
A continuación se describen las clases y diagramas de secuencias que se definieron para el
desarrollo del sistema. La simbología utilizada en los diagramas de secuencia se presenta en la
tabla (3.10).
DSec-Registrar_Usuario
Clase
Tabla 3.10. Simbología utilizada en diagramas de secuencias
NOMBRE
SIMBOLO
Frontera
(Boundary)
sd DSec-Registrar_Usuario
Control
Boundary
Clase
Control
Actor
sd DSec-Registrar_...
Control
DESCRIPCION
Representa los elementos de software, tales como pantallas, informes, formularios,
reportes, páginas HTML, o sistema de interfaces que interactúan con los actores.
También se denomina elementos de la interfaz.
Representa un proceso de control. Coordina los eventos necesarios para llevar a cabo
el comportamiento que se especifica en el caso de uso.
Boundary
Representa al usuario del sistema.
sd DSec-Registrar_Usuario
Actor
Clase
Clase
Representa las clases del sistema.
Control
3.2.2.1.
Boundary
Clases del caso de uso Registrar Usuario
Este caso de uso permite que los actores se registren en el sistema y obtengan un Login y
Password registrado para ingresar a MapWeb Designer.
Las clases involucradas en este caso de uso se describen enseguida:
VISTA
RegistraUsuarioForm: clase que inicializa las variables del sistema con los datos
introducidos por el diseñador en la página JSP.
CONTROL
RegistraUsuarioAction: clase que invoca métodos de la clase RegistraUsuarioForm y
RegistraUsuarioModelo para controlar el flujo de la información.
MODELO
RegistraUsuarioModelo: permite registrar los usuarios en la base de datos del sistema.
Se encuentra en el paquete mx.edu.cenidet.MapWebDesigner.Modelo.Logica. Para realizar el
registro implementa los siguientes métodos:
o BuscarUsuarioDuplicado para verificar que no se registren usuarios con el mismo
login
o crear_idUser para crear un identificador único por usuario.
o encriptarPasswd para cifrar el password introducido por el usuario.
o RegistraUsuarioenBD para registrar el usuario en la base de datos del sistema.
Página 57
Capítulo 3 Análisis y Diseño
o CreaDirectorioWeb para crear el directorio Web en el que se guardan las
publicaciones del usuario.
Además crea una instancia de la clase ConectaBD para realizar la conexión con la base
de datos.
ConectaBD: clase que permite realizar la conexión con la base de datos. Pertenece al
paquete mx.edu.cenidet.MapWebDesigner.Modelo.BaseDatos y los métodos que implementa
son:
o RealizaConexion: invoca los métodos InicializarDatosConfiguracion y getConexion.
o InicializarDatosConfiguracion: crea una instancia de la clase ConfiguraBD para
obtener los datos necesarios de la conexión.
o getConexion: realizar la conexión con la base de datos.
ConfiguraBD: en esta clase permiten inicializar los datos para la conexión a la base de
datos. El método que implementa es:
o setArchivo: lee el archivo de configuración PropiedadesBD.properties para
obtener los datos de la conexión y los almacena en variables por medio de
métodos públicos.
En la figura (3.20) se presenta el diagrama de clases y en la figura (3.21) se muestra el
diagrama de secuencias del presente caso de uso.
class DC-RegistrarUsuario
org.apache.struts.action.ActionForm
Action
Vista::RegistraUsuarioForm
Acciones::RegistraUsuarioAction
-
AcuerdoLicencia: boolean = false
ApMat: String
ApPat: String
ConfirmaEmail: String
ConfirmaPasswd: String
Email: String
Login: String
Nombre: String
Organizacion: String
Pais: String
Passwd: String
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
getCkBacuerdoLicencia() : boolean
getTxFapMat() : String
getTxFapPat() : String
getTxFconfirmaEmail() : String
getTxFconfirmaPasswd() : String
getTxFemail() : String
getTxFlogin() : String
getTxFnombre() : String
getTxForganizacion() : String
getTxFpais() : String
getTxFpasswd() : String
RegistraUsuarioForm()
reset(ActionMapping, HttpServletRequest) : void
setCkBacuerdoLicencia(boolean) : void
setTxFapMat(String) : void
setTxFapPat(String) : void
setTxFconfirmaEmail(String) : void
setTxFconfirmaPasswd(String) : void
setTxFemail(String) : void
setTxFlogin(String) : void
setTxFnombre(String) : void
setTxForganizacion(String) : void
setTxFpais(String) : void
setTxFpasswd(String) : void
validate(ActionMapping, HttpServletRequest) : ActionErrors
-
Configuracion: Properties
+
execute(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward
Logica::RegistraUsuarioModelo
-
conexion: Connection
+
+
+
+
+
+
BuscaUsuarioDuplicado(String) : int
CreaDirectorioWeb(String, String) : boolean
crear_idUser() : int
encriptarPasswd(String) : String
RegistraUsuarioenBD(String, String, String, String, String, String, String, String, String) : int
RegistraUsuarioModelo()
BaseDatos::ConfiguraBD
BaseDatos::ConectaBD
-
baseDatos: String
conexion: Connection
password: String
puerto: String
servidor: String
url: String
usuario: String
+
+
+
+
ConectaBD()
getConexion() : Connection
InicializarDatosConfiguracion(String) : void
RealizaConexion(String) : Connection
-
appRuta: String
appServidor: String
archivo: String
bdNombre: String
bdPassword: String
bdPuerto: String
bdServidor: String
bdUsuario: String
Configuracion: Properties
messages: MessageResources = MessageResource...
+
+
ConfiguraBD()
setArchivo(String) : void
«property get»
+ getbdNombre() : String
+ getbdPassword() : String
+ getbdPuerto() : String
+ getbdServidor() : String
+ getbdUsuario() : String
Figura 3.20. Diagrama de clases de Registrar Usuario
Página 58
Capítulo 3 Análisis y Diseño
sd DSec-Registrar_Usuario
RegistraUsuarioForm
Diseñador
Interfaz Registro
Interfaz Error
Ingresar
datos
personales
Interfaz
Registro_Correcto
RegistraUsuarioAction
RegistraUsuarioModelo
ConectaBD
ConfiguraBD
Struts-config.xml
Registrar
Mapear acción
Direacciona
Se inicializan todas
las variables con la
información
ingresada por el
actor.
setTxFnombre(nombre)
Se obtiene la
información de las
variables
inicializadas.
Direcciona
Mapear acción
Direcciona
getTxFnombre()
Instanciar modelo
Conectar a
Base de
Datos
InicializarDatosConfiguracion(path)
Lee el archivo
PropiedadesBD.properties
para obtener los datos de
la conexión a la BD.
setArchivo(path)
Datos conexion :
bd,user,passwd
RealizaConexion(path)
getConexion() :Connection
BuscaUsuarioDuplicado(login) :int
Ejecutar Query
El valor entero que
regresa la función
BuscaUsuarioDuplicado
define lo siguiente:
1= Usuario duplicado
2= Usuario no duplicado
El valor entero devuelto por
RegistraUsuarioenBD significa
lo siguiente:
4= Usuario registrado
otro numero = ocurrió un error
2
crear_idUser() :int
encriptarPasswd :String
RegistraUsuarioenBD(String,String,String,String,String,String,String,String,String) :int
Ejecutar Query
4
CreaDirectorioWeb(login,path) :boolean
Comparar estado :true
Direcciona
Mapear acción
Mostrar resultado
Direcciona
Numero diferente de 4
Comparar estado :false
Direcciona
Mapear acción
Mostrar resultado
Direcciona
Figura 3.21. Diagrama de secuencias de Registrar Usuario
3.2.2.2.
Clases del caso de uso Autentificar Usuario
Este caso de uso permite que los usuarios registrados ingresen al sistema con un Login y
Password correctos (registrados en la base de datos).
Las clases involucradas en este caso de uso se ilustran en la figura (3.22) y se describen en
seguida:
VISTA
AutentificaUsuarioForm: esta clase se encarga de inicializar las variables Login y
Passwd con los datos introducidos en la interfaz de usuario.
CONTROL
AutentificaUsuarioAction: esta clase invoca métodos de AutentificaUsuarioForm y
AutentificaUsuarioModelo para controlar el flujo de la información.
Página 59
Capítulo 3 Análisis y Diseño
MODELO
AutentificaUsuarioModelo: esta clase permite verificar que el login y password
proporcionados por el usuario correspondan a un registro de la base de datos del
sistema.
Los métodos correspondientes a esta clase son:
o desencriptarPasswd: este método permite descifrar el password almacenado en la
base de datos.
o esValido: este método invoca a desencriptarPasswd y después se conecta a la base
de datos por medio de una instancia a la clase conectaBD ( ver caso de uso
Registrar Usuario para la descripción de esta clase) y buscar que el usuario y la
contraseña introducidos coincidan con los datos registrados en la Base de datos.
class DC-AutentificaUsuario
org.apache.struts.action.ActionForm
Action
Vista::AutentificaUsuarioForm
-
miLogin: String
miPasswd: String
+
+
+
+
+
+
+
AutentificaUsuarioForm()
getTxFpasswd() : String
getTxFusuario() : String
reset(ActionMapping, HttpServletRequest) : void
setTxFpasswd(String) : void
setTxFusuario(String) : void
validate(ActionMapping, HttpServletRequest) : ActionErrors
Acciones::AutentificaUsuarioAction
+
execute(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward
Logica::AutentificaUsuarioModelo
BaseDatos::ConfiguraBD
-
appRuta: String
appServidor: String
archivo: String
bdNombre: String
bdPassword: String
bdPuerto: String
bdServidor: String
bdUsuario: String
Configuracion: Properties
messages: MessageResources = MessageResource...
+
+
ConfiguraBD()
setArchivo(String) : void
«property get»
+ getbdNombre() : String
+ getbdPassword() : String
+ getbdPuerto() : String
+ getbdServidor() : String
+ getbdUsuario() : String
-
conexion: Connection
PasswdForma: String
UsuarioForma: String
+
+
+
AutentificaUsuarioModelo()
desencriptarPasswd(String) : String
esValido(String, String, String) : int
BaseDatos::ConectaBD
-
baseDatos: String
conexion: Connection
password: String
puerto: String
servidor: String
url: String
usuario: String
+
+
+
+
ConectaBD()
getConexion() : Connection
InicializarDatosConfiguracion(String) : void
RealizaConexion(String) : Connection
Figura 3.22. Diagrama de clases de Autentificar Usuario
El diagrama de secuencia que se sigue para que un usuario se autentifique se muestra en la
figura (3.23).
Página 60
Capítulo 3 Análisis y Diseño
sd DSec-Autentificar_Usuario
AutentificaUsuarioForm
Diseñador
Interfaz Login
Introducir
login y
password
Interfaz Error
Interfaz Elige
Opción
AutentificaUsuarioAction
AutentificaUsuarioModelo
ConectaBD
ConfiguraBD
Struts-config.xml
Iniciar Sesión
Mapear acción
Direcciona
setTxFusuario(login)
setTxFpasswd(password)
Direcciona
Mapear acción
Direcciona
getTxFusuario()
getTxFpasswd()
Instanciar modelo
desencriptarPasswd(password) :String
Conectar a Base
de Datos
InicializarDatosConfiguracion(path)
Lee el archivo
PropiedadesBD.properties
para obtener los datos de
la conexión a la BD.
setArchivo(path)
Datos conexion :
bd,user,passwd
RealizaConexion(path)
getConexion() :
Connection
esValido(login,password) :int
Ejecutar Query
Direcciona
UsuarioVálido :true
4
El valor entero que regresa la
función esValido define lo
siguiente:
4= login y password correctos
otro numero= ocurrió un error
Mapear acción
Mostrar resultado
Direcciona
numero diferente de 4
Direcciona
UsuarioVálido :false
Mapear acción
Mostrar resultado
Direcciona
Figura 3.23. Diagrama de secuencias de Autentificar Usuario
3.2.2.3.
Clases del caso de uso Diseñar Mapa
El objetivo de este caso de uso es configurar los componentes de estilo que permitan estilizar
un mapa previamente solicitado y generar el código SLD que represente la estilización
aplicada.
Los casos de uso que conforman el diseño del mapa son solicitar mapa, aplicar estilos, generar
código XML. A continuación se describen cada uno de estos.
3.2.2.3.1. Clases del caso de uso Solicitar Mapa
Para realizar la solicitud de mapas al WMS primero se realiza una petición GetCapabilities para
obtener el catálogo de mapas. Esta petición se ejecuta al momento de iniciar la aplicación. Una
vez que se realiza la solicitud, los mapas y sistemas de referencia obtenidos del WMS se
almacenan en el contexto de la aplicación. Para realizar lo anterior se definió el paquete
mx.edu.cenidet.MapWebDesigner.Modelo.ContextoCapas el cual se describe en el capítulo de
implementación.
Una vez que se tienen los mapas y sistemas de referencia que provee el WMS se procede a
realizar el proceso de solicitud del mapa que desee el usuario. Las clases que permiten realizar
esta función son las que a continuación se describen:
Página 61
Capítulo 3 Análisis y Diseño
VISTA
RealizaPeticionGeoserverForm: esta clase se encarga de inicializar las variables
CapasSeleccionadas y srs con los datos introducidos en la interfaz de usuario.
CONTROL
PeticionGeoserverAction: esta clase invoca métodos de RealizaPeticionGeoserverForm
para recuperar el sistema de referencia y las capas seleccionadas por el usuario.
En la figura (3.24) se presenta el diagrama de secuencias y en la figura (3.25) se muestra el
diagrama de clases correspondientes al presente caso de uso.
sd DSec-SolicitarMapa
RealizaPeticionGeoserverForm
Diseñador
Interfaz Catálogo
de Mapas
Interfaz Visualizar
Mapa
Seleccionar
mapa
API
PeticionGeoserverAction
Struts-config.xml
Solicitar mapa
Servidor WMS
Mapear acción
Direcciona
setSrs_seleccionado(string)
setCapasSeleccionadas(String[])
Direcciona
Mapear acción
Direcciona
getSrs_seleccionado()
getCapasSeleccionadas()
Subir variables SRS y
CapasSeleccionadas a
la sesión del usuario
Direcciona
Mapear acción
Direcciona
Recupera SRS y
CapasSeleccionadas de
la sesión del usuario
Construir Cadena Solicitud
Enviar Cadena
de Solicitud
Realizar Solicitud de Mapa
Procesa solicitud
Imagen del mapa
Procesar imagen
Mostrar mapa
Mostrar resultado
Figura 3.24. Diagrama de secuencias de Solicitar Mapa
class DC-SolicitarMapa
org.apache.struts.action.ActionForm
org.apache.struts.action.Action
Vista::RealizaPeticionGeoserv erForm
-
CapasSeleccionadas: String ([]) = null
srs_seleccionado: String
+
+
+
+
+
getSrs_seleccionado() : String
RealizaPeticionGeoserverForm()
reset(ActionMapping, HttpServletRequest) : void
setSrs_seleccionado(String) : void
validate(ActionMapping, HttpServletRequest) : ActionErrors
Acciones::PeticionGeoserv erAction
+
execute(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward
«property get»
+ getCapasSeleccionadas() : String[]
«property set»
+ setCapasSeleccionadas(String[]) : void
Figura 3.25. Diagrama de clases de Solicitar Mapa
Página 62
Capítulo 3 Análisis y Diseño
3.2.2.3.2. Clases del caso de uso Aplicar Estilos y Generar Código XML
El objetivo de estos casos de uso es configurar componentes de estilo que permitan estilizar un
mapa previamente solicitado y generar el código SLD que represente la estilización
configurada.
En el caso particular del texto, para realizar su personalización se requiere conocer los
atributos del mapa y para ello es necesario realizar una petición GetFeatureInfo al WMS para
obtener esta información. Esta función es realizada por la clase Proxy que se encuentra en el
paquete mx.edu.cenidet.MapWebDesigner.Modelo.Proxy (En el capítulo de implementación se
describe a detalle la función de la clase).
Las clases involucradas en estos casos de uso son:
VISTA
creaSLDForm: esta clase se encarga de inicializar las variables correspondientes a la
configuración de estilo realizada por el usuario.
CONTROL
creaSLDAction: esta clase invoca métodos de las clases creaSLDForm y creaSLDModelo
para controlar el flujo de la información.
MODELO
creaSLDModelo: clase que contiene métodos para la creación de objetos que
corresponden al documento SLD.
CreaTagsSLDModelo: permite la creación de tags XML.
Para la creación del documento SLD se realizó el diseño en objetos del cual a partir de éste se
generaron las clases que permiten crear los objetos del SLD. En el anexo C se muestran estos
diagramas.
A continuación en la figura (3.26) se muestra el diagrama de clases y en la figura (3.27) se
presenta el diagrama de secuencias correspondientes a los casos de uso aplicar estilos y
generar XML.
Página 63
Capítulo 3 Análisis y Diseño
Figura 3.26. Diagrama de clases de Aplicar Estilos y generar código XML
Página 64
Capítulo 3 Análisis y Diseño
sd DSec-AplicarEstilos
creaSLDForm
Diseñador
Interfaz Visualizar
Mapa
Configurar
componentes de
estilo
API
Aplicar estilo
creaSLDAction
CreaSLDModelo
CreaTagsSLDModelo
Struts-config.xml
Servidor WMS
Mapear acción
Direccionar
Se inicializan
todas las
variables con la
información
ingresada por el
actor.
setNombreCapa(String)
setTipogeometria(String)
Se obtiene la
información de
las variables
inicializadas.
Direcciona
Mapear acción
Direcciona
getNombreCapa()
getTipogeometria()
Instanciar modelo
Construir objetos SLD
Enviar objetos
Construir documento SLD
Documento SLD
Documento SLD
Subir el SLD a la sesión de usuario (SLD)
Direcciona
Mapear acción
Direcciona
Recuperar SLD,SRSy CapasSeleccionadas de
la sesión del usuario
Construir cadena solicitud
Enviar cadena
solicitud
Realizar solicitud de mapa con estilo creado
Procesa solicitud
Imagen del mapa con estilo
Mostrar mapa
Mostrar resultado
Figura 3.27. Diagrama de secuencias de Aplicar Estilos y generar código XML
3.2.2.4.
Clases del caso de uso Elegir Plantilla de Diseño y Publicar Aplicación Web
El objetivo de estos casos de uso es asociar el mapa estilizado a una plantilla de página Web
para publicarlo en la Web.
Las clases involucradas en estos casos de uso son:
VISTA
CatalogoPlantillasForm: esta clase implementa el método setPlantilla la cual se
encarga de inicializar la variable numPlantilla que se recibe de la interfaz de usuario.
Esta variable se encarga de identificar las plantillas disponibles con un número.
CONTROL
AsociarPlantillaAction: esta clase invoca métodos de CatalogoPlantillasForm y de
AsociaMapaPlantillaModelo.
MODELO
AsociaMapaPlantillaModelo: los principales métodos que implementa esta clase son:
Página 65
Capítulo 3 Análisis y Diseño
o AsociarMapaPlantilla: que permite asociar el mapa con la plantilla seleccionada
por el usuario.
o publicaPlantillaconMapa: este método invoca al método CreaDirectorioWeb, el cual
se encarga de crear un nuevo directorio dentro de la carpeta Web que fue
creada al momento de registrar el usuario en el sistema. Posteriormente copia el
prototipo de aplicación Web a la carpeta creada antes.
o GuardaSLDenBD: este método permite almacenar el documento SLD en la base
de datos con el objetivo de recuperarlo en sesiones posteriores.
El diagrama de clases definido para estos casos de uso se ilustra en la figura (3.28) y el
diagrama de secuencias se muestra en la figura (3.29).
class DC-ElegirPlantilladeDiseño-PublicarAplicaciónWeb
org.apache.struts.action.Action
Acciones::AsociarPlantillaAction
+
execute(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward
org.apache.struts.action.ActionForm
Logica::AsociaMapaPlantillaModelo
Vista::CatalogoPlantillasForm
-
template: String
+
+
+
+
CatalogoPlantillasForm()
getPlantilla() : String
setPlantilla(String) : void
validate(ActionMapping, HttpServletRequest) : ActionErrors
~
conexion: Connection
num: int = 0
+
+
+
+
+
+
+
+
+
+
AsociarMapaPlantilla(String, String[], String[], String[]) : String
copia(String, String) : void
copiarCSSaCarpetaUser(String, String) : boolean
CreaDirectorioWeb(String, String) : boolean
crear_id(String) : int
GuardaSLDenBD(String[], String, String, String, String, String, String) : boolean
obtieneIDusuario(String, String) : int
obtieneProyectosUser(int, String) : Collection
publicaPlantillaconMapa(String, String, String) : String
si_existeFile(String, String) : String
Figura 3.28. Diagrama de clases de Elegir Plantilla de Diseño y Publicar Aplicación Web
sd DSec-ElegirPlantilladeDiseño
CatalogoPlantillasForm
Diseñador
Interfaz Catálogo
Plantillas
Seleccionar
plantilla
Interfaz Pagina
Publicada
AsociarPlantillaAction
AsociaMapaPlantillaModelo
Struts-config.xml
Publicar plantilla
Mapear acción
Direcciona
setPlantilla(String)
Direcciona
Mapear accón
Direcciona
getPlantilla()
Instanciar modelo
AsociarMapaPlantilla(String,String[],String[],String[])
publicaPlantillaconMapa(String,String,String)
GuardaSLDenBD(String[] ,String,String,String,String,String,String)
path de publicación
Direcciona
Mapear acción
Direcciona
Mostrar resultado
Figura 3.29. Diagrama de secuencias Elegir Plantilla de Diseño y Publicar Aplicación Web
Página 66
Capítulo 3 Análisis y Diseño
3.2.2.5.
Secuencia del Caso de uso Visualizar Aplicación Web
El objetivo de esta clase es visualizar en el navegador Web la aplicación publicada. En este
caso no se requiere programar ninguna clase ya que el navegador Web procesa la solicitud.
En la figura (3.30) se muestra el diagrama de secuencias correspondiente al diagrama de casos
de uso Visualizar Aplicación Web.
sd DSec-VisualizarAplicacionWeb
Usuario/Diseñador
Navegador Web
Introducir URL
Procesar solicitud
respuestaServidor :200
Visualiza página Web publicada con mapa asociado
respuestaServidor :500
El servidor no encuentra el recurso solicitado
Figura 3.30. Diagrama de Secuencias de Visualizar Aplicación Web
3.2.3. Diseño de la Base de Datos.
Debido a que el sistema requiere controlar las publicaciones realizadas por cada usuario, se
realizó el diseño de la base de datos. Para efectuar esta tarea, se elaboró el diseño conceptual
representado por el modelo entidad relación. A partir del modelo conceptual se construyó el
modelo físico de la base de datos. En las figuras (3.31) y (3.32) se muestran los modelos
elaborados.
MAPA
USUARIO
idUser
<pi> Serial
<M>
nombre
Variable characters (254)
apPat
Variable characters (254)
apMat
Variable characters (254)
organizacion
Variable characters (254)
pais
Variable characters (254)
email
Variable characters (254)
nombrelogin
Variable characters (254)
passwd
Variable characters (254)
es estilizado
estiliza
tiene
idMapa
<pi> Serial
<M>
nombreMapa
Variable characters (254)
bbox
Variable characters (254)
srs
Integer
servidor
Variable characters (254)
idMapa <pi>
contiene
idUser <pi>
ESTILO
idEstilo
<pi> Serial
<M>
nombreEstilo
Variable characters (254)
sld
Text
pertenece
TIENE
idEstilo <pi>
Figura 3.31. Diagrama Conceptual de la base de datos
Página 67
Capítulo 3 Análisis y Diseño
MAPA
USUARIO
idUser
nombre
apPat
apMat
organizacion
pais
email
nombrelogin
passwd
SERIAL
<pk>
VARCHAR(254)
VARCHAR(254)
VARCHAR(254)
VARCHAR(254)
VARCHAR(254)
VARCHAR(254)
VARCHAR(254)
VARCHAR(254)
estiliza
FK_MAPA_TIENE_USUARIO
idMapa
es estilizado idUser
nombreMapa
bbox
srs
servidor
SERIAL
<pk>
INT4
<fk>
VARCHAR(254)
VARCHAR(254)
INT4
VARCHAR(254)
contiene
ESTILO
idEstilo
idMapa
nombreEstilo
sld
SERIAL
<pk>
INT4
<fk>
VARCHAR(254)
TEXT
pertenece
FK_ESTILO_TIENE_MAPA
Figura 3.32. Diagrama Físico de la base de datos
Página 68
CAPÍTULO 4
IMPLEMENTACION
En este capítulo se describen las clases implementadas que muestran la
funcionalidad del sistema.
Capítulo 4 Implementación
El desarrollo de la herramienta MapWeb Designer se desarrolló bajo las siguientes
características:
IDE Netbeans 6.0
Framework Struts 1.2.9
Manejador de base de datos PostgreSQL 8.3.
Contenedor Web Apache Tomcat 6.0
Java 2 Enterprise Edition Versión 1.5.
Navegador Web Mozilla Firefox 3.0.
Sistema operativo Windows XP.
La implementación de la herramienta implicó realizar en primera instancia una evaluación de
servidores de mapas y APIS visualizadoras de mapas. La evaluación de servidores de mapas
se hizo con el objetivo de elegir al servidor que proporcionara los mapas que manipularía la
aplicación. En esta evaluación se eligió a Geoserver como proveedor de mapas (ver anexo B
para consultar la evaluación de los servidores de mapas). La evaluación de las APIs se hizo
con el objetivo de elegir al visor de mapas más conveniente para el proyecto. De acuerdo a la
evaluación realizada (ver anexo A para consultar la evaluación de las APIs) se eligió como
visor de mapas a OpenLayers por ser un API con mejores funcionalidades.
Como se mostró en el capítulo de análisis y diseño, la aplicación se agrupa en tres paquetes.
En particular el paquete mx.edu.cenidet.MapWebDesigner.Modelo contiene a su vez cuatro paquetes:
BaseDatos, ContextoCapas, lógica, proxy y SLD. A continuación se describe cada uno de
estos.
4.1
Conexión con la base de datos
Para realizar la gestión de la base de datos se creó el paquete
mx.edu.cenidet.MapWebDesigner.Modelo.BseDatos (ver figura 4.1). La clase ConfiguraBD se encarga
de obtener los datos de configuración de la base de datos (la dirección del servidor de BD, el
puerto de conexión, nombre de usuario y password con el que se solicitará la conexión a la
base de datos). La clase ConectaBD instancia a ConfiguraBD para obtener los datos de conexión
y posteriormente realizar la conexión con PostgreSQL.
pkg mx.edu.cenidet.MapWebDesigner.Modelo.BaseDatos
ConfiguraBD
ConectaBD
-
baseDatos: String
conexion: Connection
password: String
puerto: String
servidor: String
url: String
usuario: String
+
+
+
+
ConectaBD()
getConexion() : Connection
InicializarDatosConfiguracion(String) : void
RealizaConexion(String) : Connection
-
appRuta: String
appServidor: String
archivo: String
bdNombre: String
bdPassword: String
bdPuerto: String
bdServidor: String
bdUsuario: String
Configuracion: Properties
messages: MessageResources = MessageResource...
+
+
ConfiguraBD()
setArchivo(String) : void
«property get»
+ getbdNombre() : String
+ getbdPassword() : String
+ getbdPuerto() : String
+ getbdServidor() : String
+ getbdUsuario() : String
Figura 4.1. Clases del paquete mx.edu.cenidet.MapWebDesigner.Modelo.BaseDatos
Página 70
Capítulo 4 Implementación
4.2
Construcción del catálogo de mapas
Para construir el catálogo de mapas se creó el paquete que se muestra en la figura (4.2). La
clase ContextListenerCapas realiza la petición GetCapabilities al servidor de mapas. El servidor de
mapas devuelve un documento XML que describe los servicios que ofrece. Para procesar el
documento XML la clase ContextListenerCapas instancia la clase LeeArchivoXMLGetCapabilities
la cual implementa la función leeXML que devuelve como resultado un collection que contiene
los mapas y sistemas de referencia que provee el servidor.
pkg mx.edu.cenidet.MapWebDesigner.Modelo.Con...
ServletContextListener
ContextListenerCapas
{leaf}
+
+
contextDestroyed(ServletContextEvent) : void
contextInitialized(ServletContextEvent) : void
Figura 4.2. Clase del paquete mx.edu.cenidet.MapWebDesigner.Modelo.ContextoCapas
4.3
Lógica de negocio
En el paquete mx.edu.cenidet.MapWebDesigner.Modelo.Logica se crearon las clases que permiten
realizar los aspectos lógicos de la aplicación. En la figura (4.3) se muestran las clases que
forman parte de este paquete.
pkg mx.edu.cenidet.MapWebDesigner.Modelo.Logica
Capa
LeeArchiv oXMLGetCapabilities
-CatalogoOrdenado
-
capa: String = null
maxx: String = null
maxy: String = null
minx: String = null
miny: String = null
pathPublicacion: String = null
SLD: String = null
srs: String = null
+
+
+
+
+
+
+
+
+
+
+
+
+
+
getCapa() : String
getMaxx() : String
getMaxy() : String
getMinx() : String
getMiny() : String
getPathPublicacion() : String
getSrs() : String
setCapa(String) : void
setMaxx(String) : void
setMaxy(String) : void
setMinx(String) : void
setMiny(String) : void
setPathPublicacion(String) : void
setSrs(String) : void
«property get»
+ getSLD() : String
«property set»
+ setSLD(String) : void
AsociaMapaPlantillaModelo
~
conexion: Connection
num: int = 0
+
+
+
+
+
+
+
+
+
+
AsociarMapaPlantilla(String, String[], String[], String[]) : String
copia(String, String) : void
copiarCSSaCarpetaUser(String, String) : boolean
CreaDirectorioWeb(String, String) : boolean
crear_id(String) : int
GuardaSLDenBD(String[], String, String, String, String, String, String) : boolean
obtieneIDusuario(String, String) : int
obtieneProyectosUser(int, String) : Collection
publicaPlantillaconMapa(String, String, String) : String
si_existeFile(String, String) : String
-
CatalogoOrdenado: Capa ([])
misCapas: Collection
NumCapas: int = 0
+
+
+
+
+
contabiliza_srs(Capa[]) : Collection
LeeArchivoXMLGetCapabilities()
leeXML(String) : Collection
muestra_resultados(int, String[][]) : void
ordena_capas(int, Capa[]) : Capa[]
RegistraUsuarioModelo
AutentificaUsuarioModelo
-
conexion: Connection
+
+
+
+
+
+
BuscaUsuarioDuplicado(String) : int
CreaDirectorioWeb(String, String) : boolean
crear_idUser() : int
encriptarPasswd(String) : String
RegistraUsuarioenBD(String, String, String, String, String, String, String, String, String) : int
RegistraUsuarioModelo()
-
conexion: Connection
PasswdForma: String
UsuarioForma: String
+
+
+
AutentificaUsuarioModelo()
desencriptarPasswd(String) : String
esValido(String, String, String) : int
CreaSLDModelo
CreaTagsSLDModelo
~
~
~
num: int = 1
root: Element
XML: String
+
+
+
+
+
+
+
+
+
+
creaDocumentoXML(Element) : String
creaElementoRootXML() : Element
creaElementosXML(String) : Element
creaElementosXML(String, String) : Element
creaElementosXML(String, String, String, String) : Element
creaElementoXML(String, String, String) : Element
creaElseFilterXML() : Element
creaFillElseFilterXML() : Element
creaStrokeElseFilterXML() : Element
si_existeFile(String) : String
~
~
DocSLD: String = ""
SLD: StyledLayerDescriptor = new StyledLayer...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
crearEncabezado_SLD(String, String, String, String) : void
crearFillTexto_SLD(TextSymbolizer, String, String) : TextSymbolizer
crearFont_SLD(TextSymbolizer, String, String, String, String) : TextSymbolizer
crearHaloTexto_SLD(TextSymbolizer, float, String, String) : TextSymbolizer
crearLineaCssParameter_SLD(String, String, String, String) : LineSymbolizer
crearObjetosDocumentoSLD(creaSLDForm) : void
crearPoligono_SLD(String, String, String, String, String) : PolygonSymbolizer
crearPuntoExternalGraphic_SLD(String, String, String, String) : PointSymbolizer
crearPuntoMark_SLD(String, String, String, String, String, String, String, String) : PointSymbolizer
crearTextoconLinePlacement_SLD(TextSymbolizer, String) : TextSymbolizer
crearTextoconPointPlacement_SLD(TextSymbolizer, float, float, float, float, float) : TextSymbolizer
CreaSLDModelo(String[])
CreaSLDModelo(String)
generaLINEAPredefinido() : LineSymbolizer
generaPOLIGONOPredefinido() : PolygonSymbolizer
generaPUNTOPredefinido() : PointSymbolizer
leerObjetosDocumentoSLD(String) : String
Figura 4.3. Clases del paquete mx.edu.cenidet.MapWebDesigner.Modelo.Logica
Página 71
Capítulo 4 Implementación
Se puede observar que las clases son independientes sin ninguna relación entre ellas. Esto
porque que realizan tareas distintas y por la forma en que se programó la aplicación (struts). A
continuación se describe cada clase.
Capa: clase utilizada como tipo de dato del Collection que almacena las capas devueltas
por el servidor de mapas.
LeeArchivoXMLGetCapabilities: contiene funciones que procesan el documento
GetCapabilities devuelto por el servidor de mapas. Utiliza la clase Capa como tipo de
dato de la colección que almacena las capas.
RegistraUsuarioModelo: implementa funciones que permiten registrar a los usuarios y
construir su correspondiente carpeta Web en la que se almacenarán sus publicaciones.
AutentificaUsuarioModelo: contiene funciones que permite verificar si el login y password
corresponden a un usuario almacenado en la base de datos.
AsociaMapaPlantillaModelo: contiene funciones que permiten asociar el mapa estilizado a
una plantilla de página Web y publicarla en la carpeta Web del usuario.
CreaSLDModelo:implementa funciones para la creación de objetos que corresponden a
los tags XML del documento SLD.
CreaTagsSLDModelo: contiene funciones sobrecargadas que permiten traducir los
objetos creados por CreaSLDModelo a tags XML.
4.4
Consulta de atributos del mapa
Para realizar la estilización del texto de objetos de un mapa, se requiere consultar los datos
asociados a ellos. Para ello se realiza una petición GetFeatureInfo al servidor de mapas con el
objetivo de abstraer esos datos. La abstracción de los datos se hace mediante un objeto AJAX
para mejorar la interacción de la aplicación.
Considerando que MapWeb Designer se ejecuta en el navegador y el servidor de mapas se
encuentra en un dominio externo ajeno al del contenedor Web que almacena la aplicación
MapWeb Designer. No es posible crear un objeto XMLHttpRequest que se comunique de
manera directa con el servidor de mapas (ver figura 4.4).
Figura 4.4. Petición AJAX con acceso denegado al Servidor WMS
Página 72
Capítulo 4 Implementación
Partiendo de lo anterior se implementó la clase miProxy que recibe los objetos XMLHttpRequest
con la finalidad de obtener comunicación con el WMS de manera transparente. Esta clase se
implementó en el paquete mx.edu.cenidet.MapWebDesigner.Modelo.Proxy (ver figura 4.5).
pkg mx.edu.cenidet.MapWebDesigner.Modelo.Proxy
HttpServlet
miProxy
~
~
~
~
atributos: List<String> = new ArrayList<S...
c: URLConnection = null
i: int = 0
url: URL = null
+
#
#
+
#
almacenaAtributos(String, boolean) : boolean
buscaTipoGeometria(String) : String
doGet(HttpServletRequest, HttpServletResponse) : void
doPost(HttpServletRequest, HttpServletResponse) : void
getServletInfo() : String
processRequest(HttpServletRequest, HttpServletResponse) : void
Figura 4.5. Clase del paquete mx.edu.cenidet.MapWebDesigner.Modelo.Proxy
Con la implementación de la clase anterior se resolvió la restricción de acceso al servidor de
mapas. En la figura (4.6) se muestra la forma en que interactúa el proxy con las peticiones.
Figura 4.6. Petición AJAX con acceso denegado al Servidor WMS
4.5
Construcción documento SLD
Para realizar la construcción del SLD se creó una clase por cada tag XML a crear, esto con la
finalidad de crear objetos fáciles de modificar y manipular.
En el anexo C se muestran los modelos correspondientes a esta funcionalidad y en el anexo D
se presenta una síntesis de la especificación SLD.
Página 73
Capítulo 4 Implementación
Página 74
CAPÍTULO 5
PRUEBAS
En este capítulo se presentan los resultados de las pruebas realizadas al sistema.
Capítulo 5 Pruebas
Una de las últimas fases del ciclo de vida del software antes de entregar un programa para su
explotación, es la fase de pruebas.
El proceso de pruebas es un esfuerzo por parte del proyecto para asegurar que el software no
tenga defectos. El plan de pruebas define el proceso, las estrategias y asigna los roles
primordiales en la ejecución de pruebas.
En el caso de MapWeb Designer las características que se probaron del sistema son las
siguientes:
Gestión de acceso al sistema: se probó que se realizara correctamente el registro de
usuarios del sistema así como el acceso y denegación al mismo.
Solicitud y visualización de mapas: se verificó que las solicitudes de mapas fueran
correctas y que se visualizaran los mapas solicitados en el visor de mapas de la
aplicación.
Aplicación de estilos al mapa: se probó que la configuración de estilos definidos por el
usuario y la generación del código XML correspondiente a la estilización del mapa se
realizaran correctamente.
Asociar mapa a plantilla de aplicación Web: se verificó que la plantilla Web elegida
del catálogo de plantillas fuera creada conteniendo el mapa estilizado
Publicación de la aplicación Web: se probó que los archivos necesarios para la
ejecución de la aplicación en la Web fueran copiados en el contenedor Web.
Visualización de la aplicación Web: se verificó la correcta ejecución y visualización de
la aplicación Web publicada.
Los casos de prueba que se presentan en este capítulo se encuentran descritos en el plan de
pruebas del anexo E.
Página 76
Capítulo 5 Pruebas
5.1
Resultados de las pruebas
A continuación se muestran los resultados obtenidos en cada caso de prueba efectuado al
sistema.
Tabla 5.1. Caso de prueba MAPWEBDE-01.01 Registro de usuarios
CASO DE PRUEBA: MAPWEBDE-01.01 Registro de usuarios.
RESULTADO:
Los datos ingresados a la página Registrarse.jsp se registraron satisfactoriamente en la base de datos
del sistema MapWeb Designer.
En la figura (5.1) se muestra la interfaz en la que se ingresan los datos del usuario.
Figura 5.1. Interfaz en la que se proporcionan los datos del usuario
En la figura (5.2) se muestra la tabla usuario de la base de datos del sistema.
Figura 5.2. Usuario registrado en la base de datos del sistema
En la figura (5.3) se ilustra la interfaz que se le proporciona al usuario cuando no ocurre ningún error al
registrarse.
Página 77
Capítulo 5 Pruebas
Figura 5.3. Interfaz mostrada al registrar adecuadamente al usuario
En la figura (5.4) se ilustra la interfaz que se le muestra al usuario cuando intenta registrarse con un
login que ya se encuentra registrado en la base de datos.
Figura 5.4. Interfaz mostrada al ingresar un login registrado
OBSERVACIONES:
Los datos ingresados por el usuario se registraron adecuadamente en la base de datos.
Antes de registrar al usuario se encripta la clave para que no sea fácil de visualizar en la base
de datos.
El sistema muestra correctamente las excepciones del sistema.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Página 78
Capítulo 5 Pruebas
Tabla 5.2. Caso de prueba MAPWEBDE-01.02 Autentificación al sistema
CASO DE PRUEBA: MAPWEBDE-01.02 Autentificación al sistema.
RESULTADO: El usuario registrado anteriormente pudo iniciar sesión sin problemas.
En la figura (5.5) se ilustra la interfaz que se le muestra al usuario una vez que inicia sesión.
Figura 5.5. Ingreso al sistema
OBSERVACIONES:
Al usuario se le muestran dos opciones: crear un nuevo proyecto y Abrir un proyecto existente.
La opción crear nuevo proyecto permite que el usuario ingrese al catálogo de mapas que
provee el WMS para realizar la solicitud de un mapa y posteriormente estilizarlo y publicarlo
en la Web. La opción Abrir un proyecto existente muestra los mapas publicados por el usuario.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Tabla 5.3. Caso de prueba MAPWEBDE-01.03 Rechazo al inicio de sesión
CASO DE PRUEBA: MAPWEBDE-01.03 Rechazo al inicio de sesión.
RESULTADO: Se rechazo a cualquier usuario que no se encontraba registrado en el sistema.
En la figura (5.6) se muestra la interfaz que se le presenta al usuario cuando se le niega el ingreso al
sistema.
La figura (5.7) muestra el mensaje de error que se le presenta al usuario cuando no se logra establecer
conexión con la base de datos.
Página 79
Capítulo 5 Pruebas
Figura 5.6. Interfaz de rechazo al ingreso del sistema
Figura 5.7. Interfaz de error de conexión con la base de datos
OBSERVACIONES:
En caso de que el manejador de base de datos no se encuentre en servicio el sistema notifica el
error.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Página 80
Capítulo 5 Pruebas
Tabla 5.4. Caso de prueba MAPWEBDE-01.04 Acceso al sistema
CASO DE PRUEBA: MAPWEBDE-01.04 Acceso al sistema
RESULTADO: El usuario registrado anteriormente pudo iniciar sesión sin problemas y visualizar el
catálogo de mapas que provee el servidor WMS Geoserver.
En la figura (5.8) se ilustra la interfaz que muestra los mapas disponibles en el servidor de mapas.
Figura 5.8. Catálogo de mapas
OBSERVACIONES:
El catálogo de mapas es mostrado de acuerdo al sistema de referencia seleccionado por el
usuario.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Página 81
Capítulo 5 Pruebas
Tabla 5.5. Caso de prueba MAPWEBDE-02 Solicitud y visualización de mapas
CASO DE PRUEBA: MAPWEBDE-02 Solicitud y visualización de mapas
RESULTADO: El usuario pudo visualizar los mapas seleccionados del servidor de mapas Geoserver.
En la figura (5.9) se muestra que el mapa de México es visualizado en el visor de mapas de la
aplicación. A la derecha del visor de mapas se pueden observar los componentes de estilo que permiten
modificar la apariencia del mapa visualizado de acuerdo a las necesidades de estilo del usuario.
Figura 5.9. Visualización del mapa solicitado
OBSERVACIONES:
El mapa se muestra con un estilo predefinido.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Tabla 5.6. Caso de prueba MAPWEBDE-03.01 Estilizar líneas
CASO DE PRUEBA: MAPWEBDE-03.01 Estilizar líneas
RESULTADO: El usuario pudo visualizar la configuración de estilos de línea aplicados al mapa
visualizado.
Para cumplir con esta prueba, se realizaron dos configuraciones de estilo: la primera contempla la
configuración de una línea sólida y la segunda de una línea punteada.
En la figura (5.10) se muestra el mapa antes de ser personalizado. Al lado derecho del mapa se observa
la configuración de estilo establecida por el usuario.
Como primera prueba se solicitó un estilo de línea sólida de color azul, con un nivel de transparencia
1.0 y grosor de 1 punto.
Página 82
Capítulo 5 Pruebas
Figura 5.10. Estado del mapa antes de ser estilizado
En la figura (5.11) se observa el resultado de la aplicación del estilo.
Figura 5.11. Mapa después de aplicarle la configuración de línea sólida
En la figura (5.12) se muestra la segunda prueba aplicada al sistema con un estilo punteado, de color
azul, con un nivel de transparencia de 1.0 y con un grosor de 2 puntos.
Página 83
Capítulo 5 Pruebas
En esta prueba se requirió aumentar la escala del mapa para poder apreciar el punteado de las líneas
Figura 5.12. Mapa después de aplicarle la configuración de línea punteada
OBSERVACIONES:
Para aplicar esta prueba se seleccionó el mapa de la vialidad de Cuernavaca.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Tabla 5.7. Caso de prueba MAPWEBDE-03.02 Estilizar polígonos
CASO DE PRUEBA: MAPWEBDE-03.02 Estilizar polígonos
RESULTADO: El usuario pudo visualizar la configuración de estilo aplicada a los polígonos del mapa
visualizado.
En la figura (5.13) se muestra el mapa antes de ser personalizado. Al lado derecho del mapa se observa
la configuración de estilo establecida por el usuario, el cual define de color morado el relleno de los
polígonos con un nivel de transparencia de 1.0; color rosa el contorno del polígono con un grosor de 2
puntos y un nivel de transparencia de 1.0.
La figura (5.14) muestra el mapa después de aplicar el estilo configurado por el usuario.
Página 84
Capítulo 5 Pruebas
Figura 5.13. Mapa de México antes de ser personalizado
Figura 5.14. Mapa de México con estilo personalizado
OBSERVACIONES:
Para aplicar esta prueba se seleccionó el mapa de México.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Página 85
Capítulo 5 Pruebas
Tabla 5.8. Caso de prueba MAPWEBDE-03.03 Estilizar puntos
CASO DE PRUEBA: MAPWEBDE-03.03 Estilizar puntos
RESULTADO: El usuario pudo visualizar la configuración personalizada de los puntos.
En la figura (5.15) se muestra el mapa antes de ser estilizado y a la derecha del mapa se observa la
configuración de estilo a aplicar. La figura (5.16) muestra la apariencia del mapa una vez que se
estableció la configuración mostrada en la figura (5.15).
Figura 5.15. Puntos del mapa de México antes de ser personalizado
Figura 5.16. Puntos con estilo personalizado
Página 86
Capítulo 5 Pruebas
En la figura (5.17) se muestra el resultado de la configuración de estilo de simbolizaciones puntuales
utilizando símbolos gráficos.
Figura 5.17. Puntos personalizados utilizando un gráfico
OBSERVACIONES:
Para cumplir con esta prueba se realizaron dos configuraciones de estilo: la primera contempló
una configuración utilizando “nombres bien conocidos” por la especificación SLD (ver
esquema XML de Mark en anexo D) y la segunda contempló la configuración de estilo puntual
utilizando símbolos gráficos (ver esquema XML de ExternalGraphic en anexo D ).
Para aplicar esta prueba se seleccionó el mapa de México.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Tabla 5.9. Caso de prueba MAPWEBDE-03.04 Estilizar texto
CASO DE PRUEBA: MAPWEBDE-03.04 Estilizar texto
RESULTADO: El usuario pudo visualizar las configuraciones personalizadas de las etiquetas del
mapa.
Para realizar esta prueba se realizaron tres tipos de configuraciones de estilo:
Configuración 1: se estableció la etiqueta NAME con el tipo de letra Arial Narrow en itálica y
negrita de tamaño 12 y color negro sin sombra utilizando una ubicación puntual de X=0
(AnchorPointX) y Y=0 (AnchorPointY) con un desplazamiento X=0 (DisplacementX) y Y=0
(DisplacementY) a un grado de rotación.
Configuración 2: se estableció la etiqueta NAME con el tipo de letra Baskerville Old Face en
estilo normal y negrita de tamaño 13 de color verde y sombra amarilla con 4 puntos de grosor
utilizando una ubicación puntual de X=0.5, Y=0.5 sin desplazamiento (X=0,Y=0) a veinte
grados de rotación.
Configuración 3: etiqueta NOMBRE con el tipo de letra Times New Roman en estilo normal y
negrita de tamaño 13 de color negro sin sombra y con una ubicación lineal de uno.
Página 87
Capítulo 5 Pruebas
En la figura (5.18) se observa el mapa de México antes de estilizar el texto y en la figura (5.19) se
presenta el mapa de México con la aplicación del estilo textual definido en la configuración 1.
Figura 5.18. Mapa de México antes de personalizar el texto
Figura 5.19. Mapa con personalización de texto utilizando la ubicación PointPlacement.
Página 88
Capítulo 5 Pruebas
En la figura (5.20) se observa el mapa de México antes de estilizar el texto y en la figura (5.21) se
presenta el mapa de México después de aplicar el estilo textual definido en la configuración 2.
Figura 5.20. Mapa de México antes de aplicar la configuración de texto
Figura 5.21. Mapa de México que muestra el estilo de texto con rotación
Página 89
Capítulo 5 Pruebas
En la figura (5.22) se observa el mapa de la vialidad de Cuernavaca antes de estilizar el texto y en
la figura (5.23) se presenta el mapa de la vialidad de Cuernavaca después de aplicar el estilo textual
definido en la configuración 3.
Figura 5.22. Mapa de la vialidad de Cuernavaca antes de aplicar estilo de texto
Figura 5.23. Mapa con personalización de texto utilizando la ubicación LinePlacement.
Página 90
Capítulo 5 Pruebas
En la figura (5.24) se muestra la vialidad de Cuernavaca a una escala mayor para apreciar mejor la
posición del texto
Figura 5.24. Mapa de Morelos que muestra la estilización del texto
OBSERVACIONES:
Para aplicar esta prueba se utilizó el mapa de México y el mapa de la vialidad de Cuernavaca.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Tabla 5.10. Caso de prueba MAPWEBDE-03.05 Generación de Código XML
CASO DE PRUEBA: MAPWEBDE-03.05 Generación de Código XML
RESULTADO: El documento XML se crea de manera satisfactoria.
Para realizar este caso de prueba se solicitó el mapa de México y se aplicaron configuraciones de estilo
de tipo punto, línea, polígono y texto.
En la figura (5.25) se muestra un fragmento del documento XML que sigue la especificación SLD y
que describe los estilos aplicados al mapa de México.
En la figura (5.26) se ilustra el mapa de México que tiene aplicados los estilos definidos en el
documento XML.
Página 91
Capítulo 5 Pruebas
Figura 5.25. Documento SLD
Figura 5.26. Mapa que muestra el estilo descrito en el documento SLD
OBSERVACIONES:
Para aplicar esta prueba se aplicó una configuración de estilo al mapa de México.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Página 92
Capítulo 5 Pruebas
Tabla 5.11. Caso de prueba MAPWEBDE-04 Asociar mapa a plantilla de página Web
CASO DE PRUEBA: MAPWEBDE-04 Asociar mapa a plantilla de página Web
RESULTADO: El sistema creó el código de la plantilla con el mapa asociado de forma satisfactoria.
En la figura (5.27) se muestra el valor de la variable tempText que almacena el código de la página que
contiene el mapa estilizado.
Figura 5.27. Variable tempText que contiene la plantilla de aplicación Web y el mapa solicitado
OBSERVACIONES:
En el debug realizado al sistema se pudo verificar que se creó el código de la plantilla con el
mapa asociado.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Tabla 5.12. Caso de prueba MAPWEBDE-05 Publicación de la página Web
CASO DE PRUEBA: MAPWEBDE-05 Publicación de la página Web
RESULTADO: en la carpeta Web del usuario se almacenaron los archivos necesarios para la
publicación del mapa.
En la figura (5.28) se observan los archivos almacenados en la carpeta Web del usuario.
Figura 5.28. Carpeta Web del usuario
OBSERVACIONES:
Cada publicación que realiza un usuario se almacena en la carpeta Web personal.
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Página 93
Capítulo 5 Pruebas
Tabla 5.13. Caso de prueba MAPWEBDE-06 Visualización de la página Web
CASO DE PRUEBA: MAPWEBDE-06 Visualización de la página Web
RESULTADO: El usuario pudo visualizar la aplicación Web publicada.
En la figura (5.29) se muestra el prototipo de aplicación Web que eligió el usuario para publicar el
mapa estilizado.
Figura 5.29. Plantilla de estilo publicado en la Web
OBSERVACIONES: sin observaciones
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
De los casos de prueba anteriores (pruebas de unidad) se puede observar el funcionamiento
correcto de cada uno de los módulos programados. A continuación se presenta la prueba de
integración (no contemplada en el plan de pruebas) con la finalidad de mostrar el
funcionamiento general del sistema, tomando en cuenta que el usuario ya se encuentra
registrado.
Página 94
Capítulo 5 Pruebas
Tabla 5.14. PRUEBA DE INTEGRACION-Funcionamiento general del sistema
PRUEBA DE INTEGRACION: Funcionamiento general del sistema
RESULTADO: El usuario pudo realizar cada una de las funciones del sistema obteniendo buenos
resultados.
En la figura (5.30) se muestra el inicio de sesión del usuario. Cuando el usuario inicia correctamente se
le muestran las opciones que se ilustran en la figura (5.31).
Figura 5.30. Interfaz para iniciar sesión
Figura 5.31. Interfaz de opciones a elegir en una sesión activa
Página 95
Capítulo 5 Pruebas
Si el usuario desea crear un nuevo proyecto se le proporciona el catálogo de mapas (ver figura 5.32).
En caso contrario si desea abrir un proyecto existente, se le proporciona la interfaz de la figura (5.41).
En la figura (5.32) se observa que el usuario eligió el mapa llamado Mexico:AliasMexico.
Figura 5.32. Interfaz del catálogo de mapas que provee el WMS
La figura (5.33) ilustra el mapa Mexico:AliasMexico sin ningún estilo definido por el usuario.
Figura 5.33. Mapa de México sin estilos definidos por el usuario
Página 96
Capítulo 5 Pruebas
En la figura (5.34) se observa el resultado de la configuración de estilo de tipo PUNTO realizada por el
usuario.
Figura 5.34. Estilización de puntos
En la figura (5.35) se muestra el resultado de la configuración tipo LINEA realizada por el usuario.
Figura 5.35. Estilización de líneas
En la figura (5.36) se presenta el resultado de la configuración de tipo POLIGONO realizada por el
usuario.
Página 97
Capítulo 5 Pruebas
Figura 5.36. Estilización de polígonos
En la figura (5.37) se muestra el resultado de la configuración tipo TEXTO realizada por el usuario.
Figura 5.37. Estilización de texto
Las configuraciones de estilo aplicadas al mapa de México se ven reflejadas en un documento XML
que sigue la especificación SLD. En la figura (5.38) se muestra una parte del documento.
Página 98
Capítulo 5 Pruebas
Figura 5.38. Documento XML que describe los estilos definidos por el usuario
Cuando el usuario termina de estilizar el mapa, el sistema le proporciona un catálogo de plantillas de
aplicaciones Web para que pueda publicarlo en la red. En la figura (5.39) se muestra las plantillas
disponibles en el sistema.
Figura 5.39. Elección de plantilla Web
Una vez que el usuario elige la plantilla procede a asociar el mapa y publicarlo en la Web. En la figura
(5.40) se muestra el mapa publicado.
Página 99
Capítulo 5 Pruebas
Figura 5.40. Publicación del mapa en plantilla de aplicación Web
En la figura (5.41) se presenta la interfaz que lista las publicaciones realizadas por el usuario.
Figura 5.41. Publicaciones realizadas por el usuario
OBSERVACIONES: sin observaciones
RESPONSABLE DE LA PRUEBA: Janet de Jesús García Alba
Página 100
Capítulo 5 Pruebas
5.2
Análisis de resultados
Las pruebas realizadas al sistema MapWeb Designer fueron de tipo funcional, es decir,
pruebas que buscan verificar que las funciones del sistema sean correctas.
En primera instancia se hicieron pruebas de unidad, las cuales permitieron verificar que cada
módulo del sistema funcionara de manera correcta. Posteriormente se realizaron pruebas de
integración para verificar que todos los módulos programados interactuaran y funcionaran sin
problemas.
Con respecto a los resultados obtenidos de las pruebas se menciona lo siguiente:
Para visualizar un mapa que contenga varias capas, se requiere que todas se encuentren
en extensiones territoriales cercanas, de lo contrario no se visualizarán de manera
inmediata en el visor de mapas (OpenLayers). Para lograr verlas, se requiere buscarlas
utilizando los componentes de interacción que proporciona OpenLayers. Partiendo de
ésto y pensando en que los usuarios del sistema no están familiarizados con términos
geográficos, se optó por solo permitir que el usuario seleccione una capa a la vez y así
evitar la confusión de que el sistema no muestra todos los mapas que se eligen.
Las configuraciones de estilo que proporciona el usuario permiten construir el
documento XML conforme a la especificación SLD. Es importante que el usuario
conozca que el orden en que sean realizadas las configuraciones de estilo, es el mismo
que se sigue para escribir el documento XML. Considerando que los estilos se dibujan
siguiendo la secuencia descrita en el documento XML, el usuario observará en algunas
ocasiones empalmes entre objetos.
Cuando el visor de mapas trata de procesar mapas que contienen mucha información,
éste se vuelve lento dependiendo mucho de las capacidades del equipo del cliente.
Página 101
Capítulo 5 Pruebas
Página 102
CAPÍTULO 6
CONCLUSIONES
En este capítulo se exponen las conclusiones a las que se llegaron al desarrollar el
presente proyecto de tesis. Se mencionan también las aportaciones y trabajos
futuros.
Capítulo 6 Conclusiones
Con la elaboración de la presente investigación se establecen las siguientes conclusiones:
Se demostró con el desarrollo de la aplicación MapWeb Designer que es posible
interactuar y diseñar la apariencia de mapas geográficos utilizando el estándar XML y
un API de código abierto que permite el acceso a servidores de mapas.
MapWeb Designer utiliza la especificación Styled Layer Descriptor (SLD) para
permitir obtener de manera rápida y automática un documento XML que describe los
estilos definidos por el usuario.
Al utilizar la especificación SLD, se garantiza que el documento de estilo generado por
MapWeb Designer, es legible por herramientas que cumplen con las especificaciones
WMS y SLD de la OGC.
MapWeb Designer utiliza un API visora de mapas (OpenLayers) y un servidor WMS
(Geoserver) de código abierto. Esto hace que la aplicación no dependa de software GIS
propietario que es costoso y complejo de utilizar.
El uso del API de OpenLayers (ver anexo A) permite que MapWeb Designer pueda en
un futuro utilizar mapas remotos provenientes de múltiples servidores de mapas como
Google maps, Yahoo maps y Mapserver. Esto gracias a que es un API independiente
del servidor de mapas.
Utilizar el servidor de mapas (WMS) Geoserver, permite subir de manera sencilla y
rápida mapas vectoriales. Esto gracias a que proporciona una interfaz amigable en
comparación con los demás servidores estudiados. Por lo que es recomendable
utilizarlo cuando el objetivo de la investigación no sea profundizar en la funcionalidad
de los servidores de mapas.
La ventaja de realizar una aplicación como MapWeb Designer es permitir el acceso y
manipulación de mapas de manera remota a múltiples usuarios situados en diversas
áreas del mundo. Los usuarios pueden ingresar al sistema y manipular los mapas a sus
conveniencias, haciendo transparente la construcción del documento SLD y las
peticiones al servidor WMS, ya que no es necesario que el usuario conozca los tags de
la especificación SLD y el funcionamiento de los servidores de mapas.
Por otro lado, durante el desarrollo del trabajo surgieron varios problemas, siendo el
principal el de la renderización de mapas del lado del cliente. En principio se había
planteado solicitar los mapas al WMS en formato GML, pero debido a que la API no
soportaba archivos grandes se optó por solicitar los mapas en formato imagen. Este
cambio se vio reflejado en los parámetros de la petición GetMap, ya que el documento
SLD ya no fue asociado con funciones de la API, sino que se mandó como parámetro
al servidor de mapas por medio de SLD_BODY.
Para visualizar un mapa que contenga varias capas, se requiere que soporten niveles de
transparencia para poder superponerlas. El problema de esto surge cuando estas capas
se encuentran en extensiones territoriales diferentes, y crea la idea de que del sistema
no carga todas las capas. Es por eso que se optó por permitir que los usuarios
Página 104
Capítulo 6 Conclusiones
seleccionaran un mapa a la vez con el objetivo de evitar la confusión de que el sistema
no muestra todos los mapas que se eligen.
Con respecto a las pruebas aplicadas al sistema, éstas fueron de tipo funcional y se
definieron en el plan de pruebas (ver anexo E). Los resultados que se obtuvieron fueron
los esperados, por lo que se cumplió el objetivo de la tesis y la hipótesis planteada en el
plan de pruebas.
Aportaciones
Las aportaciones del presente trabajo de tesis son:
Haber programado una aplicación Web estilizadora y publicadora de mapas
geográficos que hasta el momento no se encuentra en el mercado. Esta aplicación
genera de manera automática un archivo SLD que describe los estilos aplicados a un
mapa en particular. Está programada siguiendo el patrón MVC de Java (Struts) con la
finalidad de reducir costos de depuración y pruebas. Además fue desarrollada
utilizando exclusivamente software libre
Se contribuyó con la investigación de tecnologías geográficas las cuales son
importantes de conocer para todo aquél que desee trabajar con información espacial.
Se programó un proxy que permite acceder a los atributos de un mapa. Este proxy se
implementó en un servlet el cual aporta más ventajas que el CGI que sugiere
OpenLayers.
Trabajos futuros
El presente trabajo cumplió con el objetivo de estilizar y publicar mapas geográficos a través
de la Web. Sin embargo se le pueden incluir más servicios que convendría en un futuro se
pudieran implementar:
Implementar filtros avanzados mediante la incorporación de la especificación Filter
Encoding para poder definir reglas de estilo que afecten de manera individual a cada
característica del mapa. Con esto se obtendría un mapa estilizado con simbologías
complejas.
Creación de interfaces que permitan realizar consultas georeferenciables y no
georeferenciables sobre el mapa para poder encontrar puntos de interés cercanos a una
ubicación.
Creación de mecanismos para la búsqueda de rutas óptimas.
Generación de código que permita introducir los mapas estilizados en forma de Widget
a cualquier página personal.
Incorporación de componentes que permitan dibujar objetos sobre los mapas
visualizados.
Implementar la funcionalidad de almacenar los estilos definidos por el usuario al
servidor.
Página 105
Capítulo 6 Conclusiones
Implementar la parte de obtención de la leyenda de los mapas estilizados.
Página 106
ANEXOS
ANEXOS
Página 108
ANEXO A
Evaluación de APIs visoras de mapas
Anexo A. Evaluación de APIs visoras de mapas
1.
Introducción
El presente documento reporta la evaluación de APIs visoras de mapas las cuales permiten visualizar
mapas provenientes de servidores de mapas.
El objetivo de esta actividad fue elegir la API que se integrará en el sistema MapWeb Designer.
Para cumplir con el objetivo se instalaron las APIs y se realizaron pruebas de solicitud de mapas a
servidores.
2.
Características de APIs visoras de mapas de código libre.
2.1. msCross [DATACROSSING. 2007]
Es un cliente Web Ajax, desarrollado como interfaz JavaScript para UMN MapServer. Fue
desarrollado para permitir a los usuarios visualizar dinámicamente capas de información
geográfica en la Web. Sus características principales son:
Es de software libre, distribuido bajo la licencia GPL.
Funciona del lado del cliente.
Corre en múltiples plataformas.
No requiere instalación (es sólo un archivo JavaScript).
Se puede personalizar y extender.
Está basado en Ajax (JavaScript y XML Asíncronos).
Soporta a UMN Mapserver en modo CGI.
Soporta WFS para capas de puntos, es decir, devuelve información de los puntos.
Soporta WMS. Se puede realizar peticiones siguiendo el estándar WMS.
Provee una barra de herramientas de personalización.
Permite la depuración (debug).
Ha sido probado en Mozilla Firefox >= 1.0.5, Internet Explorer >=6.0 y Opera >=8.51.
A continuación se muestra un ejemplo de solicitud de un mapa, utilizando la API de msCross.
Para visualizar un mapa en msCross es necesario tener instalado MapServer o bien conocer la
ruta de los servidores MapServer externos para hacer la petición. Una vez cumpliendo este
requisito se siguen los siguientes pasos:
1. Crear un documento HTML o JSP e incluir la librería msCross (ver figura A.1).
Figura A.1. Referencia a la librería msCross
2. Crear un elemento DIV con un identificador. En este caso se identificó como
aqui_va_el_mapa. Posterior a esto se realiza la petición al servidor tal y como se
indica en la figura (A.2).
Página 110
Anexo A. Evaluación de APIs visoras de mapas
Figura A.2. Definición de elemento DIV y solicitud a servidor de la NASA
3. Correr la aplicación y visualizar el mapa (ver figura A.3)
Figura A.3. Visualización de mapas
2.2. OpenLayers [OPENLAYERS, 2008]
OpenLayers es una API codificada en JavaScript usada para poner fácilmente mapas
dinámicos en páginas y aplicaciones Web y se ejecuta en los navegadores modernos sin
dependencias del lado del servidor. Permite mostrar porciones de mapa y marcadores cargados
de cualquier fuente e implementa la tecnología AJAX para la interacción con los mapas.
Metacarta fue quien desarrolló la primera versión de OpenLayers y lo abrió al público. Es
totalmente gratuito pues fue liberado bajo la licencia BSD.
OpenLayers permite construir mashups con información geográfica similares a los mashups de
Google Maps y MSN Earth. Implementa métodos estándar como WMS, WFS, WFS-T para
acceder a datos geográficos y SLD para estilos.
Fue desarrollado con el fin de obtener una cartografía similar a la de Google Maps y Virtual
Earth API
Sus características principales son:
Es cliente ligero de cartografía.
Es interactivo (permite zoom in, zoom out, paneo, visualización de coordenadas,
habilitado y deshabilitado de capas)
Permite cargar mapas provenientes de diferentes servidores.
Página 111
Anexo A. Evaluación de APIs visoras de mapas
No requiere instalación.
Soporta WMS, WFS, WFS-T, SLD del la OGC.
En su versión más reciente (versión 2.6) incorpora características muy potentes que mejoran la
interacción con el usuario. Estas mejoras son: soporta reproyección del lado del cliente; soporta
la lectura y escritura de varias versiones de WMC; y el paneo de las capas comerciales lo hace
como Google Maps y Yahoo Maps; (The OpenLayers Team, 2008).
A continuación se ejemplifica la solicitud de un mapa por medio de OpenLayers.
La solicitud de mapas utilizando OpenLayers se realiza de la siguiente manera:
1. Crear un documento HTML o JSP e incluir la librería OpenLayers.js (ver figura A.4).
Figura A.4. Referencia a la librería OpenLayers
2. En una función crear un objeto tipo mapa con opciones de configuración (por ejemplo:
sistema de referencia y extensión territorial). Al objeto mapa se le asignarán las capas
que se deseen (ver figura A.5).
Figura A.5. Creación de objeto mapa
3. Dentro de la función definida en el paso 2, realizar la petición a los servidores que se
deseen ya que OpenLayers permite realizar solicitudes a varios servidores de mapas.
En este caso se hizo solicitud al servidor de mapas Geoserver (ver figura A.6). Nota:
dentro de la función también es posible definir los controles para la manipulación del
mapa.
Figura A.6. Solicitud al servidor Geoserver utilizando OpenLayers
4. Añadir la solicitud anterior al objeto mapa creado en el paso 2 (ver figura A.7).
Página 112
Anexo A. Evaluación de APIs visoras de mapas
Figura A.7. Adición de la capa México al objeto map
5. Una vez definida la función de inicialización. Se define un elemento DIV en el
documento HTML o JSP, según sea el caso, con un identificador. Esto se realiza para
indicarle a OpenLayers dónde mostrar el mapa (ver figura A.8).
Figura A.8. Elemento DIV con identificador map
6. En el evento onload de la etiqueta body llamar a la función init() implementada en el
paso 2.
Figura A.9. Llamada de la función init()
7. Ejecutar la aplicación en un servidor Web (ver figura A.10).
Figura A.10. Mapa de México visualizado utilizando OpenLayers
Página 113
Anexo A. Evaluación de APIs visoras de mapas
2.3. Ka-Map [MapTools, 2008]
Ka-Map es un proyecto de código libre que proporciona un API JavaScript para desarrollar
interfaces de mapas Web. Desarrollado en AJAX y PHP. Tiene escalas de zoom prefijadas, de
forma que se mantiene en un caché de imágenes sobre las capas ya combinadas, acelerando el
proceso de visualización sin que sea necesaria la intervención del servidor de mapas. Puede ser
distribuido en live CD o DVD.
Las principales características son:
Es interactivo, permite paneo continuo sin necesidad de recargar la página.
Proporciona navegación desde el teclado (zoom, paneo).
Provee escalas de zoom predefinidas.
Soporta la visualización de mapa clave, barra de escala y leyendas.
Permite controlar las capas desde el cliente, es decir, se pueden hacer visibles o
invisibles las capas deseadas.
Presume ser estable en cualquiera de los navegadores modernos.
Permite que cualquier persona contribuya a añadir nuevas funcionalidades y reportar
errores.
No es bueno para cantidades grandes de datos.
Ka-Map es un API creada para visualizar mapas de UMN MapServer. Este servidor se encarga
del tratamiento, programación y generación de mapas en el cual una serie de scripts PHP
proporcionados por Ka-Map gestionan las respuestas de MapServer. Ka-Map por su parte,
proporciona un API en JavaScript para realizar las peticiones de datos desde una variedad de
navegadores (ver tabla A.1).
Tabla A.1. Navegadores soportados por Ka-Map
Fuente: Paul Spencer, 2006
NAVEGADOR
Internet Explorer
Mozilla/Firefox
WINDOWS
LINUX
MAC OS X
Si(6)
-
-
Si(1.0+)
Si(1.0+)
Si(1.0+)
Netscape
Si(7+)
Si(7+)
Si(7+)
Epiphany
-
Si
-
Si(7+)
Si(7+)
Si(7+)
Konqueror
-
No
-
Safari
-
-
Si
Opera
A continuación se expone un ejemplo de visualización de mapas con Ka-Map.
Para visualizar un mapa de MapServer utilizando Ka-Map se requiere configurar lo siguiente:
1.
2.
3.
Instalar y configurar MapServer con Apache.
Descargar Ka-Map de http://ka-map.maptools.org/ (página oficial). En esta prueba se
descargó la versión 1.0.
Copiar todos los archivos, directorios y subdirectorios de htdocs situados en /ka-mapms4w-1.0/ms4w/apps/ka-map-1.0/ a la carpeta /ms4w/Apache/htdocs/Ka-Map.
Página 114
Anexo A. Evaluación de APIs visoras de mapas
4.
5.
6.
Descargar y descomprimir el paquete gmap-ms46 de http://dl.maptools.org/dl/ para
cargar mapas predefinidos por Ka-Map y copiar los archivos en
/ms4w/Apache/htdocs/Ka-Map/ gmap-ms46. En la carpeta gmap-ms46/htdocs se
encuentran varios archivos .map predefinidos para visualizarlos en Ka-Map.
En el archivo de configuración config.php asegurarse si la variable $aszGMap apunta
a la dirección correcta de instalación de gmap75.map.
Una vez realizadas las configuraciones anteriores se procede a realizar el archivo
HTML en el que se invocarán las librerías necesarias para la codificación de funciones
que se encargarán de visualizar un mapa. En la figura (A.11) se observa la
visualización de un mapa utilizando el API de Ka-Map.
Figura A.11. Visualización de mapas con Ka-Map
2.4.WMS JavaScript Library [WMSJALI, 2008]
WMS Java Script Library (wmsmap.js) es una librería JavaScript que facilita la creación de
mapas dinámicos utilizando servidores de mapas. Por ejemplo, para crear un mapa dinámico
equivalente a la petición HTTP GET http://www.idee.es/wms/IDEE-Base/IDEEBase?VERSION=1.1.0&REQUEST=GetMap&LAYERS=Relieve, se necesita incluir la
librería JavaScript; definir un objeto Layer; crear un nuevo objeto mapa y asociarlo con un
elemento DIV de un documento HTML.
Es una librería inspirada por Ka-Map y la API de Google Maps. Visualiza mapas provenientes
de servidores MapServer y Geoserver. Además utiliza Prototype.js el cual es utilizado para
crear aplicaciones web dinámicas.
Página 115
Anexo A. Evaluación de APIs visoras de mapas
La documentación que presenta en su sitio es nula pues únicamente muestra cinco ejemplos de
solicitudes de mapas y las funciones del API no están documentadas.
A continuación se muestra un ejemplo de solicitud y visualización del mapa de México a
MapServer.
Para publicar un mapa utilizando WMS JavaScript Library se requiere:
1. Construir un archivo HTML o JSP en el que se incluyan las librerías: prototype.js,
dragdrop.js, util.js, example_layers.js y wmsmap.js según se vayan requiriendo. En el
archivo example_layers.js se codifican las solicitudes a los servidores de mapas tal
como se muestra en la figura (A.12).
Figura A.12. Creación de petición a WMS.
2. En el documento HTML ó JSP, según sea el caso, definir un elemento DIV con un
identificador (en este caso map) para indicar que en ése lugar del documento será
mostrado el mapa (ver figura A.13).
Figura A.13. Definición de elemento DIV
3. Definir una función llamada init() en el que se definirá el objeto mapa para que éste
invoque la capa definida anteriormente (ver figura A.14).
Figura A.14. Definición de función init()
4. Finalmente invocar la función init() en el evento onload del elemento body (ver figura
A.15).
Figura A.15. Invocación de función init()
5. Para visualizar el mapa ejecutar la aplicación en un servidor Web si se trata de un
documento HTML, o en un contenedor Web en caso de documentos JSP. En nuestro
caso se desarrolló un documento JSP, por lo que se tuvo que ejecutar en Apache
Página 116
Anexo A. Evaluación de APIs visoras de mapas
Tomcat. En la figura (A.16) se observa el mapa de México visualizado sobre el API
WMS JavaScript Library.
Figura A.16. Mapa visualizado en WMS JavaScript Library
2.5.Mapbuilder
MapBuilder permite añadir mapas dinámicos e información de muchas otras fuentes para un
sitio Web. La filosofía de diseño de MapBuilder es minimizar los requisitos del servidor, pero
para una aplicación Web es necesario un servidor Web para servir las páginas como mínimo.
MapBuilder es una librería JavaScript que implementa el patrón de diseño Modelo-VistaControlador (MVC). Los objetos Modelo, Vista y Controlador que se utilizarán en la página
Web se configura en un archivo XML. [MAPBUILDER, 2007]
Las principales características son [HONCEVAR, 2007]:
● Cliente ligero de cartografía.
● Soporta estándares del Open Geospatial Consortium (OGC).
● Dibuja mapas provenientes de Web Map Services (WMS), Web Feature Services
(WFS), GeoRSS y Google Maps.
● Soporta funciones de edición de mapas mediante el uso de Web Features Services
(WFS-T).
● Permite a los usuarios construir sus propios mapas, guardarlos y compartirlos
utilizando Web Map Context (WMC, Solo soportado para mapas proporcionados por
un WMS) y Open Web Services Context (OWS Context es similar a WMC sólo que
puede almacenar más capas WMS. Las capas pueden provenir de WMS, WFS, GML,
GeoRSS y posiblemente fuentes externas).
● Es rápido e interactivo pues fue construido usando AJAX.
● Funciona con la mayoría de los navegadores modernos (Firefox 1.0+, Internet
Explorer 6.0+, Mozilla 1.3+, Navigator 6+)
● Personalizable y fácil de extender.
● De código abierto bajo la licencia LGPL.
Página 117
Anexo A. Evaluación de APIs visoras de mapas
●
No requiere plugins.
En su versión más reciente (versión 1.5) incorpora OpenLayers para la renderización de los
mapas. Esto debido a que en septiembre de 2006 durante el FOSS4G (Free and Open Source
Software for Geospatial) varios proyectos de WebMapping se reunieron y decidieron en una
sola biblioteca para renderizar mapas. Como consecuencia de ello MapBuilder sustituye su
biblioteca MapPane.js y MapPane2.js por MapPaneOL.js.
Para visualizar mapas utilizando la API Mapbuilder se siguen los siguientes pasos:
1. En un archivo HMTL o JSP se incluye la librería Mapbuilder.js (ver figura A.17).
Figura A.17. Referencia a la librería Mapbuilder.js
2. Posteriormente se crea un elemento DIV con identificador (en este caso se usó
mainMapPane ) y en el evento onload de la etiqueta body se manda llamar la función
mbDoLoad() la cual es una función de Mapbuilder que se encarga de abrir y leer el
archivo de configuración (en el paso 3 se describe el archivo de configuración) . Este
archivo se referencía asignando la URL a la variable mbConfigUrl (ver figura A.18).
Figura A.18. Configuraciones utilizadas en documentos HTML o JSP
3. El archivo de configuración es un archivo XML que utiliza etiquetas definidas en el
archivo config.xsd (Ver figura A.19) para describir los modelos que contendrá el mapa
a visualizar, es decir, describe que componentes (zoom in, zoom out, paneo, etc.) se
desean incorporar al mapa. En la figura (A.20) se muestra un trozo de código que
define las características del mapa a visualizar. El archivo demisWorldMap.xml (ver
figura A.21) contiene las peticiones a los servidores de mapas.
Página 118
Anexo A. Evaluación de APIs visoras de mapas
Figura A.19. Trozo de código XML del archivo config.xsd
Figura A.20. Archivo de configuración
Página 119
Anexo A. Evaluación de APIs visoras de mapas
Figura A.21. Trozo de código XML del archivo demisWorldMap.xml
4. Si se realizan correctamente los pasos anteriores se visualizará un mapa tal y como se
muestra en la figura (A.22).
Figura A.22. Mapa visualizado en Mapbuilder
3.
Definición de metodología de evaluación
Para realizar la evaluación de las APIs anteriormente mencionadas se llevaron a cabo los siguientes
pasos:
1. Definir criterios de evaluación, es decir, qué características debe cumplir la API para utilizarla
en el proyecto (ver tabla A.2).
Tabla A.2. Definición de criterios
CRITERIOS
Característica 1
Característica 2
Característica N
Página 120
Anexo A. Evaluación de APIs visoras de mapas
2. Asignar ponderaciones a cada criterio en un rango del 1 al 5 tomando como base la
importancia de cada una de éstas en el proyecto (ver tabla A.3).
.
Tabla A.3. Asignación de ponderaciones a cada criterio
CRITERIOS
PONDERACIÓN
5
Característica 1
3
Característica 2
1
Característica N
5: más importante, 1: menos importante
3. Evaluar cada API de acuerdo a los criterios que se definieron en el paso 1. La forma de evaluar
cada característica es asignar una calificación del 1 al 10 de acuerdo a que tanto cumple con los
requerimientos (ver tabla A.4) y si se desea se pueden incluir observaciones en cada asignación
de calificación.
Tabla A.4. Asignación de calificaciones a cada API de acuerdo a los criterios
CRITERIOS
Característica 1
Característica 2
Característica N
PESO
API-1
CALIFICACIÓN
API-2
CALIFICACIÓN
5
10
3
5
1
8
10: más importante, 1: menos importante
1
4
2
4. Obtener el producto de cada una de las características y ponderaciones asignadas a las mismas
para obtener un subtotal (ver tabla A.5).
Tabla A.5. Obtención de productos por criterio
CRITERIOS
PESO
API 1
API 2
50
Califiic.
1
Subtotal
5
Calific.
10
Subtotal
Característica 1
Característica 2
3
5
15
4
12
Característica N
1
8
8
2
2
5
5. Realizar la sumatoria por API de los subtotales obtenidos en el paso 4 (ver tabla A.6).
Tabla A.6. Obtención de sumatorias por API
CRITERIOS
PESO
API 1
API 2
50
Califiic.
1
Subtotal
5
Calific.
10
Subtotal
Característica 1
Característica 2
3
5
15
4
12
Característica N
1
8
8
2
2
TOTAL
-
73
5
19
6. Comparar los resultados del paso 5 y elegir la API que más puntaje tenga (ver figura A.23).
Página 121
Anexo A. Evaluación de APIs visoras de mapas
Figura A.23. Gráfico comparativo de la evaluación de las APIs
4.
Desarrollo de la metodología de evaluación
A continuación se desarrollan los pasos definidos en la metodología de evaluación con las APIs
mencionadas al principio del documento.
Paso 1. Definición de criterios de evaluación
Para elegir el visor mapas que se usará en el proyecto, se definieron los siguientes criterios para
realizar la evaluación de las APIs:
Código abierto: se requiere tener total libertad de uso del código fuente del visor de mapas por
si en un caso determinado se necesita adaptar una función del API para cumplir la finalidad del
proyecto.
Buena documentación: el API debe estar bien documentada y mostrar ejemplos que permitan
aprender su uso de manera rápida.
Codificado en JAVA: el API debe de estar implementado en este lenguaje debido a que el
proyecto de tesis se basa en la especificación J2EE.
Seguir las especificaciones de la OGC: el API debe estar implementada siguiendo las
especificaciones SLD, WMS y WFS para proporcionar un ambiente estandarizado.
Permitir recuperar mapas de diferentes fuentes: el producto final de la tesis únicamente
trabajará con los mapas provenientes de un servidor de mapas, pero para no dejar limitado el
proyecto, es necesario utilizar un API que visualice mapas de diferentes servidores de mapas.
Sencillo de usar: se requiere que sea fácil de utilizar para evitar invertir tiempo en instalar o
configurar el API en caso que así se requiera.
Paso 2. Asignación de ponderaciones
De acuerdo al nivel de importancia que tienen los criterios mencionados en el paso 1, se asignan los
siguientes pesos:
Página 122
Anexo A. Evaluación de APIs visoras de mapas
Tabla A.7. Asignación de ponderaciones a cada criterio
CRITERIOS
Código abierto
Buena documentación
Codificado en JAVA
Cumplir con especificaciones OGC
Permitir recuperar mapas de diferentes
fuentes
PONDERACIÓN
5
4
5
4
3
4
Sencillo de usar
Paso 3,4 y5. Asignación de calificaciones, producto de calificación-peso y sumatoria
En la tabla (A.8) se presenta la matriz de evaluación de las APIS. Las calificaciones mostradas se
asignaron de acuerdo a la experiencia obtenida al realizar solicitudes de mapas con las APIs
mencionadas al inicio del documento.
Paso 6. Comparar resultados
En la figura (A.24), se observa que la API OpenLayers es quien más puntaje presenta. Mapbuilder
puede ser también buena alternativa, pero por la ventaja de 20 puntos de OpenLayers no es posible
elegirla.
De acuerdo a los resultados obtenidos y tomando en cuenta que OpenLayers se ha convertido en un
API estándar para renderizar mapas, el API adecuada a utilizar en el proyecto es OpenLayers.
Gráfica de resultados
300
250
250
230
200
150
171
168
181
100
50
0
msCross
OpenLayers
Ka-Map
WMS
JavaScript
Library
Mapbuilder
Figura A.24. Resultados de la evaluación de APIs
Página 123
Anexo A
Tabla A.8. Matriz de evaluación
CRITERIOS
Código abierto
P
E
S
O
5
OpenLayers
msCross
Ka-Map
WMS JavaScript Library
MapBuilder
C
Obser
S
C
Obser
S
C
Obser
S
C
Obser
S
C
Obser
S
10
Permite bajar el
código del API en
su sitio Web
50
10
Permite bajar el
código del API
50
10
Permite bajar el
código del API
50
10
Permite bajar el
código del API
50
10
Permite bajar el
código del API
50
20
10
Provee variedad
de ejemplos y
cada función del
API está
documentada
40
9
Provee ejemplos y
las funciones del
API documentadas
36
2
Provee 5 ejemplos
y no documenta la
API
8
10
Proporciona
ejemplos útiles
para aprender
sobre las
funciones del API
40
Buena
documentación
4
5
Documenta sólo
algunas funciones
del API
Codificado en
Java
5
10
Está escrito en
JavaScript
50
10
Está escrito en
JavaScript
50
5
Está escrito en Java
y PHP
25
10
Está escrito en
JavaScript
50
10
Está escrito en
JavaScript
50
Cumplir con
especificaciones
OGC
4
5
No soporta la
especificación
SLD
20
10
Soporta WMS,
WFS y SLD
40
10
Soporta WMS, WFS
y SLD
40
5
Soporta WMS y
WFS
20
10
Soporta WMS,
WFS y SLD
40
0
Únicamente
soporta los mapas
que provee
MapServer
30
0
Únicamente soporta
los mapas que
provee MapServer
0
7
Recupera mapas
de Geoserver y
MapServer
21
10
Recupera mapas
de Geoserver y
MapServer
30
7
Proporciona pocos
ejemplos por lo
que no es posible
saber la utilidad
de todas las
funciones que
proporciona
5
Requiere la
configuración de
Apache y Mapserver
8
Los ejemplos que
proporciona no
son suficientes
para conocer todas
las funciones del
API
5
Requiere el
conocimiento de
etiquetas XML
para realizar las
solicitudes de
mapas
20
Permitir
recuperar
mapas de
diferentes
fuentes
3
Sencillo de usar
4
TOTAL
-
168
0
28
10
10
Recupera mapas
de Geoserver,
MapServer, Yahoo
Maps, Google
Maps, entre otros
Con los ejemplos
que proporciona
es suficiente para
guiar a los
usuarios a crear
sus primeras
aplicaciones
250
40
171
20
181
32
230
C: calificación
S: subtotal
Obser: observaciones
Página 124
ANEXO B
Evaluación de Servidores de Mapas
Anexo B. Evaluación de servidores de mapas
1. Introducción
El presente documento reporta la evaluación de los servidores de mapas disponibles de manera
gratuita. Para realizar la evaluación se instalaron cada uno de los servidores y se valoró en base a cinco
criterios con un peso determinado a cada uno.
Los servidores que se analizaron fueron: Degree; Geoserver y MapServer. A continuación se describe
cada servidor de mapas.
2. Características de servidores de mapas de código libre.
2.1. Degree [LATLON, 2008]
Este servidor de mapas nació como un proyecto del departamento de geografía de la
Universidad de Bonn, fundándose posteriormente la empresa lat/lon GmbH, que además de
continuar con la evolución del proyecto, presta servicios comerciales alrededor de esta
plataforma. [DEGREE, 2008]
Degree es un servidor Framework de Java que se puede desplegar sobre cualquier servidor que
cumpla la especificación J2EE. Destaca por su elevado número de especificaciones OGC e ISO
Technical Committee 211 – Geographic Information/Geoinformation (ISO/TC 211) que afirma
cumplir.
Los formatos vectoriales, ráster y conexiones a bases de datos que soporta son:
PostgreSQL/PostGIS, Oracle, bases de datos que permiten conexiones JDBC, ESRI Shapefiles,
GML2, JPEG, GIF, PNG, TIFF, GeoTiff.
Alrededor de este servidor se han ido desarrollando otros proyectos complementarios como
Degree iGeoPortal, Degree iGeoSecurity, Degree iGeo3D, deeJUMP. [DEGREE, 2008]
A continuación se muestra un ejemplo de publicación de un mapa en Degree.
Degree se instala con conjuntos de datos muestra, todos esos datos se extraen automáticamente
cuando se desempaqueta el demo de Degree WMS.
Para mostrar uno de los mapas predeterminados en Degree se realiza la siguiente petición
HTTP GET:
http://localhost:8080/deegreewms/services?REQUEST=GetMap&SERVICE=WMS&VERSION=1.1.1&WIDTH=603&HE
IGHT=476&LAYERS=Vegetation,Lake,Roads&TRANSPARENT=TRUE&FORMAT=image
/png&BBOX=372233.9342431239,4460438,489069,4552689&SRS=EPSG:26912&STYLES
=default,default,default
Y se mostrará en el navegador la imagen presentada en la figura (B.1).
Página 126
Anexo B. Evaluación de servidores de mapas
Figura B.1. Mapa visualizado en Degree.
2.2. Geoserver [GEOSERVER, 2008]
Es un servidor de código abierto que conecta información a la Web. Con Geoserver es posible
publicar y editar datos utilizando estándares abiertos. Su información se encuentra disponible
en una gran variedad de formatos. Está construido sobre GeoTools2 Java GIS toolkit.
Es usado en conjunción con clientes tales como OpenLayers para páginas Web, Google Earth,
Udig, GVSig y otros. El uso de estándares permite que la información de Geoserver pueda ser
fácilmente combinada con otros datos geográficos.
Características de Geoserver [GEOSERVERFEA, 2008]:
Totalmente compatible con especificaciones WMS, WFS (1.0, 1.1), WFS-T, SLD y
WCS.
Sencillo de usar pues posee una herramienta basada en Web para la configuración de
archivos.
Soporta PostGIS, ShapeFile, ArcSDE, DB2, Oracle, MySQL, MapInfo VPF y
Cascading WFS.
Soporta la proyección a vuelo.
Mapas en formato JPEG, GIF, PNG, SVG, GeoJSON GeoRSS.
Excelente soporte de Google Earth.
OpenLayers integrado como visor predeterminado AJAX.
Soporta SLD definidos por el usuario.
Está basado en la especificación J2EE, por lo que puede ejecutarse en cualquier
contenedor Web.
Está diseñado para ser extendido.
Corre en diferentes plataformas.
Página 127
Anexo B. Evaluación de servidores de mapas
A continuación se muestra un ejemplo de publicación de un mapa en Geoserver.
Para visualizar archivos Shape en Geoserver se siguen los siguientes pasos:
1. Ingresar a http://localhost:8080/geoserver/welcome.do y en la ventana resultante ingresar
al menú Configuración (ver figura B.2)
Figura B.2. Ingreso a Configuración.
2. Iniciar sesión en el sistema con nombre de usuario= admin y contraseña= geoserver (ver
figura B.3).
Figura B.3. Inicio de sesión en Geoserver.
3. Ingresar al menú Datos (ver figura B.4).
Figura B.4. Ingreso a los datos de Geoserver.
4. Dar clic en Espacios de nombres y en la página resultante dar clic en Nuevo (ver figura
B.5).
Página 128
Anexo B. Evaluación de servidores de mapas
Figura B.5. Configuración de espacio de nombres.
5. Ingresar el prefijo Mexico y pulsar Nuevo y en la casilla URI ingresar
http://localhost:8080/geoserver y pulsar Enviar (ver figura B.6).
Figura B.6. Creación del espacio de nombres.
6. Verificar que el espacio de nombres se haya creado como lo muestra la figura (B.7) y
pulsar aplicar y guardar para hacer efectivos los cambios en el servidor.
Figura B.7. Visualización del espacio de nombre México creado.
7. Crear un almacén de datos. El almacén de datos indica en tipo de archivo se va a publicar.
Para realizar esto dar clic en Configuración->Datos->Almacenes->Nuevo. En la
descripción de datos se selecciona Shapefile y se identifica al almacén con DS_Mexico tal
como lo muestra la figura (B.8) Y finalmente se pulsa el botón Nuevo.
Página 129
Anexo B. Evaluación de servidores de mapas
Figura B.8. Creación de un nuevo almacén de datos.
8. En el Editor del almacén de datos se ingresa el espacio de nombres Mexico, la URL donde
se encuentra el archivo Shape que se desea publicar, en este caso se ingresa
file:data/janet/States_region.shp, el cual corresponde a el path C:/Program
Files/GeoServer 1.6.2/data_dir/data/janet. En la carpeta data de Geoserver, se copian los
archivos Shape que se desean visualizar. Finalmente se da clic en Enviar (ver figura B.9).
Figura B.9. Editor del almacén de datos
9. Al dar clic en Enviar se abre el Editor de entidades. En él se ingresa el alias del mapa, en
este caso ingresamos AliasMexico, se ingresa el Estilo que se desea aplicar a el mapa, en
este caso se crea un nuevo estilo llamado States_Region_Style. Se indica el sistema de
referencia a trabajar. En nuestro caso es 4326 el cual es el identificador del sistema de
referencia WGS84. Se da clic en el botón Generar para crear las longitudes máximas y
mínimas en las que se visualizará el mapa. Finalmente se da clic en Enviar. Y se verifica
en Entidades que se haya agregado correctamente la entidad (ver figura B.10).
Página 130
Anexo B. Evaluación de servidores de mapas
Figura. B.10. Entidades disponibles en Geoserver
10. Para visualizar el mapa es necesario situarse en la página principal de Geoserver e
ingresar en la liga Demostración->Vista Preliminar de Mapas. Se visualizará una lista
parecida a la mostrada en la figura (B.11). En la lista se da clic en Mexico:AliasMexico, y
posteriormente visualizaremos el mapa como se muestra en la figura (B.12). Generando
Geoserver la siguiente cadena:
http://localhost:8080/geoserver/wms?bbox=-119.99049000000001,13.621244999883022,85.12511,33.62705500002082&styles=&Format=application/openlayers&request=GetMa
p&layers=Mexico:AliasMexico&width=800&height=430&srs=EPSG:4326
Figura B.11. Entidades disponibles en Geoserver
Página 131
Anexo B. Evaluación de servidores de mapas
Figura B.12. Visualización del mapa de México en Geoserver
2.3. MapServer [MAPSERVER, 2008]
MapServer es un ambiente de desarrollo de código abierto para construir aplicaciones
destinadas a ser publicadas en internet. No es un sistema GIS ni aspira a serlo. En lugar de ello,
MapServer sobresale en la presentación de datos espaciales (mapas, imágenes y datos
vectoriales) para su publicación a través de la Web.
MapServer fue originalmente desarrollado en la Universidad de Minesota (UMN) en
colaboración con la NASA y el Departamento de Recursos Naturales de Minesota (MNDNR).
Actualmente, MapServer es acogido por el proyecto TerraSIP, un proyecto patrocinado por la
NASA, UMN y el consorcio de intereses en gestión de la tierra.
Las características principales de MapServer son:
Salida cartográfica avanzada.
o Dibuja capas de información dependiendo de la escala.
o Dibuja etiquetas evitando la colisión entre ellas.
o Muestra elementos del mapa automáticos, como son escala gráfica, mapa de
referencia y leyenda.
Corre en plataformas Linux, Windows, Mac OS X y Solaris
Soporta los formatos vectoriales: ESRI Shapefile, PostGIS, ESRI ArcSDE, Oracle
Spatial, MySQL y otros vía OGR.
Soporta los formatos raster: TIFF/GeoTIFF, EPPL7, JPG, PNG, GIF y otros vía
GDAL.
Cumple con las especificaciones OGC: WMS, WFS, WMC,WCS, Filter Encoding,
SLD, GML, SOS.
Trabaja en dos modos:
o Modo CGI.
o Modo MapScript.
A continuación se muestra un ejemplo de publicación de un mapa en MapServer.
Para publicar un mapa usando MapServer es necesario tener claros algunos conceptos que se
definen enseguida.
MapServer puede funcionar en dos modos diferentes:
Página 132
Anexo B. Evaluación de servidores de mapas
Como ejecutable CGI. Se trata de un ejecutable que puede ser invocado desde páginas
Web para generar de forma dinámica imágenes.
Como biblioteca (MapScript). La necesidad de realizar tareas específicas en el lado del
servidor obligó a publicar las funcionalidades en este servidor en diferentes lenguajes
de programación (PHP, Python, Perl, Ruby, Java y C#) para poder realizar tareas con
un alto contenido dinámico.
Generalmente funciona como una aplicación CGI (CGI es una norma para establecer
comunicación entre un servidor Web y un programa, de modo que el programa pueda
interactuar en internet) y corre dentro de un servidor http.
El CGI de MapServer utiliza los siguientes recursos:
Un servidor http como Apache o Internet Information Server.
Software MapServer.
Un archivo de inicialización que active la primera vista de la aplicación MapServer
(opcional).
Un archivo MapFile que controle lo que MapServer hace con los datos.
Un Template File que controle la aplicación de MapServer en la ventana del navegador
de Internet.
Una fuente de datos GIS.
MapServer es normalmente instalado en el directorio cgi-bin del servidor http, y la fuente de
datos GIS es almacenada en el directorio de documentos del servidor http.
El archivo de inicialización puede ser parte de otro archivo HTML, pero por simplicidad
puede ser un archivo separado. Este archivo se utiliza para enviar una consulta inicial al
servidor http que devuelve un resultado del servidor de mapas. MapServer está sin estado, este
es iniciado y ejecuta una consulta cada vez que esta es recibida, para esto el archivo de
inicialización es requerido, para pasar una variedad de parámetros a la aplicación.
El MapFile especifica los datos que definen cómo las salidas del mapa y las leyendas de
MapServer se deben presentar en la página HTML. El MapFile contiene información acerca de
cómo se debe dibujar el mapa, la leyenda y el resultado de realizar una consulta. El MapFile
tiene extensión .map y se codifica con etiquetas especiales.
El Template File permite al autor del mapa colocar la posición de presentación del mapa, la
leyenda y determina que vías son disponibles para que el usuario interactúe con la aplicación
MapServer (browse, query, zoom in, zoom out, etc.). Para producir el documento HTML que
se envía al navegador, MapServer usa palabras clave en el archivo Template y las reemplaza
con información que se encuentra en la fuente de datos GIS. Cuando un Template File es usado
para crear un archivo HTML, este es almacenado generalmente con extensión .HTML.
El conjunto de datos GIS que el CGI MapServer usa es el formato Shapefile como formato
vectorial por default y en formato ráster utiliza geoTiff y Tiff. Puede utilizar algunos otros
formatos, dependiendo de cómo MapServer es compilado. El conjunto de datos GIS puede ser
ubicado en un directorio, el cual es referenciado al MapFile.
Para mostrar un ejemplo de visualización de un mapa en MapServer se requiere codificar un
archivo .map, siguiendo las etiquetas que se definen en la tabla (B.1).
Página 133
Anexo B. Evaluación de servidores de mapas
Tabla B.1. Abstracto de etiquetas usadas en MapServer
COMANDO
IMAGETYPE
EXTENT
DESCRIPCION
La palabra clave IMAGETYPE es usada para definir que formato de imagen podría usar el programa CGI Map Server
para la salida de las imágenes. En este caso se usa el color indexado PNG (similar al GIF). Este podría ser GIF, si se
compila la librería GD con soporte para GIF, WBMP, o JPEG. También se puede especificar otros formatos de salida
(PDF, SWF, Geotiff) asumiendo que se ha compilado el soporte para los mismos y que el OUTPUTHFORMAT es de
este tipo.
Este parámetro especifica las dimensiones de salida del mapa. Este necesita ser en las mismas unidades de los datos. En
este caso nuestra unidad de salida son los metros. Para extraer los valores de la extensión, se puede usar ArcView u
otro software SIG.
SIZE
Este es el tamaño de la imagen (el mapa) que el Map Server puede generar, en pixeles. Así el mapa es de 400 pixeles
de ancho por 300 pixeles de alto.
SHAPEPATH
Esta es la ruta en la que se localizan los archivos Shapefile que se desean visualizar.
IMAGECOLOR
Este es el color de fondo del mapa, los valores son RGB y valores como 255 Red, 255 Green y 255 Blue resultan en un
fondo de color blanco.
LAYER
Marca el inicio de un objeto LAYER dentro de un objeto MAP. En MapServer se puede especificar los layers que se
deseen y el límite de capas (se proporcionan 100 por default). Para modificar el límite de capas a visualizar se requiere
recompilar el CGI Map Server.
NAME
Este es el identificador del nombre de cada uno de los layers especificados.
DATA
El nombre del dato (Shapefile en este caso). Map Server soporta formatos vectoriales y otros Shapefiles que ESRI usa
de ORG library (parte del GDAL software).
TYPE
Se usa para especificar el tipo de dato que se va a visualizar el cual puede ser: POLYGON; LINE o POINT para
formatos vectoriales.
STATUS
Los layers pueden ser colocados en ON u OFF basados en su STATUS. DEFAULT es siempre en ON o visible. ON u
OFF funciona cuando el nombre del LAYER es pasado como parte del parámetro del query string.
CLASS
Marca el inicio de un objeto CLASS dentro de un objeto LAYER. Se pueden especificar muchas clases en un layer y
por default se permiten 50. Para cambiar este valor se requiere recompilar el CGI Map Server.
COLOR
Este es el color de relleno del polígono. En caso de que el TYPE sea LINE, este es el color de línea. Los valores son en
formato RGB.
OUTLINECOLOR
Este es el color de línea de salida de los polígonos. Este valor esta dado en RGB.
CLASSITEM
Esta palabra clave es usada para especificar que atributos se usan para separar un objeto de la clase.
EXPRESSION
FONSET
LABELITEM
LABEL
COLOR
SHADOWSIZE
TYPE
FONT
SIZE
POSITION
Por cada clase, se requiere especificar qué valores de atributos se utilizan. Esta es la forma simple del valor
EXPRESSION. EXPRESSION puede ser más complejo incluso que esto.
Aquí se especifica la ruta completa de el archivo truetype fontlist (lista de fuentes). Este archivo lista cada una de las
fuentes disponibles.
Este especifica que atributos de datos se usa para el etiquetado. LABELITEM es un parámetro del objeto LAYER.
Marca el inicio del objeto LABEL. El objeto label puede ser usado bajo otros objetos (Ejemplo: El objeto
SCALEBAR).
En el objeto LABEL, COLOR especifica el control de etiqueta de texto.
Especifica el tamaño de la sombra. El valor correspondiente para las variables X e Y en pixeles. Para “2 2” quiere decir
dos pixeles de ancho y dos pixeles de alto.
En el objeto LABEL, TYPE especifica qué tipo de fuente se va a usar. Es posible escoger entre TRUETYPE o Bitmap
(el constructor en fuentes).
Si se especifica TYPE como TRUETYPE, éste necesita especificar qué fuente usará. El valor de esta es el “alias” en el
archivo de lista de fuentes.
Si se usan fuentes truetype, el valor del tamaño es en pixeles. Si es bitmap, se puede escribir “small” o “large”.
Indica la posición de la etiqueta de texto con relación a los puntos de label. Los valores son una combinación de
posiciones verticales y horizontales. Se puede elegir para una alineación vertical: C para el centro, L para la izquierda y
R para la derecha. Para la alineación de la etiqueta de texto en el centro del label ID se debe usar el valor “CC” (centercenter). O si se quiere por abajo del ID se debe usar el “LL”.
En la figura (B.13) se ilustra el archivo MAP utilizado para publicar el mapa de México en
MapServer.
Página 134
Anexo B. Evaluación de servidores de mapas
Figura B.13. Archivo .map
Una vez que se configura el archivo .map se procede a crear el archivo de inicialización. Este
archivo mandará los parámetros a MapServer. El archivo de inicialización del archivo
MAPFILE mostrado en la figura anterior se ilustra en la figura (B.14).
Figura B.14. Archivo de inicialización ejemplo2.html
Finalmente para visualizar el mapa se introduce la cadena de petición
http://127.0.0.1:8081/ejemplo2/ejemplo2.html en el navegador Web y como resultado
observamos el archivo de inicialización. Al hacer clic en “Click Me” se visualiza el mapa
como se observa en la figura (B.15).
Página 135
Anexo B. Evaluación de servidores de mapas
Figura B.15. Mapa visualizado en MapServer
3. Definición de metodología de evaluación
Para realizar la evaluación de los servidores de mapas anteriormente mencionados se llevaron a cabo
los siguientes pasos:
1. Definir criterios de evaluación, es decir, qué características debe cumplir el servidor de mapas
para utilizarlo como proveedor de mapas en el proyecto (ver tabla B.2).
Tabla B.2. Definición de criterios
CRITERIOS
Característica 1
Característica 2
Característica N
2. Asignar ponderaciones a cada criterio en un rango del 1 al 5 tomando como base la
importancia de cada una de éstas en el proyecto (ver tabla B.3).
.
Tabla B.3. Asignación de ponderaciones a cada criterio
CRITERIOS
PONDERACIÓN
5
Característica 1
3
Característica 2
1
Característica N
5: más importante, 1: menos importante
3. Evaluar cada servidor de acuerdo a los criterios que se definieron en el paso 1. La forma de
evaluar cada característica es asignar una calificación del 1 al 10 de acuerdo a que tanto
cumple con los requerimientos (ver tabla B.4) y si se desea se pueden incluir observaciones en
cada asignación de calificación.
Página 136
Anexo B. Evaluación de servidores de mapas
Tabla B.4. Asignación de calificaciones a cada servidor de mapas de acuerdo a los criterios
CRITERIOS
Característica 1
Característica 2
Característica N
PESO
WMS-1
CALIFICACIÓN
WMS-2
CALIFICACIÓN
5
10
3
5
1
8
10: más importante, 1: menos importante
1
4
2
4. Obtener el producto peso-calificación por característica definida en el paso 1 con la finalidad
de obtener un subtotal (ver tabla B.5).
Tabla B.5. Obtención de productos por criterio
CRITERIOS
PESO
WMS-1
WMS-2
50
Califiic.
1
Subtotal
5
Calific.
10
Subtotal
Característica 1
Característica 2
3
5
15
4
12
Característica N
1
8
8
2
2
5
5. Realizar la sumatoria por servidor de los subtotales obtenidos en el paso 4 (ver tabla B.6).
Tabla B.6. Obtención de sumatorias por WMS
CRITERIOS
PESO
WMS- 2
WMS-1
50
Califiic.
1
Subtotal
5
Calific.
10
Subtotal
Característica 1
Característica 2
3
5
15
4
12
Característica N
1
8
8
2
2
TOTAL
-
73
5
19
6. Comparar los resultados del paso 5 y elegir el servidor de mapas que mayor puntaje tenga (ver
figura B.16).
Figura B.16. Gráfico comparativo de la evaluación de los servidores de mapas
Página 137
Anexo B. Evaluación de servidores de mapas
4. Desarrollo de la metodología de evaluación
A continuación se desarrollan los pasos definidos en la metodología de evaluación tomando en cuenta
los tres servidores de mapas mencionados en la sección 3 del documento.
Paso 1. Definición de criterios de evaluación
Para elegir el servidor de mapas que se usará en el proyecto, se definieron los siguientes criterios a
evaluar:
Código abierto: el servidor de mapas debe de tener disponible su código fuente para tener total
libertad de utilizarlo y modificarlo en caso de que se requiera.
Fácil de instalar y manejar: se requiere que el servidor de mapas sea sencillo de manejar para
no invertir mucho tiempo en la instalación y manipulación del servidor.
Codificado en JAVA: el servidor de mapas debe estar codificado en Java para cumplir con las
especificaciones del proyecto de tesis.
Implementar las especificaciones de la OGC: el servidor de mapas debe cumplir con
especificaciones OGC en especial WMS, WFS y SLD ya que la estandarización aporta
beneficios en términos de migración de datos.
Soportar el formato Shapefile: el servidor de mapas a elegir debe ser capaz de visualizar
archivos vectoriales (shp) ya que es el formato en el que se basa el proyecto de tesis.
Paso 2. Asignación de ponderaciones
De acuerdo al nivel de importancia que tienen los criterios mencionados en el paso 1, se asignan los
siguientes pesos:
Tabla B.7. Asignación de ponderaciones a cada criterio
CRITERIOS
Código abierto
Fácil de instalar y manejar
Codificado en JAVA
Implementar las especificaciones OGC
Soportar el formato Shapefile
PONDERACIÓN
5
5
2
5
5
Paso 3,4 y5. Asignación de calificaciones, producto de calificación-peso y sumatoria
Las calificaciones mostradas en la tabla (B.8) se asignaron de acuerdo a la experiencia obtenida al
realizar la instalación y configuración de los servidores de mapas mencionados en la sección 3 del
documento.
Página 138
Anexo B. Evaluación de servidores de mapas
Tabla B.8. Comparativa de servidores
CRITERIOS
Código abierto
P
E
S
C
O
5
GEOSERVER
DEGREE
MAPSERVER
Observaciones
S
C
Observaciones
S
C
Observaciones
S
10
Se puede descargar el código en
un archivo.jar
50
10
Es posible descargar el código fuente
de la página oficial.
50
10
Permite descargar el código fuente
de la página oficial.
50
10
10
Provee una interfaz amigable que
permite configurar el servidor sin
introducir líneas de código. Además
de que se encuentra disponible en
español y muestra los mapas en
OpenLayers.
50
2
Para visualizar un mapa se
necesita codificar manualmente un
archivo de configuración
MAPFILE y un archivo de
inicialización.
10
Fácil de instalar y
manejar
5
2
La instalación es sencilla pero la
manipulación del servidor es
compleja. Se requiere codificar
manualmente archivos XML
Codificado en Java
2
10
Está programado en Java
20
10
La interfaz sigue el modo de
programación Struts
20
0
Está programado en C++
0
Implementar las
especificaciones
OGC
5
10
Implementa una amplia gama de
especificaciones entre ellas están
WMS, WFS y SLD
50
10
Cumple con varias especificaciones y
entre ellas se encuentran WMS, WFS
y SLD
50
10
Cumple con varias
especificaciones y entre ellas se
encuentran WMS, WFS y SLD
50
Soportar el
formato Shapefile
5
10
También soporta formatos ráster
50
10
Soporta archivos Shp y gracias a su
programación es posible ampliar la
cantidad de formatos
50
10
Soporta otros archivos vía GDAL
y OGR
50
TOTAL
-
180
220
160
C: calificación
S: subtotal
Página 139
Anexo B. Evaluación de servidores de mapas
Paso 6. Comparar resultados
De los servidores de mapas analizados, Geoserver es el servidor que implementa las especificaciones
OGC que se requieren en el proyecto y permite publicar los mapas por medio de interfaces gráficas,
por lo que resulta sencilla su manipulación.
Por otro lado Degree y Mapserver no cumplen con la característica de facilidad de manejo, esto debido
a que se requiere codificar manualmente los archivos necesarios para la publicación de un mapa.
Por lo tanto, como el objetivo de la tesis no se enfoca en la profundización del funcionamiento de los
servidores de mapas, Geoserver es la mejor alternativa de servidor para publicar mapas en la Web.
En la figura (B.17) se muestra la gráfica de los resultados obtenidos de la evaluación de mapas.
Gráfica de resultados
250
220
200
150
180
160
100
50
0
DEGREE
GEOSERVER
MAPSERVER
Figura B.17. Resultados de la evaluación de servidores de mapas
Página 140
ANEXO C
Diseño de objetos para el documento SLD
Anexo C. Diseño de objetos para el documento SLD
UserStyle
- Name
: java.lang.String
- Title
: java.lang.String
- Abstracts : java.lang.String
- IsDefault : boolean
+
+
+
+
+
+
+
+
StyledLayerDescriptor
- version
: java.lang.String
- Name
: java.lang.String
- Title
: java.lang.String
- Abstracts : java.lang.String
+
+
+
+
+
+
+
+
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
NamedLayer
getVersion ()
setVersion (java.lang.String newVersion)
getName ()
setName (java.lang.String newName)
getTitle ()
setTitle (java.lang.String newTitle)
getAbstracts ()
setAbstracts (java.lang.String newAbstracts)
:
:
:
:
:
:
:
:
- Name : java.lang.String
1..1
java.lang.String
void
java.lang.String
void
java.lang.String
void
java.lang.String
void
1..*
+ <<Getter>> getName ()
: java.lang.String
+ <<Setter>> setName (java.lang.String newName) : void
0..*
1..1
getName ()
setName (java.lang.String newName)
getTitle ()
setTitle (java.lang.String newTitle)
getAbstracts ()
setAbstracts (java.lang.String newAbstracts)
getIsDefault ()
setIsDefault (boolean newIsDefault)
:
:
:
:
:
:
:
:
java.lang.String
void
java.lang.String
void
java.lang.String
void
boolean
void
1..*
Rule
-
Featureid
0..*
- Fid : java.lang.String
0..*
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
Filter
0..1
1..1
+ <<Getter>> getFid ()
: java.lang.String
+ <<Setter>> setFid (java.lang.String newFid) : void
1..1
ElseFilter
0..1
1..1
+
+
+
+
+
+
+
+
+
+
+
+
Name
Title
Abstracts
LegendGraphic
MinScaleDenominator
MaxScaleDenominator
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
:
:
:
:
:
:
FeatureTypeStyle
java.lang.String
java.lang.String
java.lang.String
Graphic
float
float
getName ()
setName (java.lang.String newName)
getTitle ()
setTitle (java.lang.String newTitle)
getAbstracts ()
setAbstracts (java.lang.String newAbstracts)
getMinScaleDenominator ()
setMinScaleDenominator (float newMinScaleDenominator)
getMaxScaleDenominator ()
setMaxScaleDenominator (float newMaxScaleDenominator)
getLegendGraphic ()
setLegendGraphic (Graphic newLegendGraphic)
:
:
:
:
:
:
:
:
:
:
:
:
-
1..*
java.lang.String
void
java.lang.String
void
java.lang.String
void
float
void
float
void
Graphic
void
+
+
+
+
+
+
+
+
+
+
1..1
Name
Title
Abstracts
FeatureTypeName
SemanticTypeIdentifier
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
:
:
:
:
:
java.lang.String
java.lang.String
java.lang.String
java.lang.String
java.util.Collection
getName ()
setName (java.lang.String newName)
getTitle ()
setTitle (java.lang.String newTitle)
getAbstracts ()
setAbstracts (java.lang.String newAbstracts)
getFeatureTypeName ()
setFeatureTypeName (java.lang.String newFeatureTypeName)
getSemanticTypeIdentifier ()
setSemanticTypeIdentifier (java.util.Collection newSemanticTypeIdentifier)
:
:
:
:
:
:
:
:
:
:
java.lang.String
void
java.lang.String
void
java.lang.String
void
java.lang.String
void
java.util.Collection
void
1..1
1..*
SymbolizerType
{abstract}
Label
Halo
- Label : java.lang.String
- Radius : float
0..1
+ <<Getter>> getLabel ()
: java.lang.String
+ <<Setter>> setLabel (java.lang.String newLabel) : void
+ <<Getter>> getRadius ()
: float
+ <<Setter>> setRadius (float newRadius) : void
1..1
LineSymbolizer
TextSymbolizer
1..1
1..1
1..1
0..1
PointSymbolizer
PolygonSymbolizer
1..1
1..1
1..1
0..1
1..1
1..1
LabelPlacement
1..1
1..1
1..1
1..1
1..1
1..1
0..1
1..1
ExpressionType
Stroke
0..1
1..1
0..1
0..1
{abstract}
1..1
- expression : java.lang.String
1..1
LinePlacement
PointPlacement
0..1
+ <<Getter>> getRotation ()
: float
+ <<Setter>> setRotation (float newRotation) : void
0..1
0..1
0..1
PropertyNameType
0..1
- AnchorPointX : float
- AnchorPointY : float
+ <<Getter>> getPropertyName ()
: PropertyNameType
+ <<Setter>> setPropertyName (PropertyNameType newPropertyName) : void
+
+
+
+
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
getAnchorPointX ()
: float
setAnchorPointX (float newAnchorPointX) : void
getAnchorPointY ()
: float
setAnchorPointY (float newAnchorPointY) : void
0..1
PerpendicularOffset
Displacement
AnchorPoint
- PropertyName : PropertyNameType
GraphicFill
0..1
0..1
Geometry
0..1
0..1
1..1
1..1
1..1 - Rotation : float
+ <<Getter>> getExpression ()
: java.lang.String
+ <<Setter>> setExpression (java.lang.String newExpression) : void
- DisplacementX : float
- DisplacementY : float
+ <<Getter>> getDisplacementX ()
: float
+ <<Setter>> setDisplacementX (float newDisplacementX) : void
+ <<Getter>> getDisplacementY ()
: float
+ <<Setter>> setDisplacementY (float newDisplacementY) : void
- PerpendicularOffset : java.lang.String
+ <<Getter>> getPerpendicularOffset ()
: java.lang.String
+ <<Setter>> setPerpendicularOffset (java.lang.String newPerpendicularOffset) : void
0..1
0..*
CssParameter
Font
0..*
- name : java.lang.String
- valor : java.lang.String
0..1
0..1
GraphicStroke
Graphic
0..1
- Opacity : java.lang.String
- Size
: java.lang.String
- Rotation : java.lang.String
+
+
+
+
+
+
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
<<Getter>>
<<Setter>>
0..1
1..1
+ <<Getter>> getName ()
: java.lang.String
+ <<Setter>> setName (java.lang.String newName) : void
+ <<Getter>> getValor ()
: java.lang.String
+ <<Setter>> setValor (java.lang.String newValor) : void
0..1
0..*
0..1
getOpacity ()
setOpacity (java.lang.String newOpacity)
getSize ()
setSize (java.lang.String newSize)
getRotation ()
setRotation (java.lang.String newRotation)
:
:
:
:
:
:
java.lang.String
void
java.lang.String
void
java.lang.String
void
0..1
Fill
1..1
0..1
0..1
1..1
0..1
1..1
1..1
1..1
Mark
0..*
1..1
- WellKnownName : java.lang.String
+ <<Getter>> getWellKnownName ()
: java.lang.String
+ <<Setter>> setWellKnownName (java.lang.String newWellKnownName) : void
0..*
ExternalGraphic
SimpleLink
- OnlineResource : SimpleLink
- Format
: java.lang.String
- type : java.lang.String
- href : java.lang.String
+ <<Getter>> getOnlineResource ()
: SimpleLink
+ <<Setter>> setOnlineResource (SimpleLink newOnlineResource) : void
+ <<Getter>> getFormat ()
: java.lang.String
+ <<Setter>> setFormat (java.lang.String newFormat)
: void
+ <<Getter>> getType ()
: java.lang.String
+ <<Setter>> setType (java.lang.String newType) : void
+ <<Getter>> getHref ()
: java.lang.String
+ <<Setter>> setHref (java.lang.String newHref)
: void
= simple
Figura C.1. Diagrama de objetos SLD
Página 142
Anexo C. Diseño de objetos para el documento SLD
class SLD
NamedLayer
StyledLayerDescriptor
+
-
abstracts: java.lang.String
name: java.lang.String
namedLayer: java.util.Collection
title: java.lang.String
version: java.lang.String
+
+
+
+
+
+
+
+
+
+
+
+
+
+
addNamedLayer(NamedLayer) : void
getAbstracts() : java.lang.String
getIteratorNamedLayer() : java.util.Iterator
getName() : java.lang.String
getNamedLayer() : java.util.Collection
getTitle() : java.lang.String
getVersion() : java.lang.String
removeAllNamedLayer() : void
removeNamedLayer(NamedLayer) : void
setAbstracts(java.lang.String) : void
setName(java.lang.String) : void
setNamedLayer(java.util.Collection) : void
setTitle(java.lang.String) : void
setVersion(java.lang.String) : void
UserStyle
+
name: java.lang.String
userStyle: java.util.Collection
+
+
+
+
+
+
+
+
addUserStyle(UserStyle) : void
getIteratorUserStyle() : java.util.Iterator
getName() : java.lang.String
getUserStyle() : java.util.Collection
removeAllUserStyle() : void
removeUserStyle(UserStyle) : void
setName(java.lang.String) : void
setUserStyle(java.util.Collection) : void
CssParameter
-
name: java.lang.String
valor: java.lang.String
+
+
+
+
getName() : java.lang.String
getValor() : java.lang.String
setName(java.lang.String) : void
setValor(java.lang.String) : void
-
format: java.lang.String
onlineResource: SimpleLink
+
+
+
+
getFormat() : java.lang.String
getOnlineResource() : SimpleLink
setFormat(java.lang.String) : void
setOnlineResource(SimpleLink) : void
abstracts: java.lang.String
featureTypeStyle: java.util.Collection
isDefault: boolean
name: java.lang.String
title: java.lang.String
+
+
+
+
+
+
+
+
+
+
+
+
+
+
addFeatureTypeStyle(FeatureTypeStyle) : void
getAbstracts() : java.lang.String
getFeatureTypeStyle() : java.util.Collection
getIsDefault() : boolean
getIteratorFeatureTypeStyle() : java.util.Iterator
getName() : java.lang.String
getTitle() : java.lang.String
removeAllFeatureTypeStyle() : void
removeFeatureTypeStyle(FeatureTypeStyle) : void
setAbstracts(java.lang.String) : void
setFeatureTypeStyle(java.util.Collection) : void
setIsDefault(boolean) : void
setName(java.lang.String) : void
setTitle(java.lang.String) : void
Featureid
-
fid: java.lang.String
+
+
getFid() : java.lang.String
setFid(java.lang.String) : void
ExternalGraphic
Displacement
displacementX: float
displacementY: float
+
+
+
+
getDisplacementX() : float
getDisplacementY() : float
setDisplacementX(float) : void
setDisplacementY(float) : void
+displacement
+
-
abstracts: java.lang.String
featureTypeName: java.lang.String
name: java.lang.String
rule: java.util.Collection
semanticTypeIdentifier: java.util.Collection
title: java.lang.String
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
addRule(Rule) : void
getAbstracts() : java.lang.String
getFeatureTypeName() : java.lang.String
getIteratorRule() : java.util.Iterator
getName() : java.lang.String
getRule() : java.util.Collection
getSemanticTypeIdentifier() : java.util.Collection
getTitle() : java.lang.String
removeAllRule() : void
removeRule(Rule) : void
setAbstracts(java.lang.String) : void
setFeatureTypeName(java.lang.String) : void
setName(java.lang.String) : void
setRule(java.util.Collection) : void
setSemanticTypeIdentifier(java.util.Collection) : void
setTitle(java.lang.String) : void
+
+
+
+
Filter
ElseFilter
+
+
-
externalGraphic: java.util.Collection
mark: java.util.Collection
opacity: java.lang.String
rotation: java.lang.String
size: java.lang.String
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
addExternalGraphic(ExternalGraphic) : void
addMark(Mark) : void
getExternalGraphic() : java.util.Collection
getIteratorExternalGraphic() : java.util.Iterator
getIteratorMark() : java.util.Iterator
getMark() : java.util.Collection
getOpacity() : java.lang.String
getRotation() : java.lang.String
getSize() : java.lang.String
removeAllExternalGraphic() : void
removeAllMark() : void
removeExternalGraphic(ExternalGraphic) : void
removeMark(Mark) : void
-legendGraphic
setExternalGraphic(java.util.Collection) : void
setMark(java.util.Collection) : void
setOpacity(java.lang.String) : void
setRotation(java.lang.String) : void
setSize(java.lang.String) : void
+graphic
SimpleLink
-onlineResource -
AnchorPoint
-
Graphic
FeatureTypeStyle
+
-
+graphic
+
featureid: java.util.Collection
+
+
+
+
+
+
addFeatureid(Featureid) : void
getFeatureid() : java.util.Collection
getIteratorFeatureid() : java.util.Iterator
removeAllFeatureid() : void
+filter
removeFeatureid(Featureid) : void
setFeatureid(java.util.Collection) : void
+elseFilter
Rule
+graphic
href: java.lang.String
type: java.lang.String = "simple"
getHref() : java.lang.String
getType() : java.lang.String
setHref(java.lang.String) : void
setType(java.lang.String) : void
PerpendicularOffset
-
anchorPointX: float
anchorPointY: float
+
+
+
+
getAnchorPointX() : float
getAnchorPointY() : float
setAnchorPointX(float) : void
setAnchorPointY(float) : void
-
perpendicularOffset: java.lang.String
+
+
getPerpendicularOffset() : java.lang.String
setPerpendicularOffset(java.lang.String) : void
GraphicFill
+perpendicularOffset
+
+graphicFill
graphic: Graphic
+anchorPoint
+graphicFill
GraphicStroke
+
-propertyName
+
+
addCssParameter(CssParameter) : void
getCssParameter() : java.util.Collection
getIteratorCssParameter() : java.util.Iterator
removeAllCssParameter() : void
removeCssParameter(CssParameter) : void
setCssParameter(java.util.Collection) : void
+font
+
+
getExpression() : java.lang.String
setExpression(java.lang.String) : void
Stroke
+linePlacement
Font
cssParameter: java.util.Collection
expression: java.lang.String
perpendicularOffset: PerpendicularOffset
+pointPlacement
+
+
+
+
+
+
-
Fill
getRotation() : float
setRotation(float) : void
+
addSymbolizerType(SymbolizerType) : void
getAbstracts() : java.lang.String
getIteratorSymbolizerType() : java.util.Iterator
getLegendGraphic() : Graphic
getMaxScaleDenominator() : float
getMinScaleDenominator() : float
getName() : java.lang.String
getSymbolizerType() : java.util.Collection
getTitle() : java.lang.String
removeAllSymbolizerType() : void
removeSymbolizerType(SymbolizerType) : void
setAbstracts(java.lang.String) : void
setLegendGraphic(Graphic) : void
setMaxScaleDenominator(float) : void
setMinScaleDenominator(float) : void
setName(java.lang.String) : void
setSymbolizerType(java.util.Collection) : void
setTitle(java.lang.String) : void
ExpressionType
LinePlacement
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
PropertyNameType
+graphicStroke
anchorPoint: AnchorPoint
displacement: Displacement
rotation: float
abstracts: java.lang.String
elseFilter: ElseFilter
filter: Filter
legendGraphic: Graphic
maxScaleDenominator: float
minScaleDenominator: float
name: java.lang.String
symbolizerType: java.util.Collection
title: java.lang.String
graphic: Graphic
PointPlacement
+
+
-
+
+
+
-
LabelPlacement
+
+
linePlacement: LinePlacement
pointPlacement: PointPlacement
+labelPlacement
+
+
cssParameter: java.util.Collection
graphicFill: GraphicFill
+
+
+
+
+
+
addCssParameter(CssParameter) : void
getCssParameter() : java.util.Collection
getIteratorCssParameter() : java.util.Iterator
removeAllCssParameter() : void
removeCssParameter(CssParameter) : void
setCssParameter(java.util.Collection) : void
+fill
Label
+fill
+fill
+fill
+
+
+
cssParameter: java.util.Collection
graphicFill: GraphicFill
graphicStroke: GraphicStroke
+
+
+
+
+
+
addCssParameter(CssParameter) : void
getCssParameter() : java.util.Collection
getIteratorCssParameter() : java.util.Iterator
removeAllCssParameter() : void
removeCssParameter(CssParameter) : void
setCssParameter(java.util.Collection) : void
+stroke
-
label: java.lang.String
+
+
getLabel() : java.lang.String
setLabel(java.lang.String) : void
+label
Geometry
+geometry
-
propertyName: PropertyNameType
+
+
getPropertyName() : PropertyNameType
setPropertyName(PropertyNameType) : void
+stroke
+geometry
+geometry
+geometry
+stroke
Mark
Halo
+
-
fill: Fill
radius: float
+
+
getRadius() : float
setRadius(float) : void
+
+
-
fill: Fill
stroke: Stroke
wellKnownName: java.lang.String
+
+
getWellKnownName() : java.lang.String
setWellKnownName(java.lang.String) : void
PolygonSymbolizer
+
+
+
fill: Fill
geometry: Geometry
stroke: Stroke
LineSymbolizer
+
+
geometry: Geometry
stroke: Stroke
PointSymbolizer
+
+
geometry: Geometry
graphic: Graphic
+halo
TextSymbolizer
+
+
+
+
+
+
fill: Fill
font: Font
geometry: Geometry
halo: Halo
label: Label
labelPlacement: LabelPlacement
SymbolizerType
Figura C.2. Diagrama de clases SLD
Página 143
Anexo C. Diseño de objetos para el documento SLD
Página 144
ANEXO D
Síntesis de la Especificación SLD
-Styled Layer Descriptor Versión 1.0.0-
Anexo D. Síntesis de la especificación SLD
1. Introducción
La presente especificación describe de manera general el esquema del lenguaje de estilizado de mapas
para producir mapas geográficos con estilos definidos por el usuario.
2. Especificación SLD
Styled Layer Descriptor (SLD por sus siglas en inglés) es un lenguaje XML para personalizar la
apariencia de un mapa. Tiene una estructura propia, formado por el elemento principal
StyledLayerDescriptor el cual contiene una secuencia de definiciones de estilo para los mapas.
2.1 Elemento principal del archivo SLD
El esquema XML que define la cabecera de un documento SLD se muestra en la figura (D.1):
Figura D.1. Esquema SLD del elemento raíz
En la figura (D.1) se puede apreciar que la cabecera está formada por los elementos NamedLayer
y UserLayer. El atributo version es utilizado para indicar la versión del documento SLD. Por
ejemplo un documento SLD basado en la presente especificación debería tener la cadena “1.0.0”
asignada en el atributo version.
Es importante tener en cuenta que el orden en que aparezcan las capas en el documento SLD será
el orden en que se dibujen.
2.2 Named Layers
Una capa o layer es definida como un conjunto de entidades que pueden ser de varias clases. La
especificación WMS usa el parámetro LAYER para hacer referencia a los nombres de las capas.
Por ejemplo: LAYERS=carreteras, ríos, casas
Un servidor WMS va a reconocer directamente las Named Layers, esto gracias a que el
documento GetCapabilities describe las capas que provee el servidor de mapas.
Si se quiere personalizar la visualización de las capas es necesario utilizar SLD, es decir, no
utilizar los estilos definidos por el WMS, sino personalizar los elementos que va a contener la
capa.
El esquema XML del elemento NamedLayer se presenta en la figura (D.2):
Página 146
Anexo D. Síntesis de la especificación SLD
Figura D.2. Esquema de elemento NamedLayer
El elemento NamedLayer está formado por los elementos Name, LayerFeatureConstrains,
NameStyle y UserStyle. El elemento Name identifica un nombre bien conocido (well-known
name) de las capas y es obligatorio. El elemento LayerFeatureConstraints es opcional y es para
definir restricciones en las entidades que se seleccionan. El elemento NamedStyle es utilizado para
incluir cualquier número y en cualquier orden los nombres de estilos tanto definidos por el usuario
como por el servidor WMS. Todos los estilos disponibles para cada capa son normalmente citados
en el documento GetCapabilities.
2.3 UserLayers
Un WMS utiliza el parámetro STYLES para especificar el estilo relativo a las capas LAYERS,
por ejemplo:
LAYERS=carreteras, ríos, casas
STYLES=Centerline, Centerline, Outline
El esquema XML para el elemento UserLayers se presenta en la figura (D.3):
Figura D.3. Esquema de elemento UserLayer
El elemento Name indica el nombre de la capa que va a definir el usuario. El elemento
RemoteOWS especifica el lugar en el que se encuentran los datos a personalizar, es decir, el
servidor Web OGC utilizado (WFS/WCS).
El esquema XML que describe a RemoteOWS se presenta en la figura (D.4):
Página 147
Anexo D. Síntesis de la especificación SLD
Figura D.4. Esquema de elemento RemoteOWS
El elemento RemoteOWS está formado por los elementos Service y OnlineResource.
Por su parte, LayerFeatureConstrains especifica qué tipos de entidades se van a incluir en la capa.
El fragmento de esquema XML de LayerFeatureConstrains se presenta en la figura (D.5):
Figura D.5. Esquema XML para el elemento LayerFeatureConstraints
Página 148
Anexo D. Síntesis de la especificación SLD
LayerFeatureConstrains está formado por los elementos FeatureTypeName, Filter y Extent
(name, value).
Los Named Styles no pueden ser usados con capas definidas por el usuario. Sólo estilos definidos
por el usuario (UserStyles) pueden ser usados en capas definidas por el usuario (UserLayers)
En la figura (D.6) se presenta el ejemplo de un SLD que usa capas definidas por el usuario:
Figura D.6. Ejemplo de capa definida por el usuario
2.4 UserStyles
UserStyle especifica el estilo creado por el usuario. La definición del esquema se presenta en la
figura (D.7).
Figura D.7. Esquema XML del estilo definido por el usuario
Página 149
Anexo D. Síntesis de la especificación SLD
UserStyle está formado por los elementos Name, Title, Abstract,IsDefault, FeatureTypeStyle.
Name, Title y Abstract son opcionales. Name se usa para llamar al estilo externamente cuando un
SLD se almacena dentro de un WMS, Title es una descripción corta para el estilo y Abstract es
una descripción más extensa. El elemento IsDefault identifica si un estilo es el estilo por defecto
para una capa (Se usa 1 para verdadero y 0 para falso).
A continuación en la figura (D.8) se muestra un ejemplo incompleto de un estilo definido por el
usuario utilizando un NamedLayer.
Figura D.8. Ejemplo de UserStyle
2.5 FeatureTypeStyles
Los FeatureTypeStyles definen el estilo que se va a aplicar a un tipo de entidad de una capa. Un
UserStyle puede contener uno o más elementos de éste. El esquema XML se muestra en la figura
(D.9):
Figura D.9. Esquema XML de FeatureTypeStyle
FeatureTypeStyles está formado por los elementos Name, Title, Abstract, FeatureTypeName,
SemanticTypeIdentifier y Rule. FeatureTypeName: identifica el tipo de entidad específica para el
FeatureTypeStyle que se ha definido. SemanticTypeIdentifier es experimental e identifica que
estilo de entidad es conveniente para ser usada por muchos tipos de entidades. Es un string
indefinido pero se definen los siguientes valores: “generic:line”, ”generic:polygon”,
”generic:point”, ”generic:text”, ”generic:raster” y “generic:any”.
Página 150
Anexo D. Síntesis de la especificación SLD
Un elemento FeatureTypeStyle contiene una o más elementos Rule. El elemento Rules identifica
las reglas a cumplir por FeatureTypeStyle.
2.6 Rules
Describe las reglas a cumplir para el dibujo de los elementos según la escala de los mapas y las
características de los elementos. El esquema XML para el elemento Rule se muestra en la figura
(D.10).
Figura D.10. Esquema XML del elemento Rule
El elemento Rule está formado por los elementos Name, Title, Abstract, LegendGraphic, Filter,
ElseFilter, MinScaleDenominator, MaxScaleDenominator, LineSimbolizer, PoligonSymbolizer,
PointSymbolizer, TextSymbolizer y RasterSymbolizer.
Las Rules deben localizarse en orden de “prioridad” dentro de UserStyle (las más importantes
primero). Title y Abstract son elementos que dan un título corto de la regla para aparecer en una
lista y una descripción de la misma. Name permite referenciar externamente la regla.
El elemento LegendGraphic contiene el símbolo Graphic para luego ser mostrado en la leyenda.
El esquema XML de este elemento se presenta en la figura (D.11):
Figura D.11. Esquema XML de LegendGraphic
Página 151
Anexo D. Síntesis de la especificación SLD
MinScaleDenominator y MaxScaleDenominator define el rango de escalas de visualización del
mapa. En la figura (D.12) se presenta su esquema:
Figura D.12. Esquema XML para MinScaleDenominator y MaxScaleDenominator
Los valores usados son el denominador de la escala. La mínima escala es inclusive y la máxima
exclusive y son opcionales. Por ejemplo:
<MinScaleDenominator>100e3</MinScaleDenominator>
<MaxScaleDenominator>1e6</MaxScaleDenominator>
Corresponden a la siguiente condición lógica:
scale_denom >= 100e3 && scale_denom < 1e6
Filter y ElseFilter permiten la selección de entidades según condiciones definidas por sus
atributos. Filter permite tanto filtrar espacialmente como por atributos. Los filtros se ejecutan en
el orden que van apareciendo. ElseFilter permite definir reglas que son activadas para entidades
que no se ven afectadas por otra regla. En la figura (D.13) se muestra un ejemplo del uso de Filter
y ElseFilter:
Figura D.13. Ejemplo de Filter y ElseFilter
El ejemplo anterior describe que todas las entidades en la capa se van a dibujar, las que tienen
atributo igual a 1 se dibujarán en rojo y las restantes en gris.
2.7 Simbolización
Está localizada dentro de la definición de las “Reglas” y describe cómo van a aparecer las
entidades en el mapa (forma, color, etc.). Se define según el tipo y tienen sus parámetros
asociados. Los tipos de simbolización son: Línea, Polígono, Punto, Texto y Ráster.
2.8 Simbolización Lineal (LineSymbolizer)
Los símbolos lineales se definen como lo muestra el esquema de la figura (D.14):
Página 152
Anexo D. Síntesis de la especificación SLD
Figura D.14. Esquema XML de la simbolización Lineal
El elemento LineSymbolizer está formado por los elementos Geometry y Stroke. Geometry
(Geometría) es opcional, todas las clases de simbolización pueden contener este elemento. Si no
se define se toma “por defecto” como geometría la definida en “FeatureStyleType”. El esquema
de Geometry se presenta en la figura (D.15):
Figura D.15. Esquema XML de Geometry
El elemento ogc: PropertyName (se define en la especificación WFS) puede tener como contenido
una definición de geometría, utilizando GML o unas propiedades de entidad.
Los tipos de geometría son:
Línea. Línea de longitud X con orientación horizontal centrada en un punto, delimitada
por dos nodos.
Polígono: Línea cerrada con relleno interior.
Ráster: línea rasterizada.
En la figura (D.16) se presenta un ejemplo de uso de este sub-elemento:
Figura D.16. Ejemplo de uso de Geometry
El elemento Stroke (Borde) es opcional. Todas las clases de simbolización pueden contener este
elemento. Si no se define entonces no se dibuja. Su esquema SLD se presenta en la figura (D.17).
Página 153
Anexo D. Síntesis de la especificación SLD
Figura D.17. Esquema XML de Stroke
Está formada por los elementos GraphicFill, Graphicstroke y cssParameter.
Los bordes pueden ser de tres tipos: Solid-color (color sólido), GraphicFill (efecto punteado) y
GraphicStroke (símbolo gráfico repetido linealmente). Si no se proporcionan GraphicFill o
GraphicStroke entonces el símbolo lineal se rellena de color sólido.
El elemento cssParameter proporciona los parámetros para describir los estilos de las líneas. La
definición de su esquema se presenta en la figura (D.18).
Figura D.18. Esquema XML de CssParameter
El elemento GraphicFill especifica la línea punteada repetida que se va a utilizar. En la figura
(D.19) se muestra el esquema XML:
Figura D.19. Esquema XML de GraphicFill
El elemento GraphicStroke especifica el símbolo gráfico repetido que se va a utilizar. En la figura
(D.20) se presenta el esquema XML de este elemento.
Página 154
Anexo D. Síntesis de la especificación SLD
Figura D.20. Esquema XML de GraphicStroke
Ejemplo: Capa con todas las entidades del tipo río que se van a mostrar con líneas azules de 2
píxeles de ancho. En la figura (D.21) se muestra una sección del documento SLD que describe la
configuración de estilo mencionada anteriormente y en la figura (D 22) se presenta el resultado al
aplicar el estilo definido en la figura (D.21).
Figura D.21. Ejemplo de LineSymbolizer
Figura D.22. Resultado al aplicar la
simbolización
LineSymbolizer
definida en la figura (D.21)
2.9 Simbolización Poligonal
Se usa para dibujar un polígono formado por un relleno interior y línea de contorno. La figura
(D.23) muestra el esquema de la simbolización poligonal.
Figura D.23. Esquema XML de PolygonSymbolizer
Primero se dibuja el relleno (fill) y después el borde (stroke) encima. PolygonSymbolizer está
formado por los elementos Geometry, Fill, Stroke.
Fill (Relleno) se define como lo muestra la figura (D.24):
Página 155
Anexo D. Síntesis de la especificación SLD
Figura D.24. Esquema XML de Fill
Existen dos tipos de relleno: color sólido y GraphicFill (patrón repetido). Por su lado,
CssParameters define parámetros referidos al relleno: Fill ( relleno) y Fill-Opacity ( nivel de
transparencia). Por defecto el valor del relleno (Fill) es gris (“#808080”).
Ejemplo: Tipo de entidad Lago que se desea representar con relleno azul claro y su borde con una
línea en azul oscuro. En la figura (D.25) se muestra las líneas XML que describen la
configuración anterior. Y en la figura (D.26) se presenta el resultado al aplicar la configuración de
estilo presentada en la figura (D.25).
Figura D.25. Ejemplo de estilización poligonal
Figura D.26. Resultado de la definición mostrada en la figura (D.25)
2.10
Simbolización Puntual
Se usa para dibujar elementos puntuales mediante símbolos. La figura (D.27) presenta la
definición de esta simbolización:
Figura D.27. Esquema XML de PointSymbolizer
Página 156
Anexo D. Síntesis de la especificación SLD
Está formada por los elementos Geometry, Graphic. Si se utiliza una geometría tipo línea,
polígono o Ráster entonces se usa el centroide de la geometría.
Graphic (Gráfico) es el símbolo (vector o Ráster) utilizado con un relleno, color y tamaño. El
símbolo puede proceder de una URL externa o se puede especificar características del mismo. Si
no se especifica ni ExternalGraphic ni Mark entonces por defecto se aplica un cuadrado de un
relleno de gris y línea de contorno de ancho 6 píxeles y color negra. El esquema XML se presenta
en la figura (D.28).
Figura D.28. Esquema XML de Graphic y ExternalGraphic
Los elementos que lo constituyen son:
ExternalGraphic (símbolo externo) hace referencia a una URL exterior donde se
encuentra el símbolo y está formado por los elementos OnlineResource, y Format.
Mark (símbolo) define el color de relleno, el color de línea de la figura elegida para la
simbolización puntual. La figura (D.29) muestra la definición de su esquema.
Página 157
Anexo D. Síntesis de la especificación SLD
Figura D.29. Esquema XML Mark
El elemento WellKnownName especifica el nombre de la forma del símbolo el cual puede
ser Square(cuadrado),circle(círculo),triangle (triángulo),star(estrella),cross(cruz) y X. Por
defecto su valor es “square”. El dibujo de estos símbolos puede ser sólido o vacío
dependiendo de los elementos Fill y Stroke.
Opacity (Opacidad) establece el grado de opacidad (igual que stroke-opacity y fillopacity).
Size (tamaño) establece el tamaño del símbolo numéricamente.
Rotation (rotación) establece la orientación del símbolo en dirección de las agujas del
reloj y codificado con un número. Por defecto el valor es 0.0.Se permiten valores
negativos.
En la figura (D.30) se presenta el documento SLD que describe lo siguiente: Simbolización de
Hospitales mediante elementos puntuales en forma de estrellas centrados en la localización de los
hospitales. La figura (D.31) muestra el resultado de la configuración de estilo anterior.
Figura D.30. Ejemplo de estilización Puntual
Figura D.31. Resultado de la definición mostrada en la figura (D.30)
Página 158
Anexo D. Síntesis de la especificación SLD
2.11
Textos
La simbolización TextSymbolizer es utilizada para definir el estilo de las etiquetas textuales. En la
figura (D.32) se muestra la definición del esquema XML.
Figura D.32. Esquema XML de TextSymbolizer
Está formada por los elementos Geometry, Label, Font, LabelPlacement, Halo y Fill. El tipo de
geometría es punto o línea y necesita el elemento LabelPlacement (localización etiqueta).El
elemento Label (etiqueta) hace referencia al contenido de la etiqueta. Se define como:
Si un elemento Label no se proporciona dentro del elemento TextSymbolizer no se dibujará y por
tanto no aparecerá.
El elemento Font (fuente) identifica la familia, estilo, y tamaño de la fuente. La figura (D.33)
muestra la definición del esquema de este elemento.
Figura D.33. Esquema XML de Font
Donde el elemento Cssparameter puede ser:
Font-family: nombre de la familia de la fuente
Font-Style: estilo de la fuente (“normal”, “italic”, “oblique”).
Font-weight: formato de la fuente (“normal”,”negrita”).
Font-size: tamaño de la fuente, por defecto es 10 píxeles.
El elemento LabelPlacement (Localización etiqueta) posiciona la etiqueta relativa a un punto o a
una línea. La definición de su esquema se presenta en la figura (D.34).
Página 159
Anexo D. Síntesis de la especificación SLD
Figura D.34. Esquema XML de LabelPlacement, PointPlacement y LinePlacement
PointPlacement (localización puntual) está formado por: AnchorPoint el cual proporciona la
localización dentro de la etiqueta para usarlo como anclaje y se define como lo muestra la figura
(D.35).
Figura D.35. Esquema XML de AnchorPoint
Donde los elementos AnchorPointX y AnchorPointY toman valores entre 0.0 (esquina inferior
izquierda) y1.0 (esquina superior derecha). Por defecto se tienen los valores de x=0, y= 0.5.
La figura (D.36) muestra las posiciones de la etiqueta con respecto a los valores que se le asignen
al elemento AnchorPoint.
Figura D.36. Valores que puede tomar AnchorPoint
Algunos ejemplos de uso de la ubicación puntual se muestran en la tabla (D.1).
Página 160
Anexo D. Síntesis de la especificación SLD
Tabla D.1. Ejemplos de ubicaciones puntuales
(x=0, y=0.5) DEFAULT – la etiqueta se localiza a
la derecha del punto
(x=0.5, y=0.5) – el centro de la etiqueta se localiza
sobre el punto
(x=1, y=0.5) – la etiqueta se localiza a la izquierda
del punto
(x=0.5, y=0) – la etiqueta se localiza centrada encima
del punto
Displacement proporciona el desplazamiento X, Y del texto con respecto al elemento puntual al
que da nombre (ver tabla D.2). Rotation: proporciona los grados de rotación de la etiqueta en
grados (ver tabla D.3).
Tabla D.2. Ejemplos de desplazamientos
Desplazamiento de 10 pixeles es similar a la
ubicación puntual (x = 0, y = 0,5)
Desplazamiento de y = -10 pixeles es similar a la
ubicación puntual (x=0.5, y=1.0)
Tabla D.3. Ejemplos de rotación
45 grados de rotación simple
45 grados de rotación con ubicación puntual de
(x=0.5, y=0.5)
45 grados de rotación con 40 pixeles de
desplazamiento en X
45 grados de rotación con ubicación puntual de
(x=0.5,y=0.5) y 40 pixeles de desplazamiento en Y
Página 161
Anexo D. Síntesis de la especificación SLD
LinePlacement (localización lineal) está formado por PerpendicularOffset que permite
proporcionar la distancia perpendicular a la línea sobre la que se localizará el texto (ver tabla D.4).
La distancia se establece en pixeles, los cuales pueden ser positivos (sitúa el texto a la derecha o
arriba de la línea) y negativos (sitúa el texto a la izquierda o abajo de la línea). Por defecto se toma
el valor de 0.
Tabla D.4. Ejemplos de localización lineal
PerpendicularOffset=0
PerpendicularOffset=10
El elemento Halo (halo) define el tipo de relleno que se aplica al fondo de la fuente. Se define
como se muestra en la figura (D.37):
Figura D.37. Esquema XML de Halo
Donde Radius define el tamaño absoluto en píxeles del radio de halo, por defecto es 1 pixel y Fill
que por defecto es blanco. Fill (relleno), por defecto el relleno de las letras es negro sólido
(“#000000”).
En la figura (D.38) se presenta el ejemplo de la descripción de una configuración textual aplicada
a un mapa. El resultado de esta configuración se puede apreciar en la figura (D.38).
Página 162
Anexo D. Síntesis de la especificación SLD
Figura D.38. Ejemplo de simbolización Texto
Figura D.39. Resultado de la definición mostrada en la figura (D.38)
Página 163
Anexo D. Síntesis de la especificación SLD
Página 164
ANEXO E
Plan de Pruebas
Anexo E. Plan de pruebas
1. Introducción
El presente documento expone el plan de pruebas basado en el estándar 829 de la IEEE
utilizado para pruebas de software. Este plan permite evaluar el sistema MapWeb Designer.
[IEEE 1998].
El sistema a probar es una herramienta creadora de prototipos de aplicaciones Web que
contienen mapas estilizados por el usuario (diseñador).
Los módulos que se desarrollaron son:
Gestión de acceso al sistema.
Solicitud y visualización de mapas.
Aplicación de estilos al mapa.
Generación de plantilla de aplicación Web con la asociación del mapa estilizado.
Publicación del prototipo de aplicación Web.
Visualización del prototipo de aplicación Web publicado.
La hipótesis nula a probar es la siguiente:
Con herramientas editoras y visualizadoras de mapas vectoriales, no es posible
publicar aplicaciones Web y aplicar estilos a los mapas definidos por el usuario a
través de la Web.
La hipótesis alterna es:
Con una herramienta Web es posible visualizar y estilizar mapas vectoriales aplicando
estilos definidos por el usuario (diseñador). Además es posible publicar un prototipo
de aplicación Web con el mapa estilizado.
El presente documento se encuentra organizado de la siguiente manera:
Identificador del plan de pruebas: describe la forma en que se identificaron las pruebas.
Descripción del plan de pruebas: se hace una descripción general de las características
que se probaron; se definen los criterios necesarios para aprobar, suspender o reanudar
una prueba; se mencionan las tareas necesarias y las condiciones ambientales para
aplicar las pruebas.
Casos de prueba: expone los grupos y subgrupos de los casos prueba.
Procedimiento de pruebas: describe los pasos realizados para ejecutar las pruebas.
2. Identificador del plan de pruebas
MAPWEBDE-XX.YY
SIGLAS
MAP
WEB
DE
XX
YY
SIGNIFICADO
Mapas
Web
Designer
Grupo de prueba
Caso de prueba
MapWeb Designer: Diseñador de mapas en Web.
Página 166
Anexo E. Plan de pruebas
3. Descripción del Plan de Pruebas
3.1.
Elementos de prueba
Los módulos del sistema MapWeb Designer que fueron probados se identifican como lo
muestra la tabla E.1.
TIPO
Módulo
Módulo
Módulo
Módulo
Módulo
Módulo
3.2.
Tabla E.1. Elementos de prueba
NOMBRE
MAPWEBDE-01 Gestión de acceso al sistema.
MAPWEBDE-02 Solicitud y visualización de mapas.
MAPWEBDE-03 Aplicación de estilos al mapa.
MAPWEBDE-04 Asociar mapa a plantilla de aplicación Web
MAPWEBDE-05 Publicación de la página Web.
MAPWEBDE-06 Visualización de la página Web.
Características probadas
La siguiente lista describe las características que fueron probadas en cada módulo mencionado
en los elementos de prueba:
Gestión de acceso al sistema: se verificó que se realizara correctamente el registro de
usuarios del sistema así como el acceso y denegación al mismo.
Solicitud y visualización de mapas: se verificó que las solicitudes de mapas fueran
correctas y que se visualizaran los mapas solicitados en el visor de mapas de la
aplicación.
Aplicación de estilos al mapa: se probó que la configuración de estilos definidos por el
usuario y la generación del código XML correspondiente a la estilización del mapa
fueran realizados correctamente.
Asociar mapa a plantilla de aplicación Web: se verificó que la plantilla Web elegida
del catálogo de plantillas, fuera creada conteniendo el mapa estilizado
Publicación de la aplicación Web: se probó que los archivos necesarios para la
ejecución de la aplicación en la Web fueran copiados en el contenedor Web.
Visualización de la aplicación Web: se verificó la correcta ejecución y visualización de
la aplicación Web publicada.
3.3.
Características excluidas de las pruebas
El presente plan de pruebas no abarca los siguientes aspectos:
No se realizaron pruebas al hardware en que se ejecutó el sistema.
No se realizaron pruebas de velocidad de carga de mapas y rendimiento del sistema
MapWeb Designer.
No se examinaron compatibilidades y configuración del software a desarrollar.
3.4.
Enfoque
Las pruebas que se le efectuaron al sistema MapWeb Designer fueron de funcionalidad.
MapWeb Designer interactua con un servidor de mapas (WMS por sus siglas en inglés) el cual
tiene el papel de proveedor de mapas vectoriales. Además resuelve las necesidades de estilo
Página 167
Anexo E. Plan de pruebas
que el diseñador configura por medio de componentes de estilo disponibles y tiene la
funcionalidad de publicar el mapa en la Web. Las pruebas se realizaron invocando la
aplicación MapWeb Designer desde un navegador Web
3.5.
Criterio pasa/no pasa de los elementos
En la descripción de cada uno de los casos de prueba contenidos en el presente documento, se
detallan los resultados esperados del caso de prueba. Se consideró que una prueba pasaba con
éxito cuando los resultados esperados coincidieron con los descritos en el caso de prueba.
Cuando no se pasaba la prueba, el responsable de la prueba analizó el problema y realizó las
modificaciones necesarias hasta que se cumplieran los resultados esperados.
3.6.
Criterios de suspensión y requerimientos de reanudación
En ningún caso de prueba descrito en el presente documento se establecieron criterios para
suspender las pruebas. Todos los casos de prueba fueron llevados a cabo y cuando se
encontraron errores, se solucionaron hasta obtener los resultados esperados descritos en cada
caso de prueba.
3.7.
Tareas de prueba
Las tareas a desarrolladas para aplicar las pruebas se describen en la tabla E.2:
TAREA
1.
Realizar el plan
de pruebas.
2.
Realizar las
pruebas.
3.
Resolver los
incidentes
resultantes de
las pruebas.
4.
Evaluar los
resultados.
3.8.
Tabla E.2. Descripción de las tareas de prueba
TAREA PRECEDENTE
HABILIDADES ESPECIALES
Análisis y diseño de la
Conocer el estándar 829 de la IEEE y
herramienta MapWeb
las funciones que realizará MapWeb
Designer.
Designer.
Tarea 1 e
Conocer la arquitectura de MapWeb
implementación de la
Designer, los casos de uso, las clases
herramienta MapWeb
y métodos desarrollados.
Designer.
Conocimiento de J2EE,
XML,
JavaScript, Ajax, funciones del API
Tarea 2
visora de mapas y
las
especificaciones SLD y WMS de la
OGC.
Conocer el objetivo de la tesis,
Tarea 3
alcances, limitaciones e hipótesis de
prueba de la investigación.
RESPONSABILIDADES
Autora de esta tesis.
Autora de esta tesis.
Autora de esta tesis.
Autora de esta tesis.
Necesidades ambientales
Los requisitos necesarios tanto de hardware como de software que cumplieron los equipos
cliente y servidor para llevar a cabo la correcta ejecución de pruebas se describen en la tabla
E.3.
Nota: las características que se presentan para el equipo servidor son regulares ya que si se
desea almacenar grandes cantidades de información espacial, se tiene que aumentar las
capacidades en disco duro, memoria RAM y procesador.
Página 168
Anexo E. Plan de pruebas
REQUISITO
PC(Equipo servidor)
PC(Equipo cliente)
3.9.
Tabla E.3. Requisitos ambientales
CARACTERÍSTICAS
Procesador Pentium 4 o superior.
1 GB de memoria RAM o superior.
80 GB en disco duro.
Windows XP/ Windows Vista/Linux.
Navegador web Mozilla.
Contenedor Web Apache Tomcat 5.5
Servidor de mapas (WMS) elegido en la fase de análisis de servidores.
Mapas vectoriales de servicios municipales y carreteros.
NetBeans 6.0 como entorno de programación.
Macromedia Dreamweaver para el diseño de plantillas Web.
JDK 1.5.
PostgreSQL utilizado como manejador de base de datos.
Procesador opcional.
512 de memoria RAM superior.
Espacio en disco duro opcional.
Sistema operativo opcional.
Cualquier navegador Web (se recomienda utilizar Mozilla).
Máquina virtual de Java.
Liberación de pruebas
Las pruebas fueron liberadas una vez que se obtuvieron los resultados esperados en cada caso
de prueba.
3.10. Responsabilidades
La autora de esta tesis tuvo la responsabilidad de efectuar todas las pruebas que se
especificaron.
3.11. Riesgos y contingencias
El tiempo fue factor importante para que todas las pruebas se efectuaran de manera correcta.
Cuando se extendió el tiempo destinado a las pruebas del software, se continuó hasta que el
sistema quedara libre de errores.
Cuando se presentaron errores en el sistema que no se consideraron en el presente documento,
fueron resueltos por el responsable de las pruebas.
4. Casos de prueba
4.1.
Pruebas a realizar
La tabla E.4 expone los casos de prueba de cada uno de los elementos de prueba mencionados
anteriormente.
Cada caso de prueba está identificado por el número asignado al elemento de prueba seguido
de un número consecutivo:
Página 169
Anexo E. Plan de pruebas
Tabla E.4. Casos de prueba
IDENTIFICADOR
NOMBRE
MAPWEBDE-01
Gestión de acceso al sistema.
MAPWEBDE-01.01 Registro de usuarios.
MAPWEBDE-01.02 Autentificación al sistema.
MAPWEBDE-01.03 Rechazo al inicio de sesión.
MAPWEBDE-01.04 Acceso al sistema.
MAPWEBDE-02
Solicitud y visualización de mapas.
MAPWEBDE-03
Aplicación de estilos al mapa.
MAPWEBDE-03.01 Estilizar líneas
MAPWEBDE-03.02 Estilizar polígonos.
MAPWEBDE-03.03 Estilizar puntos.
MAPWEBDE-03.04 Estilizar texto.
MAPWEBDE-03.05 Generación de código XML.
MAPWEBDE-04
Asociar mapa a plantilla de aplicación Web.
MAPWEBDE-05
Publicación de la página Web.
MAPWEBDE-06
Visualización de la página Web.
5. Procedimiento de pruebas
En esta sección se presenta la descripción de cada caso de prueba. Para cada uno de los casos
de prueba se describe el propósito del caso de prueba, el entorno necesario para la ejecución
de la prueba, el procedimiento que se llevó a cabo para efectuar la prueba y los resultados que
se esperaron.
5.1.
MAPWEBDE-01 Gestión de acceso al sistema
Propósito
Verificar que los usuarios se registren e ingresen satisfactoriamente al sistema. En el
caso de usuarios no registrados o de introducir incorrectamente el nombre de usuario
(login) o el password, el sistema rechazará el acceso al mismo.
Entorno
Para la ejecución de los casos de prueba contenidos en este grupo se utilizarán los
siguientes elementos:
Equipo servidor en el que estará almacenada la aplicación MapWeb Designer y
la base de datos.
Equipo cliente el cual ejecutará la aplicación Web MapWeb Designer desde un
navegador Web.
Nombre de usuario (login).
Contraseña.
Datos del usuario (en caso del registro de usuarios).
Resultado esperado
El usuario se registrará en la base de datos y se le proporcionará el ingreso o rechazo al
sistema.
Página 170
Anexo E. Plan de pruebas
5.2.
MAPWEBDE-01.01 Registro de usuarios
Propósito
Verificar que el usuario registre sus datos en el sistema satisfactoriamente.
Entorno
El usuario debe de tener ejecutando la página de registro de usuarios.
Proceso
1. Ingresar datos personales (nombre, apellido paterno, apellido materno,
organización, país, correo electrónico, confirmar correo, nombre de usuario,
contraseña, confirmar contraseña y seleccionar estar de acuerdo con los
términos y condiciones de la herramienta).
2. Pulsar botón “Registrar Usuario”.
Resultado esperado
El usuario debe de estar registrado en el sistema y podrá iniciar sesión con el nombre
de usuario y contraseña proporcionados en el registro. En caso de que el usuario a
registrarse ingrese un login que se encuentre almacenado en la base de datos, el sistema
deberá notificar el error.
5.3.
MAPWEBDE-01.02 Autentificación al sistema
Propósito
Verificar que el usuario ingrese al sistema satisfactoriamente.
Entorno
El usuario debe de estar registrado previamente en el sistema, es decir, éste ya posee un
nombre de usuario y contraseña válidos que le permitirán ingresar al sistema.
Proceso
1. Ingresar el nombre de usuario (login).
2. Ingresar contraseña.
3. Pulsar el botón “iniciar sesión”.
Resultado esperado
Si el usuario ingresó correctamente los datos deberá ver la interfaz del sistema
MapWeb Designer.
5.4.
MAPWEBDE-01.03 Rechazo al inicio de sesión
Propósito
Verificar que los usuarios no registrados tengan acceso denegado al sistema. Los
usuarios registrados que ingresen datos de login y contraseña incorrectos deberán ser
rechazados al inicio de la sesión en el sistema.
Página 171
Anexo E. Plan de pruebas
Entorno
El usuario debe de ingresar el login y contraseña en la página correspondiente al inicio
de sesión.
Proceso
1. Ingresar el nombre de usuario (login).
2. Ingresar contraseña.
3. Pulsar el botón “iniciar sesión”.
Resultado esperado
Si el usuario aún no está registrado e ingresa datos de login y contraseña, el sistema
deberá rechazar el ingreso. En caso de que un usuario registrado ingrese login o
contraseña incorrectos el sistema también rechazará su acceso.
5.5.
MAPWEBDE-01.04 Acceso al sistema
Propósito
Verificar que los usuarios registrados que ingresan login y contraseña correctos tengan
acceso al sistema.
Entorno
El usuario registrado debe de ingresar el login y contraseña correctos en la página
correspondiente al inicio de sesión.
Proceso
1. Ingresar el nombre de usuario correctamente (login).
2. Ingresar contraseña correcta.
3. Pulsar el botón “iniciar sesión”.
Resultado esperado
El usuario deberá visualizar la interfaz del sistema.
5.6.
MAPWEBDE-02 Solicitud y visualización de mapas
Propósito
Verificar que las peticiones de mapas solicitados sean visualizadas en un visor de
mapas dentro del sistema MapWeb Designer.
Entorno
El usuario deberá estar autentificado en el sistema y se requiere de los siguientes
elementos:
Equipo Servidor de mapas (WMS)
Aplicación MapWeb Designer corriendo en una máquina cliente.
Datos de solicitud del mapa
Página 172
Anexo E. Plan de pruebas
Proceso
1.
2.
3.
4.
5.
Ingresar al sistema.
Elegir Nuevo Proyecto.
Seleccionar el mapa a visualizar.
Enviar solicitud a WMS.
Esperar la respuesta del WMS.
Resultado esperado
El mapa solicitado se visualizará en el visor de mapas de la aplicación.
5.7.
MAPWEBDE-03 Aplicación de estilos al mapa
Propósito
Verificar que los estilos aplicados al mapa se vean reflejados en el visor de mapas.
Entorno
El usuario debe estar autentificado en el sistema y haber visualizado en el visor de
mapas de la aplicación un mapa solicitado al WMS.
Resultado esperado
Se visualizarán los cambios de estilos sobre el mapa y se generará un archivo XML el
cual contendrá la estilización del mapa.
5.8.
MAPWEBDE-03.01 Estilizar líneas
Propósito
Verificar que el tipo de línea, color, ancho y transparencia configurados sean aplicados
correctamente a las líneas del mapa visualizado.
Entorno
El usuario debe estar autentificado en el sistema y haber visualizado el mapa solicitado
en el visor de mapas de la aplicación.
Proceso
1. Elegir tipo de geometría línea. Para indicar que se van a estilizar las líneas del
mapa.
2. Configurar las opciones de estilo según las necesidades del usuario.
3. Aplicar el estilo al mapa visualizado.
Resultado esperado
Los objetos tipo línea mostradas en el mapa deben de cambiar de color, tipo de línea y
grosor de acuerdo a la configuración realizada por el usuario.
Página 173
Anexo E. Plan de pruebas
5.9.
MAPWEBDE-03.02 Estilizar polígonos
Propósito
Verificar que las líneas y el relleno de polígonos visualizados en el mapa, cambien de
estilo de acuerdo a configuración de estilo proporcionada por el usuario.
Entorno
El usuario debe de haberse autentificado en el sistema y haber visualizado el mapa
solicitado sobre el visor de mapas de la aplicación.
Proceso
1. Elegir tipo de geometría polígono para indicar que se van a estilizar los
polígonos del mapa.
2. Configurar las opciones de estilo según las necesidades del usuario.
3. Aplicar el estilo al mapa visualizado.
Resultado esperado
Los objetos tipo polígono mostrados en el mapa deben de cambiar de apariencia de
acuerdo a la configuración realizada por el usuario.
5.10. MAPWEBDE-03.03 Estilizar puntos
Propósito
Verificar que los puntos mostrados en el mapa, cambien de estilo de acuerdo a la
configuración proporcionada por el usuario.
Entorno
El usuario debe estar autentificado en el sistema y haber visualizado el mapa solicitado
en el visor de mapas de la aplicación.
Proceso
1. Elegir tipo de geometría punto para indicar que se van a estilizar los puntos del
mapa.
2. Configurar las opciones de estilo según las necesidades del usuario.
3. Aplicar el estilo al mapa visualizado.
Resultado esperado
Los objetos tipo punto mostrados en el mapa deben de cambiar de apariencia de
acuerdo a la configuración realizada por el usuario.
5.11. MAPWEBDE-03.04 Estilizar texto
Propósito
Verificar que el texto asociado al mapa, cambie de estilo de acuerdo a la configuración
proporcionada por el usuario.
Página 174
Anexo E. Plan de pruebas
Entorno
El usuario debe estar autentificado en el sistema y haber visualizado el mapa solicitado
en el visor de mapas de la aplicación.
Proceso
1. Elegir tipo de geometría texto para indicar que se van a asignar propiedades de
estilo a texto relacionado con el mapa.
2. Dar clic sobre cualquier objeto del mapa para obtener los nombres de las
etiquetas asociadas al mapa.
3. Configurar las opciones de estilo según las necesidades del usuario.
4. Aplicar el estilo al mapa visualizado.
Resultado esperado
Los objetos tipo texto mostrados en el mapa deben de cambiar de apariencia de
acuerdo a la configuración realizada por el usuario.
5.12. MAPWEBDE-03.05 Generación de código XML
Propósito
Verificar que se genere correctamente el código XML correspondiente a los estilos
aplicados sobre el mapa visualizado en el visor de mapas.
Entorno
El usuario debe haberse autentificado en el sistema, haber visualizado el mapa
solicitado y estar en el proceso de estilización del mapa.
Proceso
1. Realizar un cambio de estilo en el mapa.
Resultado esperado
Cada vez que se realice un cambio de estilo sobre el mapa visualizado en la aplicación,
se deberá generar el código XML correspondiente al estilo aplicado.
5.13. MAPWEBDE-04 Asociar mapa a plantilla de página Web
Propósito
Verificar que el mapa estilizado sea asociado a una plantilla de página Web elegida por
el usuario.
Entorno
El usuario debe de haberse autentificado en el sistema, haber visualizado y estilizado el
mapa solicitado y finalmente haber seleccionado una plantilla de página Web.
Proceso
1. Terminar de estilizar el mapa.
2. Seleccionar “Asociar mapa a plantilla de página Web”.
Página 175
Anexo E. Plan de pruebas
3. Del catálogo de plantillas Web elegir la que se desee.
4. Pulsar Asociar mapa y publicar página Web
Resultado esperado
La plantilla elegida deberá contener el mapa estilizado por el usuario.
5.14. MAPWEBDE -05 Publicación de la página Web
Propósito
Verificar que la publicación de la página Web se efectúe de manera correcta.
Entorno
El usuario debe de estar autentificado en el sistema, haber terminado de diseñar la
aplicación Web y haber elegido una plantilla de página Web.
Proceso
1.
2.
3.
4.
5.
6.
Ingresar al sistema.
Solicitar un mapa.
Estilizar el mapa.
Seleccionar “Asociar mapa a plantilla general”.
Del catálogo de plantillas predefinidas elegir una de ellas.
Seleccionar “Asociar mapa y publicar página Web”.
Resultado esperado
Los archivos necesarios para la publicación del mapa deberán ser copiados a la carpeta
Web del usuario de manera satisfactoria.
5.15. MAPWEBDE-06 Visualización de la página Web
Propósito
Verificar que la página Web publicada se ejecute y visualice en el navegador de forma
correcta.
Entorno
El usuario debe de estar autentificado en el sistema, haber terminado de diseñar y
publicar la página Web.
Proceso
1. Ingresar al sistema.
2. Elegir la opción de abrir proyecto.
3. Seleccionar ver publicación del mapa que se desee visualizar.
Resultado esperado
Deberá visualizarse en el navegador la aplicación Web con el mapa estilizado.
Página 176
Referencias
REFERENCIAS
[ADSENSE, 2008]
Google AdSense. Información acerca de AdSense. [En línea]
https://www.google.com/adsense/login/es/?hl=es&gsessionid=CUFlUhiS
L9-aVYqx3weFrg. Consultado en Diciembre 2008
[ARMSTRONG, 2007]
Armstrong Eric, et al, 2007. The J2EE 1.4 Tutorial. Página 44. Sun Java
System Application Server Platform Edition 8.2. [En línea]
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/J2EETutorial.pdf.
Consultado en Octubre 2008.
[BRISABOA, 2007]
Brisaboa Nieves R., et al , sf. Definición e implementación de un servicio
Web de mapas activos. Universidad de Coruña.
[CARMONA, 2007]
Carmona Álvaro, Monsalve Jhon. Sistemas de Información Geográficos.
[En línea] http://www.monografias.com/trabajos/gis/gis.shtml. Consultado
en Marzo de 2007
[CLICK2MAP 2008]
Click2Map, 2008. Click2Map, a new way to build your Google Maps. [En
línea] http://www.click2map.com/. Consultado en Agosto 2008.
[CRANE, 2006]
Crane Dave, Pascarello Eric with Darren James. Ajax in action
MANNING. Greenwich. 2006 Págs. 4, 17-27, 32.
[CSGRIP, 2008]
Consejo Superior Geográfico, 2008.Infraestructura de Datos Espaciales
de
España.
Rincón
del
Programador.
[En
línea]
http://www.idee.es/show.do?to=pideep_ejemplosOGC.ES. Consultado en
Febrero 2008.
[CSGWMS, 2008]
Consejo Superior Geográfico, Infraestructura de Datos Espaciales de
España,
2008.
Web
Map
Service
1.3.0.
[En
línea]
http://www.idee.es/show.do?to=pidee_programador_wms.ES.
Consultado en Febrero 2008.
[DATACROSSING, 2007]
DataCrossing, 2007. msCross: AJAX (WEB 2.0) WEB GIS Client. [En
línea]
http://datacrossing.crs4.it/en_Documentation_mscross.html.
Consultado el 9 de Abril de 2008.
[DEGREE, 2008]
Degree, 2008. Some bits of history first. [En línea]
http://deegree.sourceforge.net/inf/about.html. Consultado en Marzo 2008.
[DESIGE, 2008]
Département des Sciences Géomatiques. Qu'est-ce que la géomatique. [En
línea] http://www.scg.ulaval.ca/page.php?nom=geomatique. Consultado
en Diciembre 2008
[DIGECA, 2008]
Dirección General del Catastro, 2008. Servicio WMS de Ponencias de
valores. [En línea] http://www.catastro.meh.es/pdf/wms_ponencias.pdf.
Consultado en Febrero 2008.
[EDNEW, 2009].
Educación
Newton.
Sistema
de
referencia.
[En
línea]
http://newton.cnice.mec.es/escenas/cinematica/sist_ref.php. Consultado en
Enero 2009.
Página 177
Referencias
[EGUILUZ, 2008]
Eguíluz Pérez Javier, 2008. Introducción a JavaScript. [En línea]
http://www.librosweb.es/javascript/pdf/introduccion_javascript.pdf.
Consultado en Octubre 2008.
[ESRI, 2008]
Sitio oficial ESRI. ESRI GIS and Mapping Software. [En línea],
http://www.esri.com/. Consultado en Noviembre de 2008
[FERNANDEZ, 2004]
Fernández Hernán Darío, 2004. Introducción al Framework Web de
Jakarta Struts con WSAD 5.1, Colombia.
[GEORSS, 2007]
Sitio oficial GeoRSS. Geographycally Encoded Objects for RSS feeds,
[En línea] http://www.georss.org/1#intro. Consultado en Octubre 2007.
[GEOSERVER, 2008]
Página oficial de Geoserver, 2008. Geoserver Home, What is Geoserver.
[En
línea]
http://geoserver.org/display/GEOS/GeoServer+Home.
Consultado en Marzo 2008.
[GEOSERVERFEA, 2008]
Página oficial de Geoserver, 2008. Features, Geoserver Features. [En
línea] http://geoserver.org/display/GEOS/Features. Consultado en Marzo
2008.
[GOOGLEMAPS, 2007]
Google Maps, 2007. Sitio oficial de Google Maps.[En línea]
http://www.google.com/apis/maps/. Consultado en 18 de Abril de 2007
[GUTIERREZ, 2000]
Gutiérrez Rodríguez Abraham; Martínez González Raúl. XML a través de
ejemplos. Alfaomega Ra-Ma
[HONCEVAR, 2007]
Honcevar, Andreas, 2007. About Mapbuilder. [En
http://communitymapbuilder.org/. Consultado en abril de 2008
[IEEE, 1998]
IEEE,1998. Software Engineering Technical Committee of the IEEE
Computer Society. IEEE Standard for Software Test Documentation. [En
línea]
http://www.ucsc.cl/~marciam/weblog/images/ieeestd8291998standardtest_documentation.pdf. Consultado en Octubre 2007
[LATLON, 2008]
Lat/lon, Universidad de Bonn, 2008. Degree Web Map Service v.2.1,
Departamento de Geografía de la Universidad de Bonn.
[LBSPRO, 2007]
LBSPRO, 2007. Sistema de información geográfico. [En línea]
http://wiki.lbspro.com/index.php?title=Sistema_de_Informaci%C3%B3n_
Geogr%C3%A1fico. Consultado el 9 de marzo de 2007.
[LEARNER, 2003]
"Cartography." World of Earth Science. Eds. K. Lee Lerner and Brenda
Wilmoth Lerner. Vol. 1. Detroit: Gale, 2003. Págs. 95-96.
[LEWOTSKY, 2004]
Lewotsky, Karen. "Cartography." Gale Encyclopedia of Science. Eds. K.
Lee Lerner and Brenda Lerner. Vol. 1. 3rd ed. Detroit: Gale, 2004. Págs.
742-748.
[LOPEZ, 2006]
López Romero Emilio, F. Rodríguez Antonio, 2006. IDEE.
Recomendaciones para la creación y configuración de servicios de
mapas. Consejo Superior Geográfico. Pág. 7.
[MAP24 2008]
Map24, 2008. Map24 México. [En línea] http://www.mx.map24.com/.
Consultado en Agosto 2008.
línea]
Página 178
Referencias
[MAPBUILDER, 2007]
Mapbuilder,
2007.
Sitio
Oficial
MapBuilder.[En
línea]
http://www.mapbuilder.net/index.php. Consultado en Noviembre 2007.
[MAPBUILDER, 2008]
MapBuilder,
2008.
MapBuilder
User
Guide.
[En
línea]
http://geodiscover.cgdi.ca/mapbuilder/userGuide?page=intro. Consultado
en abril de 2008.
[MAPSERVER, 2008]
Página Oficial de MapServer, 2008. Welcome to MapServer, Features.
[En línea] http://mapserver.gis.umn.edu/. Consultado en Marzo 2008.
[MAPTOOLS, 2007]
MapTools.org, 2007. Ka-Map. [En línea] http://ka-map.maptools.org/.
Consultado en abril 2008.
[MONTESINOS, 2007]
Montesinos Lajara Miguel, Sanz Salinas Jorge Gaspar, Panorama actual
del ecosistema de software libre para SIG. [En línea]
http://www.sigte.udg.es/jornadassiglibre2007/comun/1pdf/12.pdf.
Consultado en Diciembre 2007.
[OGC, 2008]
Open Geospatial Consortium, 2008. Sitio Oficial de la OGC,About
OGC.[En línea] http://www.opengeospatial.org/ogc. Consultado en
Agosto, 2008.
[OGCGML, 2007]
Open Geospatial Consortium Inc., 2007. OpenGIS Geography Markup
Language (GML) Encoding Specification. Version 3.2.1, Clemens Portele.
[OGCSLD, 2002]
Open Geospatial Consortium Inc., 2002. Styled Layer Descriptor
Implementation Specification. Version 1.0.0, William Lalonde.
[OGCWFS, 2002]
Open Geospatial Consortium Inc., 2002. Web Feature Service
Implementation Specification. Version 1.1.1, Panagiotis A. Vretanos.
[OGCWMS, 2002]
Open Geospatial Consortium Inc., 2002. OpenGIS Web Map Server
Implementation Specification. Version 1.1.1, Jeff de la Beaujardiere.
[OPENLAYERS, 2008]
OpenLayers, 2008. About . [En línea] http://www.openlayers.org/.
Consultado en Abril de 2008.
[POKML, 2008]
Página Oficial de Google, 2008. Acerca de KML. [En línea]
http://earth.google.es/userguide/v4/ug_kml.html.
Consultado
en
Diciembre 2008.
[RFC4180, 2005]
Y. Shafranovich. Common Format and MIME Type for Comma-Separated
Values (CSV) Files, Octubre de 2005
[SARRIA, 2007]
Sarría Francisco Alonso,2007. Sistemas de Información Geográfica. [En
línea] http://www.um.es/geograf/sigmur/sigpdf/temario.pdf. Consultado
en marzo 2007.
[SOMMERVILLE 2005]
Sommerville Ian, Ingeniería del Software. Pearson Addison Wesley,
séptima edición, 2005.
[VON, 2005]
Von Braun, Margrit, and Deena Lilya. "GIS (Geographic Information
System)." Pollution A to Z. Ed. Richard M. Stapleton. Vol. 1. New York:
Macmillan Reference USA, 2004. 222-224. 2 vols. Gale Virtual
Reference Library. Thomson Gale. Dir. de Institutos Tecnológicos. 14
Aug. 2007
Página 179
Referencias
[WIKIAPI, 2007]
Wikipedia. Application Programming Interface. [En
http://es.wikipedia.org/wiki/API. Consultado en Abril de 2007
línea],
[WIKIGMAPS, 2007]
Wikipedia,
2007.
Google
maps.
[En
línea],
http://es.wikipedia.org/wiki/Google_Maps. Consultado en 18 de Abril de
2007
[WIKIMASH, 2009]
Wikipedia.
Definición
de
Mashup.
[En
línea],
http://es.wikipedia.org/wiki/Mashup_(aplicaci%C3%B3n_web_h%C3%A
Dbrida). Consultado en 20 de enero de 2009.
[WIKIMATH, 2009]
Wikipedia.
Definición
de
MathML.
[En
línea],
http://es.wikipedia.org/wiki/MathML. Consultado en 20 de enero de 2009.
[WIKISHP, 2008]
Wikipedia.
Definición
de
ShapeFile.
[En
línea].
http://es.wikipedia.org/wiki/Shapefile. Consultado en Noviembre de 2008
[WIKIWIDG, 2009]
Wikipedia.
Definición
de
widget.
[En
línea].
http://es.wikipedia.org/wiki/Artilugio. Consultado en Enero de 2009.
[WMSJALI, 2008]
Brent Pedersen, 2008 .WMS JavaScript Library. [En línea] http://wmsmap.sourceforge.net/. Consultado en febrero de 2008.
[W3CSGML, 2009]
World Wide Web Consortium. Overview of SGML resources. [En línea]
http://www.w3.org/MarkUp/SGML/. Consultado en Enero 2009.
[YAHOOMAPS, 2007]
Yahoo Maps, 2007. Sitio official de Yahoo Maps. [En línea]
http://espanol.maps.yahoo.com. Consultado en Abril 2007.
[ZOOM IN 2007]
ZOOMIN, 2007. El mejor camino para explorar Australia.[En línea]
http://zoomin.com.au/. Consultado en Noviembre 2007.
Página 180

Top subcategories

Top subcategories

Top subcategories

Top subcategories

Top subcategories

Top subcategories

Top subcategories

Download Capítulo 1. Introducción