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

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 2007-

2009. 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.

~ i ~

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

~ ii ~

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

~ iii ~

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

~ iv ~

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

~ v ~

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

~ vi ~

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

~ vii ~

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.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


~ viii ~

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

~ ix ~

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

~ x ~

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].

~ xi ~

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 Un sistema de referencia es un conjunto de coordenadas espacio-tiempo que

Referencia 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].

~ xii ~

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]

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

Página 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

1.8.2. Map24

Es un buscador de direcciones disponible en la Web de manera gratuita [MAP24, 2008].


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 11

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].


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 12

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 13

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 14

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 15

Tabla 1.1. Comparativa de las aplicaciones Web estudiadas con la propuesta.

Aplicaciones Web

Visualización de mapas

Estilización de PUNTOS del

mapa basado en XML

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

Click2Map Sí

No, sólo permite la

personalización de POIs

insertados sobre el mapa

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

Map24 Sí No No No No No

ZoomIn Sí No No No No No

Map Builder Sí No No No No Sí

Google Maps Sí

No, utiliza KML para describir

los POIS insertados

No No No Sí

Yahoo Maps Sí No No No No Sí

Live Search Maps

Sí

No, únicamente inserta puntos de interés y los exporta a KML

No, sólo dibuja líneas sobre el

mapa y los exporta a KML

No, sólo dibuja polígonos sobre

el mapa y los exporta a KML

No No

MapWeb Designer (TESIS)

Sí Sí Sí Sí Sí 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 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

Página 18

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 19

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 20

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 21

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 22

/ 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 23

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 24

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 25

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


Parámetro de solicitud Obligatoriedad Descripción

VERSION=versión Opcional Versión de la especificación OGC.

SERVICE=WMS Obligatorio Tipo de servicio al que va dirigida la petición.


Página 26

REQUEST=GetCapabilities Obligatorio Nombre de la operación.

UPDATESEQUENCE=string Opcional

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/IDEE-

Base?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


Parámetro de solicitud Obligatoriedad Descripción

VERSION Obligatorio Versión de la especificación OGC.

REQUEST=GetMap Obligatorio Nombre de la petición.

LAYERS=lista de capas Obligatorio Lista de una o más capas, separadas por comas.

STYLES=lista de estilos Obligatorio Estilo de visualización por capa requerida, separados por comas.

SRS=namespace:identificador Obligatorio Sistema de Referencia Espacial.

http://www.idee.es/wms/IDEE-Base/IDEE-Base?VERSION=1.1.0&REQUEST=GetCapabilities&SERVICE=WMS

http://www.idee.es/wms/IDEE-Base/IDEE-Base?VERSION=1.1.0&REQUEST=GetCapabilities&SERVICE=WMS


Página 27

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/IDEE-

Base?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

BBOX=minx,miny,maxx,maxy Obligatorio 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.

TRANSPARENT=TRUE|FALSE Opcional Transparencia del fondo del mapa (default=FALSE).

BGCOLOR=color_value Opcional Valor del color de fondo RGB en Hexadecimal (default=0xFFFFFF).

EXCEPTOPNS=exceptions_format Opcional Formato en el que el WMS informa de las 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.

SLD_BODY=sld codificado Opcional Estilo definido por el usuario codificado de manera que pueda enviarse por la URL.

WFS=url del wfs Opcional URL del Web Feature Service para proporcionar características de simbolización mediante SLD.

http://www.idee.es/wms/IDEE-Base/IDEE-Base?VERSION=1.1.0&REQUEST=GetMap&LAYERS=Relieve,Hidrografia,transporte&STYLES=default&SRS=EPSG:4230&BBox=-3.4650655,40.4137,3.62939155,44.13107&WIDTH=1000&HEIGHT=1000&FORMAT=image/jpeg





Página 28

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


Componentes Obligatoriedad Descripción

VERSION=versión Obligatorio Versión de la especificación OGC.

REQUEST=GetFeatureInfo Obligatorio Nombre de la petición.

Parámetros del mapa Obligatorio Copia parcial de una petición de mapas que genera el mapa del cual se quiere obtener información.

QUERY_LAYERS=lista de capas Obligatorio Lista de una o más capas, sobre las que se realiza la consulta, separadas por comas.

INFO_FORMAT=formato de salida

Opcional Formato de respuesta de la información sobre el objeto (MIME type).

FEATURE_COUNT=número Opcional Número de objetos sobre los que se devuelve información (default=1).

X=pixel_column Obligatorio Coordenada X del objeto en el Mapa, en pixeles (medido desde la esquina superior izquierda=0).

Y=pixel_row Obligatorio Coordenada Y del objeto en el Mapa, en pixeles (medido desde la esquina superior izquierda=0).

EXCEPTIONS=exception_format Opcional 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/IDEE-

Referencia?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).

http://www.idee.es/wms/IDEE-Referencia/IDEE-Referencia?SERVICES=WMS&VERSION=1.1.0&REQUEST=GetFeatureInfo&LAYERS=redroi&STYLES=default&SRS=EPSG:4230&BBox=-5.4650655,38.4137,-1.62939155,42.13107&WIDTH=400&HEIGHT=500&FORMAT=image/png&OPAQUE&QUERY_LAYERS=redroi&FEATURE_COUNT=1&X=250&Y=300






Página 29

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/BCN25-

OWS/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

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=http://www.idee.es/SLD/prueba.xml






Página 30

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 31

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 32

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 (struts-

config.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 33

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 34

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 35

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 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

Página 38

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 39

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 40

3. Únicamente se estilizarán mapas en formato vectorial.

4. Se trabajarán con mapas de servicios municipales y/o servicios carreteros.

5. La herramienta estará pensada para trabajar en plataformas convencionales.

6. El manejador de la base de datos que se utilizará será PostgreSQL.

7. La herramienta estará programada en Java siguiendo la especificación J2EE.

8. 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.

Figura 3.1. Diagrama general de casos de uso del sistema

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

Diseñador Usuario Final

CU-3 Diseñar Mapa

CU-5 Publicar

Aplicación Web

CU-6 Visualizar

Aplicación Web

CU-4 Elegir Plantilla

de Diseño

CU-2 Autentificar

Usuario

CU-1 Registrar

Usuario


Página 41

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).

Figura 3.2. Diagrama del caso de uso Registrar Usuario

Tabla 3.1. Descripción de caso de uso Registrar Usuario

ID: CU-1 El diagrama de actividades que incluye los escenarios de éxito y fracaso se muestra en la figura (3.3).

Nombre del caso de uso:

Registrar Usuario

Actores: Diseñador, MapWeb Designer

Descripción: 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.

Precondiciones: Los actores deberán de tener en su navegador la página principal de MapWeb Designer y dar clic en el botón Registrarse.

Postcondiciones: Se insertarán los datos del diseñador en la base de datos PostgreSQL y cada usuario contará con un login y password personal.

Escenario de éxito 1:

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.

Escenario de fracaso 1:

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:

uc CU-1 Registrar Usuario

Diseñador

CU-1 Registrar

Usuario


Página 42

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).

Figura 3.4. Diagrama del caso de uso Autentificar Usuario

Tabla 3.2. Descripción del caso de uso Autentificar Usuario



Autentificar Usuario


Descripción: Permite que los diseñadores registrados ingresen al sistema MapWeb Designer una vez que hayan introducido su login y password correctos.

Precondiciones: Para ingresar al sistema el diseñador debe estar registrado en el sistema.

Postcondiciones: 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.

act DA-CU1 Registrar Usuario

Ma

pW

eb

De

sig

ne

rD

ise

ña

do

r

Inicio

Fin

¿login duplicado?

Introducir el login y

password deseado

Introducir datos

personales

Notificar duplicación

de login

Registrar datos en la

base de datosBuscar login

duplicado

¿Base de

datos

disponible?

Realizar la conexión

con la base de datos

Notificar error

No

Si

Si

No

uc CU-2 Autentificar Usuario

Diseñador

CU-2 Autentificar

Usuario


Página 43


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 no son correctos por lo que el sistema rechaza el acceso. 6. Terminar proceso.


1. El diseñador introduce el login. 2. El diseñador introduce el password. 7. El sistema realiza la conexión con la base de datos. 3. No es posible establecer conexión con la base de datos. 4. Notificar error. 5. Terminar proceso.

Incluye:

Suposiciones: Se supone que el diseñador ya se ha registrado en el sistema.

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.

act DA-CU2 Autentificar Usuario

Ma

pW

eb

De

sig

ne

rD

ise

ña

do

r

Inicio

Fin

Introducir Login

Introducir

Password

Validar login y

password

¿Login y

password

correctos?

Ingresar al

sistema

Rechazar ingreso al

sistema

¿Base de

datos

disponible?

Realizar la conexión

con la base de datos

Notificar error

No

SiSi

No


Página 44

Figura 3.6. Diagrama del caso de uso Diseñar Mapa

Tabla 3.3. Descripción de caso de uso Diseñar Mapa



Diseñar Mapa


Descripción: Permite a los diseñadores configurar opciones de estilo para estilizar un mapa.

Precondiciones: 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.

Postcondiciones: 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.



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.



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.

Incluye CU-3.1 Solicitar Mapa, CU-3.2 Aplicar Estilos.

Suposiciones: 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.

uc CU-3 Diseñar Mapa

Diseñador

CU-3 Diseñar Mapa

CU-3.1 Solicitar

Mapa

CU-3.2 Aplicar

Estilos

CU-3.3 Generar

Código XML

«include»«include»

«include»


Página 45

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: CU-3.1 El diagrama de actividades que incluye los escenarios de éxito y fracaso se muestra en la figura (3.8)


Solicitar Mapa


Descripción: Solicita un mapa proveniente de un servidor WMS.

Precondiciones: El diseñador debe de indicar que mapa desea solicitar.

Postcondiciones: 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.

act DA-CU3 Diseñar Mapa

Dis

eñ

ad

or

Ma

pW

eb

De

sig

ne

r

¿Mapa

Visualizado?

Estilizar Mapa

Fin

Notificar error

Generar Código

XMLConstruir cadena de

solicitud y env iar la

petición al WMS

Inicio

Realizar petición

GetCapabilities al WMS

Leer archiv o GetCapabilities y

construir el catálogo de mapas

¿Catálogo

de mapas

disponible?

Elegir del catálogo el

mapa a estilizar

No

No

Si

Si


Página 46

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



Aplicar estilos


Descripción: Permite configurar componentes para aplicarle estilos a los mapas visualizados.

Precondiciones: El mapa debe ser mostrado en el visor de mapas.

Postcondiciones: 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.

act DA-CU3.1 Solicitar Mapa

Ma

pW

eb

De

sig

ne

rD

ise

ña

do

r

Inicio

Construir la cadena

de solicitud ¿Mapa

Visualizado?

Fin

Seleccionar el mapa que

se desea v isualizar

Notificar que el

recurso no está

disponible

Env iar petición

GetMap al WMS

Visualizar mapa

solicitadoVisualizar error

Si

No


Página 47

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.

Incluye CU-3.3 Generar código XML.

Suposiciones:

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 48

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



Generar código XML

Actores: Diseñador, MapWeb Designer, WMS.

Descripción: Genera el código XML (cumpliendo con la especificación SLD) cada vez que el diseñador aplica un nuevo estilo al mapa.

Precondiciones: El mapa a estilizar debe estar visualizado en el visor de mapas.

Postcondiciones: 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.

Escenario fracaso 1:


diseñador.

act DA-CU3.2 Aplicar Estilos

Ma

pW

eb

De

sig

ne

rD

ise

ña

do

rInicio

Fin

Seleccionar tipo de

geometría a estilizar (punto,

línea, polígono o texto)

Hacer click sobre

un objeto del mapa

¿Geometría

tipo texto

seleccionada?

¿WMS

responde

solicitud?

Notificar Error

Configurar propiedades

de estilo

Obtener coordenadas X,Y del mapa

Aplicar estilo

¿WMS

responde

solicitud?

Generacion del

documento SLD

Construcción y env ío de

petición GetMap al WMS

Visualización del mapa

estilizado

Construir y env iar petición

GetFeatureInfo al WMS

Si

Si

Si

No

No

No


Página 49

3. Ocurre un error al construir el documento SLD. 4. Se notifica el error al diseñador. 5. Terminar proceso.



diseñador. 3. El sistema construye y envía la petición GetMap al WMS. 4. Ocurre un error, el WMS no responde. 5. Se notifica el error al diseñador. 6. Terminar proceso.

Incluye:

Suposiciones:

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).

Figura 3.11. Diagrama del caso de uso Elegir Plantilla de Diseño

act DA-CU3.3 Generar Código XML

WM

SD

ise

ña

do

rM

ap

We

b D

es

ign

er

Inicio

Fin

Notificar Error

Construir y env iar la

petición GetMap al WMS

con el nombre del mapa y el

SLD generado como

parámetros

¿SLD

creado?

¿Respuesta

del WMS

recibida?

Mostrar SLD

asociado al mapa

Configurar opciones

de estilo

Construir SLD de acuerdo a

las configuraciones de estilo

realizadas por el diseñador

Procesar solicitud

GetMap

Si

No

Si

No

uc CU-4 Elegir Plantilla de Diseño

Diseñador

CU-4 Elegir Plantilla

de Diseño


Página 50

Tabla 3.7. Descripción de caso de uso Elegir Plantilla de Diseño

ID: CU-4 El diagrama de actividades que incluye los escenarios de éxito y fracaso se muestra en la figura (3.12)


Elegir plantilla de diseño


Descripción: Provee un catálogo de aplicaciones Web para que el diseñador pueda elegir una de ellas y asociarla al mapa estilizado anteriormente.

Precondiciones: El diseñador debe haber sido autentificado anteriormente.

Postcondiciones: 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.

Suposiciones: Se supone que el diseñador ya terminó de estilizar el mapa para asociarlo a la plantilla seleccionada.

Figura 3.12. Diagrama de actividad de caso de uso Elegir Plantilla de Diseño.

act DA-CU4 Elegir plantilla de Diseño

Ma

pW

eb

De

sig

ne

rD

ise

ña

do

r

Inicio

Fin

Generar plantilla con

mapa asociado

Seleccionar Plantilla

¿Catálogo

de planti l las

visualizado?

¿Planti l la

Generada?

Notificar Error

No

No

Si

Si


Página 51

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).

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

ID: CU-5 El diagrama de actividades que incluye los escenarios de éxito y fracaso se muestra en la figura (3.14)


Publicar aplicación Web


Descripción: Permite publicar la aplicación Web en el contenedor Web con la finalidad de que sea visible en la red de Internet.

Precondiciones: El diseñador debió haber elegido una plantilla de página Web.

Postcondiciones: 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.

Suposiciones: Se supone que el diseñador ha terminado de estilizar el mapa.

Figura 3.14. Diagrama de actividad del caso de uso Publicar Aplicación Web

uc CU-5 Publicar Aplicación Web

Diseñador

CU-5 Publicar

Aplicación Web

act DA-CU5 Publicar Aplicación Web

Dis

eñ

ad

or

Ma

pW

eb

De

sig

ne

r

Inicio

Fin

Notificar Error

Copiar Archiv os a

Contenedor Web

¿Archivos

Copiados

Correctamente?Redirigir a página

publicada

Si

No


Página 52

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).

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



Visualizar aplicación Web

Actores: Diseñador, usuario final, navegador Web.

Descripción: Visualiza la página Web publicada anteriormente en un navegador.

Precondiciones: Los archivos de la aplicación Web deben de estar publicados en el contenedor Web.

Postcondiciones: 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.

uc CU-6 Visualizar Aplicación Web

Diseñador Usuario Final

CU-6 Visualizar

Aplicación Web


Página 53

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.

act DA-CU6 Visualizar Aplicación Web

Ma

pW

eb

De

sig

ne

r

WM

SC

on

ten

ed

or

We

bD

ise

ña

do

r/U

su

ari

o

Inicio

Fin

Abrir Nav egador Introducir el path de la

página Web publicada

en el nav egadorNotificar Error

¿Aplicación

Disponible?

Env iar petición GetMap

almacenada en la

aplicación publicada

Procesar la solicitud http

Procesar solicitud

GetMap

¿Respuesta

del WMS

recibida?

No

Si

Si

No


Página 54

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 55

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 56

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 57

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).

Tabla 3.10. Simbología utilizada en diagramas de secuencias

NOMBRE SIMBOLO DESCRIPCION

Frontera (Boundary)

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.

Control

Representa un proceso de control. Coordina los eventos necesarios para llevar a cabo el comportamiento que se especifica en el caso de uso.

Actor

Representa al usuario del sistema.

Clase

Representa las clases del sistema.

3.2.2.1. 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.

sd DSec-Registrar_Usuario

BoundaryControl

Clase


BoundaryControl

Clase

sd DSec-Registrar_...

Actorsd DSec-Registrar_Usuario

BoundaryControl

Clase


Página 58

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.

Figura 3.20. Diagrama de clases de Registrar Usuario

class DC-RegistrarUsuario

Action

Acciones::RegistraUsuarioAction

- 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()

org.apache.struts.action.ActionForm

Vista::RegistraUsuarioForm

- 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

BaseDatos::ConectaBD

- baseDatos: String


- password: String

- puerto: String

- servidor: String

- url: String

- usuario: String

+ ConectaBD()

+ getConexion() : Connection

+ InicializarDatosConfiguracion(String) : void

+ RealizaConexion(String) : Connection

BaseDatos::ConfiguraBD

- appRuta: String

- appServidor: String

- archivo: String

- bdNombre: String

- bdPassword: String

- bdPuerto: String

- bdServidor: String

- bdUsuario: String


- messages: MessageResources = MessageResource...

+ ConfiguraBD()

+ setArchivo(String) : void

«property get»

+ getbdNombre() : String

+ getbdPassword() : String

+ getbdPuerto() : String

+ getbdServidor() : String

+ getbdUsuario() : String


Página 59

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.


Diseñador

ConfiguraBDRegistraUsuarioForm

Interfaz

Registro_Correcto

Interfaz Registro Interfaz Error Struts-config.xml

RegistraUsuarioAction ConectaBDRegistraUsuarioModelo

Se inicializan todas

las variables con la

información

ingresada por el

actor.

Se obtiene la

información de las

variables

inicializadas.

Lee el archivo

PropiedadesBD.properties

para obtener los datos de

la conexión a la BD.

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

Ingresar

datos

personales RegistrarMapear acción

Direacciona setTxFnombre(nombre)

Direcciona

Mapear acción

Direcciona getTxFnombre()

Instanciar modelo

Conectar a

Base de

DatosInicializarDatosConfiguracion(path)

setArchivo(path)

Datos conexion :

bd,user,passwd

RealizaConexion(path)

getConexion() :Connection

BuscaUsuarioDuplicado(login) :intEjecutar Query

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

DireccionaMostrar resultado Numero diferente de 4

Comparar estado :false

Direcciona

Mapear acción

DireccionaMostrar resultado


Página 60

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.

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).

class DC-AutentificaUsuario

Action

Acciones::AutentificaUsuarioAction


Logica::AutentificaUsuarioModelo


- PasswdForma: String

- UsuarioForma: String

+ AutentificaUsuarioModelo()

+ desencriptarPasswd(String) : String

+ esValido(String, String, String) : int


Vista::AutentificaUsuarioForm

- miLogin: String

- miPasswd: String

+ AutentificaUsuarioForm()

+ getTxFpasswd() : String

+ getTxFusuario() : String


+ setTxFpasswd(String) : void

+ setTxFusuario(String) : void


BaseDatos::ConectaBD

- baseDatos: String


- password: String

- puerto: String

- servidor: String

- url: String

- usuario: String

+ ConectaBD()




BaseDatos::ConfiguraBD

- appRuta: String


- archivo: String

- bdNombre: String


- bdPuerto: String


- bdUsuario: String



+ ConfiguraBD()


«property get»







Página 61

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:

sd DSec-Autentificar_Usuario

AutentificaUsuarioModelo ConfiguraBDConectaBDAutentificaUsuarioActionAutentificaUsuarioForm

Interfaz Elige

Opción

Interfaz ErrorInterfaz LoginDiseñador Struts-config.xml

Lee el archivo

PropiedadesBD.properties

para obtener los datos de

la conexión a la BD.

El valor entero que regresa la

función esValido define lo

siguiente:

4= login y password correctos

otro numero= ocurrió un error

Introducir

login y

passwordIniciar Sesión

Mapear acción

DireccionasetTxFusuario(login)

setTxFpasswd(password)

Direcciona

Mapear acción

Direcciona getTxFusuario()

getTxFpasswd()

Instanciar modelodesencriptarPasswd(password) :String

Conectar a Base

de Datos

InicializarDatosConfiguracion(path)

setArchivo(path)

Datos conexion :

bd,user,passwd

RealizaConexion(path)

getConexion() :

Connection

esValido(login,password) :int

Ejecutar Query

4UsuarioVálido :true

Direcciona

Mapear acción

DireccionaMostrar resultado numero diferente de 4

UsuarioVálido :falseDirecciona

Mapear acción

DireccionaMostrar resultado


Página 62

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.

Figura 3.24. Diagrama de secuencias de Solicitar Mapa

Figura 3.25. Diagrama de clases de Solicitar Mapa

sd DSec-SolicitarMapa

Diseñador Servidor WMS

RealizaPeticionGeoserverForm

Interfaz Visualizar

Mapa

Interfaz Catálogo

de Mapas

Struts-config.xml

PeticionGeoserverAction

API

Seleccionar

mapaSolicitar mapa

Mapear acción

DireccionasetSrs_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


Construir Cadena Solicitud

Enviar Cadena

de Solicitud

Realizar Solicitud de MapaProcesa solicitud

Imagen del mapa

Procesar imagen

Mostrar mapa

Mostrar resultado

class DC-SolicitarMapa

org.apache.struts.action.Action

Acciones::PeticionGeoserv erAction



Vista::RealizaPeticionGeoserv erForm

- CapasSeleccionadas: String ([]) = null

- srs_seleccionado: String

+ getSrs_seleccionado() : String

+ RealizaPeticionGeoserverForm()


+ setSrs_seleccionado(String) : void


«property get»

+ getCapasSeleccionadas() : String[]

«property set»

+ setCapasSeleccionadas(String[]) : void


Página 63

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 64

Figura 3.26. Diagrama de clases de Aplicar Estilos y generar código XML


Página 65

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:

sd DSec-AplicarEstilos

Diseñador

creaSLDAction

Interfaz Visualizar

Mapa

Struts-config.xmlAPI

creaSLDForm CreaSLDModelo CreaTagsSLDModelo

Servidor WMS

Se inicializan

todas las

variables con la

información

ingresada por el

actor.

Se obtiene la

información de

las variables

inicializadas.

Configurar

componentes de

estiloAplicar estilo Mapear acción

Direccionar

setNombreCapa(String)

setTipogeometria(String)

Direcciona

Mapear acción

Direcciona getNombreCapa()

getTipogeometria()

Instanciar modeloConstruir 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


Construir cadena solicitud

Enviar cadena

solicitud

Realizar solicitud de mapa con estilo creadoProcesa solicitud

Imagen del mapa con estilo

Mostrar mapa

Mostrar resultado


Página 66

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).

Figura 3.28. Diagrama de clases de Elegir Plantilla de Diseño y Publicar Aplicación Web

Figura 3.29. Diagrama de secuencias Elegir Plantilla de Diseño y Publicar Aplicación Web

class DC-ElegirPlantilladeDiseño-PublicarAplicaciónWeb

org.apache.struts.action.Action

Acciones::AsociarPlantillaAction


Logica::AsociaMapaPlantillaModelo


~ num: int = 0

+ AsociarMapaPlantil la(String, String[], String[], String[]) : String

+ copia(String, String) : void

+ copiarCSSaCarpetaUser(String, String) : boolean


+ crear_id(String) : int

+ GuardaSLDenBD(String[], String, String, String, String, String, String) : boolean

+ obtieneIDusuario(String, String) : int

+ obtieneProyectosUser(int, String) : Collection

+ publicaPlantil laconMapa(String, String, String) : String

+ si_existeFile(String, String) : String


Vista::CatalogoPlantillasForm

- template: String

+ CatalogoPlantil lasForm()

+ getPlantil la() : String

+ setPlantil la(String) : void


sd DSec-ElegirPlantilladeDiseño

Diseñador Interfaz Pagina

Publicada

AsociarPlantil laActionCatalogoPlantil lasForm

Interfaz Catálogo

Plantil las

Struts-config.xml

AsociaMapaPlantil laModelo

Seleccionar

plantil la Publicar plantil laMapear acción

Direcciona setPlantil la(String)

Direcciona

Mapear accón

DireccionagetPlantil la()

Instanciar modeloAsociarMapaPlantil la(String,String[],String[],String[])

publicaPlantil laconMapa(String,String,String)

GuardaSLDenBD(String[] ,String,String,String,String,String,String)

path de publicación

Direcciona

Mapear acción

Direcciona

Mostrar resultado


Página 67

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.

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.

Figura 3.31. Diagrama Conceptual de la base de datos

sd DSec-VisualizarAplicacionWeb

Usuario/Diseñador Navegador Web

Introducir URLProcesar solicitud

respuestaServidor :200

Visualiza página Web publicada con mapa asociado

respuestaServidor :500

El servidor no encuentra el recurso solicitado

TIENE

contiene

pertenece

tiene

estil iza es estil izado

USUARIO

idUser

nombre

apPat

apMat

organizacion

pais

email

nombrelogin

passwd

<pi> Serial

Variable characters (254)








<M>

idUser <pi>

MAPA

idMapa

nombreMapa

bbox

srs

servidor

<pi> Serial



Integer


<M>

idMapa <pi>

ESTILO

idEstilo

nombreEstilo

sld

<pi> Serial


Text

<M>

idEstilo <pi>


Página 68

Figura 3.32. Diagrama Físico de la base de datos

FK_ESTILO_TIENE_MAPA

pertenece

contiene

FK_MAPA_TIENE_USUARIO

es estil izadoestil iza

USUARIO

idUser

nombre

apPat

apMat

organizacion

pais

email

nombrelogin

passwd

SERIAL

VARCHAR(254)

VARCHAR(254)

VARCHAR(254)

VARCHAR(254)

VARCHAR(254)

VARCHAR(254)

VARCHAR(254)

VARCHAR(254)

<pk>

MAPA

idMapa

idUser

nombreMapa

bbox

srs

servidor

SERIAL

INT4

VARCHAR(254)

VARCHAR(254)

INT4

VARCHAR(254)

<pk>

<fk>

ESTILO

idEstilo

idMapa

nombreEstilo

sld

SERIAL

INT4

VARCHAR(254)

TEXT

<pk>

<fk>

CAPÍTULO 4 IMPLEMENTACION

En este capítulo se describen las clases implementadas que muestran la

funcionalidad del sistema.

Capítulo 4 Implementación

Página 70

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.

Figura 4.1. Clases del paquete mx.edu.cenidet.MapWebDesigner.Modelo.BaseDatos

pkg mx.edu.cenidet.MapWebDesigner.Modelo.BaseDatos

ConectaBD

- baseDatos: String


- password: String

- puerto: String

- servidor: String

- url: String

- usuario: String

+ ConectaBD()




ConfiguraBD

- appRuta: String


- archivo: String

- bdNombre: String


- bdPuerto: String


- bdUsuario: String



+ ConfiguraBD()


«property get»







Página 71

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.

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.

Figura 4.3. Clases del paquete mx.edu.cenidet.MapWebDesigner.Modelo.Logica

pkg mx.edu.cenidet.MapWebDesigner.Modelo.Con...

ServletContextListener

ContextListenerCapas

{leaf}

+ contextDestroyed(ServletContextEvent) : void

+ contextInitialized(ServletContextEvent) : void

pkg mx.edu.cenidet.MapWebDesigner.Modelo.Logica

AsociaMapaPlantillaModelo


~ num: int = 0

+ AsociarMapaPlantil la(String, String[], String[], String[]) : String

+ copia(String, String) : void

+ copiarCSSaCarpetaUser(String, String) : boolean


+ crear_id(String) : int

+ GuardaSLDenBD(String[], String, String, String, String, String, String) : boolean

+ obtieneIDusuario(String, String) : int

+ obtieneProyectosUser(int, String) : Collection

+ publicaPlantil laconMapa(String, String, String) : String

+ si_existeFile(String, String) : String

AutentificaUsuarioModelo


- PasswdForma: String

- UsuarioForma: String

+ AutentificaUsuarioModelo()

+ desencriptarPasswd(String) : String

+ esValido(String, String, String) : int

Capa

- 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

CreaSLDModelo

~ 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

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

LeeArchiv oXMLGetCapabilities

- 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


+ BuscaUsuarioDuplicado(String) : int


+ crear_idUser() : int

+ encriptarPasswd(String) : String

+ RegistraUsuarioenBD(String, String, String, String, String, String, String, String, String) : int

+ RegistraUsuarioModelo()

-CatalogoOrdenado


Página 72

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 73

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).

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.

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


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

Página 76

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.

Capítulo 5 Pruebas

Página 77

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.

Capítulo 5 Pruebas

Página 78

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

Capítulo 5 Pruebas

Página 79

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.


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.

Capítulo 5 Pruebas

Página 80

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.


Capítulo 5 Pruebas

Página 81

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.


Capítulo 5 Pruebas

Página 82

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.


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.

Capítulo 5 Pruebas

Página 83

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.

Capítulo 5 Pruebas

Página 84

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.


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.

Capítulo 5 Pruebas

Página 85

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.


Capítulo 5 Pruebas

Página 86

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

Capítulo 5 Pruebas

Página 87

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.


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.

Capítulo 5 Pruebas

Página 88

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.

Capítulo 5 Pruebas

Página 89

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

Capítulo 5 Pruebas

Página 90

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.

Capítulo 5 Pruebas

Página 91

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.


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.

Capítulo 5 Pruebas

Página 92

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.


Capítulo 5 Pruebas

Página 93

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.


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.


Capítulo 5 Pruebas

Página 94

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


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.

Capítulo 5 Pruebas

Página 95

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

Capítulo 5 Pruebas

Página 96

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

Capítulo 5 Pruebas

Página 97

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.

Capítulo 5 Pruebas

Página 98

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.

Capítulo 5 Pruebas

Página 99

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.

Capítulo 5 Pruebas

Página 100

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


Capítulo 5 Pruebas

Página 101

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.

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

Página 104

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 105

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 106

Implementar la parte de obtención de la leyenda de los mapas estilizados.

ANEXOS

ANEXOS

Página 108

ANEXO A Evaluación de APIs visoras de mapas

Anexo A. Evaluación de APIs visoras de mapas

Página 110

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 111

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 112

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 113

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 114

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 WINDOWS LINUX MAC OS X

Internet Explorer Si(6) - -

Mozilla/Firefox Si(1.0+) Si(1.0+) Si(1.0+)

Netscape Si(7+) Si(7+) Si(7+)

Epiphany - Si -

Opera Si(7+) Si(7+) Si(7+)

Konqueror - No -

Safari - - Si

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. Instalar y configurar MapServer con Apache.

2. Descargar Ka-Map de http://ka-map.maptools.org/ (página oficial). En esta prueba se

descargó la versión 1.0.

3. Copiar todos los archivos, directorios y subdirectorios de htdocs situados en /ka-map-

ms4w-1.0/ms4w/apps/ka-map-1.0/ a la carpeta /ms4w/Apache/htdocs/Ka-Map.

http://ka-map.maptools.org/


Página 115

4. 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.

5. 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.

6. 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/IDEE-

Base?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.

http://dl.maptools.org/dl/

http://www.idee.es/wms/IDEE-Base/IDEE-Base?VERSION=1.1.0&REQUEST=GetMap&LAYERS=Relieve

http://www.idee.es/wms/IDEE-Base/IDEE-Base?VERSION=1.1.0&REQUEST=GetMap&LAYERS=Relieve


Página 116

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 117

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-Vista-

Controlador (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 118

● 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 119

Figura A.19. Trozo de código XML del archivo config.xsd

Figura A.20. Archivo de configuración


Página 120

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 121

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

Característica 1 5

Característica 2 3

Característica N 1

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 PESO API-1

CALIFICACIÓN

API-2

CALIFICACIÓN

Característica 1 5 10 1


Característica N 1 8 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

Calific. Subtotal Califiic. Subtotal

Característica 1 5 10 50 1 5


Característica N 1 8 8 2 2

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





TOTAL - 73 19

6. Comparar los resultados del paso 5 y elegir la API que más puntaje tenga (ver figura A.23).


Página 122

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 123

Tabla A.7. Asignación de ponderaciones a cada criterio


Código abierto 5

Buena documentación 4

Codificado en JAVA 5

Cumplir con especificaciones OGC 4

Permitir recuperar mapas de diferentes

fuentes

3

Sencillo de usar 4

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.

Figura A.24. Resultados de la evaluación de APIs

168

250

171181

230

0

50

100

150

200

250

300

msCross OpenLayers Ka-Map WMS

JavaScript

Library

Mapbuilder

Gráfica de resultados

Anexo A

Página 124

Tabla A.8. Matriz de evaluación

CRITERIOS

PESO

msCross OpenLayers Ka-Map WMS JavaScript Library MapBuilder

C Obser S C Obser S C Obser S C Obser S C Obser S

Código abierto 5 10 Permite bajar el

código del API en su sitio Web

50 10 Permite bajar el código del API




50

Buena documentación

4 5 Documenta sólo

algunas funciones del API

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

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

Permitir recuperar mapas de diferentes

fuentes

3 0

Únicamente

soporta los mapas

que provee MapServer

0 10

Recupera mapas de Geoserver,

MapServer, Yahoo Maps, Google

Maps, entre otros

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

Sencillo de usar 4 7

Proporciona pocos

ejemplos por lo que no es posible

saber la utilidad

de todas las funciones que

proporciona

28 10

Con los ejemplos que proporciona es suficiente para

guiar a los usuarios a crear

sus primeras aplicaciones

40 5

Requiere la

configuración de

Apache y Mapserver 20 8

Los ejemplos que

proporciona no

son suficientes para conocer todas

las funciones del

API

32 5

Requiere el

conocimiento de

etiquetas XML para realizar las

solicitudes de

mapas

20

TOTAL - 168 250 171 181 230

C: calificación

S: subtotal

Obser: observaciones

ANEXO B Evaluación de Servidores de Mapas

Anexo B. Evaluación de servidores de mapas

Página 126

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/deegree-

wms/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).

http://localhost:8080/deegree-wms/services?REQUEST=GetMap&SERVICE=WMS&VERSION=1.1.1&WIDTH=603&HEIGHT=476&LAYERS=Vegetation,Lake,Roads&TRANSPARENT=TRUE&FORMAT=image/png&BBOX=372233.9342431239,4460438,489069,4552689&SRS=EPSG:26912&STYLES=default,default,default






Página 127

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 128

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).

http://localhost:8080/geoserver/welcome.do


Página 129

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.

http://localhost:8080/geoserver


Página 130

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 131

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

http://localhost:8080/geoserver/wms?bbox=-119.99049000000001,13.621244999883022,-85.12511,33.62705500002082&styles=&Format=application/openlayers&request=GetMap&layers=Mexico:AliasMexico&width=800&height=430&srs=EPSG:4326




Página 132

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 133

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 134

Tabla B.1. Abstracto de etiquetas usadas en MapServer COMANDO DESCRIPCION

IMAGETYPE

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.

EXTENT

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 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.

FONSET Aquí se especifica la ruta completa de el archivo truetype fontlist (lista de fuentes). Este archivo lista cada una de las fuentes disponibles.

LABELITEM Este especifica que atributos de datos se usa para el etiquetado. LABELITEM es un parámetro del objeto LAYER.

LABEL Marca el inicio del objeto LABEL. El objeto label puede ser usado bajo otros objetos (Ejemplo: El objeto

SCALEBAR).

COLOR En el objeto LABEL, COLOR especifica el control de etiqueta de texto.

SHADOWSIZE 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.

TYPE 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).

FONT 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.

SIZE Si se usan fuentes truetype, el valor del tamaño es en pixeles. Si es bitmap, se puede escribir “small” o “large”.

POSITION

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” (center-

center). 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 135

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).

http://127.0.0.1:8081/ejemplo2/ejemplo2.html


Página 136

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


Característica 1 5

Característica 2 3

Característica N 1


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 137

Tabla B.4. Asignación de calificaciones a cada servidor de mapas de acuerdo a los criterios

CRITERIOS PESO WMS-1

CALIFICACIÓN

WMS-2

CALIFICACIÓN



Característica N 1 8 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





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-1 WMS- 2





TOTAL - 73 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 138

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


Código abierto 5

Fácil de instalar y manejar 5

Codificado en JAVA 2

Implementar las especificaciones OGC 5

Soportar el formato Shapefile 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 139

Tabla B.8. Comparativa de servidores

CRITERIOS

PESO

DEGREE GEOSERVER MAPSERVER

C Observaciones S C Observaciones S C Observaciones S

Código abierto 5 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

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

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

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 140

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.

Figura B.17. Resultados de la evaluación de servidores de mapas

180

220

160

0

50

100

150

200

250

DEGREE GEOSERVER MAPSERVER

Gráfica de resultados

ANEXO C Diseño de objetos para el documento SLD

Anexo C. Diseño de objetos para el documento SLD

Página 142

1..1

0..*

1..1

1..*

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..1

1..*

0..*

1..1

1..*

1..1

0..*

0..1

0..1

1..1

0..*

1..1

0..*

0..1

0..1

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..*

1..1

0..11..1

0..1

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..*

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..1

1..1

0..11..1

0..1

1..1

0..1

1..1

0..*

1..1

1..*

NamedLayer

- Name : java.lang.String

+

+

<<Getter>>

<<Setter>>

getName ()

setName (java.lang.String newName)

: java.lang.String

: void

StyledLayerDescriptor

-

-

-

-

version

Name

Title

Abstracts

: java.lang.String

: java.lang.String

: java.lang.String

: java.lang.String

+

+

+

+

+

+

+

+

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

getVersion ()

setVersion (java.lang.String newVersion)

getName ()


getTitle ()

setTitle (java.lang.String newTitle)

getAbstracts ()

setAbstracts (java.lang.String newAbstracts)

: java.lang.String

: void

: java.lang.String

: void

: java.lang.String

: void

: java.lang.String

: voidRule

-

-

-

-

-

-

Name

Title

Abstracts

LegendGraphic

MinScaleDenominator

MaxScaleDenominator

: java.lang.String

: java.lang.String

: java.lang.String

: Graphic

: float

: float

+

+

+

+

+

+

+

+

+

+

+

+

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

getName ()


getTitle ()


getAbstracts ()


getMinScaleDenominator ()

setMinScaleDenominator (float newMinScaleDenominator)

getMaxScaleDenominator ()

setMaxScaleDenominator (float newMaxScaleDenominator)

getLegendGraphic ()

setLegendGraphic (Graphic newLegendGraphic)

: java.lang.String

: void

: java.lang.String

: void

: java.lang.String

: void

: float

: void

: float

: void

: Graphic

: void

FeatureTypeStyle

-

-

-

-

-

Name

Title

Abstracts

FeatureTypeName

SemanticTypeIdentifier

: java.lang.String

: java.lang.String

: java.lang.String

: java.lang.String

: java.util.Collection

+

+

+

+

+

+

+

+

+

+

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

getName ()


getTitle ()


getAbstracts ()


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

Filter

ElseFilter

SymbolizerType

{abstract}

LineSymbolizer PolygonSymbolizer PointSymbolizer TextSymbolizer

Geometry

- PropertyName : PropertyNameType

+

+

<<Getter>>

<<Setter>>

getPropertyName ()

setPropertyName (PropertyNameType newPropertyName)

: PropertyNameType

: void

Stroke

GraphicFill

GraphicStroke

UserStyle

-

-

-

-

Name

Title

Abstracts

IsDefault

: java.lang.String

: java.lang.String

: java.lang.String

: boolean

+

+

+

+

+

+

+

+

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

getName ()


getTitle ()


getAbstracts ()


getIsDefault ()

setIsDefault (boolean newIsDefault)

: java.lang.String

: void

: java.lang.String

: void

: java.lang.String

: void

: boolean

: void

CssParameter

-

-

name

valor

: java.lang.String

: java.lang.String

+

+

+

+

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

getName ()


getValor ()

setValor (java.lang.String newValor)

: java.lang.String

: void

: java.lang.String

: void

ExpressionType

{abstract}

- expression : java.lang.String

+

+

<<Getter>>

<<Setter>>

getExpression ()

setExpression (java.lang.String newExpression)

: java.lang.String

: void

PropertyNameType

Graphic

-

-

-

Opacity

Size

Rotation

: java.lang.String

: java.lang.String

: java.lang.String

+

+

+

+

+

+

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

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

ExternalGraphic

-

-

OnlineResource

Format

: SimpleLink

: java.lang.String

+

+

+

+

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

getOnlineResource ()

setOnlineResource (SimpleLink newOnlineResource)

getFormat ()

setFormat (java.lang.String newFormat)

: SimpleLink

: void

: java.lang.String

: void

Mark

- WellKnownName : java.lang.String

+

+

<<Getter>>

<<Setter>>

getWellKnownName ()

setWellKnownName (java.lang.String newWellKnownName)

: java.lang.String

: void

Fill

Label

- Label : java.lang.String

+

+

<<Getter>>

<<Setter>>

getLabel ()

setLabel (java.lang.String newLabel)

: java.lang.String

: void

Font

PointPlacement

- Rotation : float

+

+

<<Getter>>

<<Setter>>

getRotation ()

setRotation (float newRotation)

: float

: void

LabelPlacement

LinePlacement

AnchorPoint

-

-

AnchorPointX

AnchorPointY

: float

: float

+

+

+

+

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

getAnchorPointX ()

setAnchorPointX (float newAnchorPointX)

getAnchorPointY ()

setAnchorPointY (float newAnchorPointY)

: float

: void

: float

: void

Displacement

-

-

DisplacementX

DisplacementY

: float

: float

+

+

+

+

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

getDisplacementX ()

setDisplacementX (float newDisplacementX)

getDisplacementY ()

setDisplacementY (float newDisplacementY)

: float

: void

: float

: void

PerpendicularOffset

- PerpendicularOffset : java.lang.String

+

+

<<Getter>>

<<Setter>>

getPerpendicularOffset ()

setPerpendicularOffset (java.lang.String newPerpendicularOffset)

: java.lang.String

: void

Halo

- Radius : float

+

+

<<Getter>>

<<Setter>>

getRadius ()

setRadius (float newRadius)

: float

: void

Featureid

- Fid : java.lang.String

+

+

<<Getter>>

<<Setter>>

getFid ()

setFid (java.lang.String newFid)

: java.lang.String

: void

SimpleLink

-

-

type

href

: java.lang.String

: java.lang.String

= simple

+

+

+

+

<<Getter>>

<<Setter>>

<<Getter>>

<<Setter>>

getType ()

setType (java.lang.String newType)

getHref ()

setHref (java.lang.String newHref)

: java.lang.String

: void

: java.lang.String

: void

Figura C.1. Diagrama de objetos SLD


Página 143

Figura C.2. Diagrama de clases SLD

class SLD

AnchorPoint

- anchorPointX: float

- anchorPointY: float

+ getAnchorPointX() : float

+ getAnchorPointY() : float

+ setAnchorPointX(float) : void

+ setAnchorPointY(float) : 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

Displacement

- displacementX: float

- displacementY: float

+ getDisplacementX() : float

+ getDisplacementY() : float

+ setDisplacementX(float) : void

+ setDisplacementY(float) : void

ElseFilter

ExpressionType

- expression: java.lang.String

+ getExpression() : java.lang.String

+ setExpression(java.lang.String) : void

ExternalGraphic

- format: java.lang.String

- onlineResource: SimpleLink

+ getFormat() : java.lang.String

+ getOnlineResource() : SimpleLink

+ setFormat(java.lang.String) : void

+ setOnlineResource(SimpleLink) : void

Featureid

- fid: java.lang.String

+ getFid() : java.lang.String

+ setFid(java.lang.String) : void

FeatureTypeStyle

- abstracts: java.lang.String

- featureTypeName: 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


+ 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


+ setRule(java.util.Collection) : void

+ setSemanticTypeIdentifier(java.util.Collection) : void

+ setTitle(java.lang.String) : void

Fill

+ 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

Filter

+ featureid: java.util.Collection

+ addFeatureid(Featureid) : void

+ getFeatureid() : java.util.Collection

+ getIteratorFeatureid() : java.util.Iterator

+ removeAllFeatureid() : void

+ removeFeatureid(Featureid) : void

+ setFeatureid(java.util.Collection) : void

Font








Geometry

- propertyName: PropertyNameType

+ getPropertyName() : PropertyNameType

+ setPropertyName(PropertyNameType) : void

Graphic

+ 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

+ 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

GraphicFill

+ graphic: Graphic

GraphicStroke

+ graphic: Graphic

Halo

+ fil l: Fil l

- radius: float

+ getRadius() : float

+ setRadius(float) : void

Label

- label: java.lang.String

+ getLabel() : java.lang.String

+ setLabel(java.lang.String) : void

LabelPlacement

+ linePlacement: LinePlacement

+ pointPlacement: PointPlacement

LinePlacement

+ perpendicularOffset: PerpendicularOffset

LineSymbolizer

+ geometry: Geometry

+ stroke: Stroke

Mark

+ fil l: Fil l

+ stroke: Stroke

- wellKnownName: java.lang.String

+ getWellKnownName() : java.lang.String

+ setWellKnownName(java.lang.String) : void

NamedLayer


+ userStyle: java.util.Collection

+ addUserStyle(UserStyle) : void

+ getIteratorUserStyle() : java.util.Iterator


+ getUserStyle() : java.util.Collection

+ removeAllUserStyle() : void

+ removeUserStyle(UserStyle) : void


+ setUserStyle(java.util.Collection) : void

PerpendicularOffset

- perpendicularOffset: java.lang.String

+ getPerpendicularOffset() : java.lang.String

+ setPerpendicularOffset(java.lang.String) : void

PointPlacement

+ anchorPoint: AnchorPoint

+ displacement: Displacement

- rotation: float

+ getRotation() : float

+ setRotation(float) : void

PointSymbolizer


+ graphic: Graphic

PolygonSymbolizer

+ fil l: Fil l


+ stroke: Stroke

PropertyNameType

Rule


+ elseFilter: ElseFilter

+ fi lter: Filter

- legendGraphic: Graphic

- maxScaleDenominator: float

- minScaleDenominator: float


+ symbolizerType: java.util.Collection


+ addSymbolizerType(SymbolizerType) : void


+ getIteratorSymbolizerType() : java.util.Iterator

+ getLegendGraphic() : Graphic

+ getMaxScaleDenominator() : float

+ getMinScaleDenominator() : float


+ getSymbolizerType() : java.util.Collection


+ removeAllSymbolizerType() : void

+ removeSymbolizerType(SymbolizerType) : void


+ setLegendGraphic(Graphic) : void

+ setMaxScaleDenominator(float) : void

+ setMinScaleDenominator(float) : void


+ setSymbolizerType(java.util.Collection) : void


SimpleLink

- 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

Stroke


+ graphicFill: GraphicFill

+ graphicStroke: GraphicStroke







StyledLayerDescriptor



+ namedLayer: java.util.Collection


- version: java.lang.String

+ addNamedLayer(NamedLayer) : void


+ getIteratorNamedLayer() : java.util.Iterator


+ getNamedLayer() : java.util.Collection


+ getVersion() : java.lang.String

+ removeAllNamedLayer() : void

+ removeNamedLayer(NamedLayer) : void



+ setNamedLayer(java.util.Collection) : void


+ setVersion(java.lang.String) : void

SymbolizerType

TextSymbolizer

+ fil l: Fil l

+ font: Font


+ halo: Halo

+ label: Label

+ labelPlacement: LabelPlacement

UserStyle


+ featureTypeStyle: java.util.Collection

- isDefault: boolean



+ addFeatureTypeStyle(FeatureTypeStyle) : void


+ getFeatureTypeStyle() : java.util.Collection

+ getIsDefault() : boolean

+ getIteratorFeatureTypeStyle() : java.util.Iterator



+ removeAllFeatureTypeStyle() : void

+ removeFeatureTypeStyle(FeatureTypeStyle) : void


+ setFeatureTypeStyle(java.util.Collection) : void

+ setIsDefault(boolean) : void



+perpendicularOffset

-onlineResource

+displacement+anchorPoint

+stroke

+fil l

+graphic

+geometry

+pointPlacement

+linePlacement

+fil l

+graphic+graphic

-propertyName

+graphicFill

+stroke

-legendGraphic

+labelPlacement

+label

+halo

+geometry

+font

+fil l

+geometry

+graphicFill

+filter+elseFilter

+stroke

+geometry

+fil l

+graphicStroke


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

Página 146

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 147

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 148

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 149

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 150

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 151

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 152

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 153

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 154

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 155

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 156

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 157

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 158

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 fill-

opacity).

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



Página 159

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 160

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 161

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 162

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 163

Figura D.38. Ejemplo de simbolización Texto



Página 164

ANEXO E Plan de Pruebas

Anexo E. Plan de pruebas

Página 166

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 SIGNIFICADO

MAP Mapas

WEB Web

DE Designer

XX Grupo de prueba

YY Caso de prueba

MapWeb Designer: Diseñador de mapas en Web.


Página 167

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.

Tabla E.1. Elementos de prueba

TIPO NOMBRE

Módulo MAPWEBDE-01 Gestión de acceso al sistema.

Módulo MAPWEBDE-02 Solicitud y visualización de mapas.

Módulo MAPWEBDE-03 Aplicación de estilos al mapa.

Módulo MAPWEBDE-04 Asociar mapa a plantilla de aplicación Web

Módulo MAPWEBDE-05 Publicación de la página Web.

Módulo MAPWEBDE-06 Visualización de la página Web.

3.2. 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 168

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:

Tabla E.2. Descripción de las tareas de prueba

TAREA TAREA PRECEDENTE HABILIDADES ESPECIALES RESPONSABILIDADES

1. Realizar el plan de pruebas.

Análisis y diseño de la herramienta MapWeb

Designer.

Conocer el estándar 829 de la IEEE y las funciones que realizará MapWeb Designer.

Autora de esta tesis.

2. Realizar las pruebas.

Tarea 1 e implementación de la herramienta MapWeb

Designer.

Conocer la arquitectura de MapWeb Designer, los casos de uso, las clases y métodos desarrollados.


3. Resolver los incidentes resultantes de las pruebas.

Tarea 2

Conocimiento de J2EE, XML, JavaScript, Ajax, funciones del API visora de mapas y las especificaciones SLD y WMS de la OGC.


4. Evaluar los resultados.

Tarea 3 Conocer el objetivo de la tesis, alcances, limitaciones e hipótesis de prueba de la investigación.


3.8. 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 169

Tabla E.3. Requisitos ambientales

REQUISITO CARACTERÍSTICAS

PC(Equipo servidor)

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.

PC(Equipo cliente) 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.

3.9. 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 170

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 171

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 172

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.


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.


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 173

Proceso

1. Ingresar al sistema.

2. Elegir Nuevo Proyecto.

3. Seleccionar el mapa a visualizar.

4. Enviar solicitud a WMS.

5. 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 174

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.



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



Proceso

1. Elegir tipo de geometría punto para indicar que se van a estilizar los puntos del

mapa.



Resultado esperado

Los objetos tipo punto mostrados en el mapa deben de cambiar de apariencia de


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 175

Entorno



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.



Resultado esperado

Los objetos tipo texto mostrados en el mapa deben de cambiar de apariencia de


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 176

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


2. Solicitar un mapa.

3. Estilizar el mapa.

4. Seleccionar “Asociar mapa a plantilla general”.

5. Del catálogo de plantillas predefinidas elegir una de ellas.

6. 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


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.

Referencias

Página 177

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.

http://www.monografias.com/trabajos/gis/gis.shtml

Referencias

Página 178

[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 línea]

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/ieeestd829-

1998standardtest_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.

Referencias

Página 179

[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

Referencias

Página 180

[WIKIAPI, 2007] Wikipedia. Application Programming Interface. [En línea],

http://es.wikipedia.org/wiki/API. Consultado en Abril de 2007

[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://wms-

map.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.

Documents

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