Generador de mapas croquis en formato SVG-Tiny para dispositivos móviles aplicando perfiles

cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS DE LA COMPUTACIÓN

Generador de mapas croquis en formato SVG-Tiny para dispositivos móviles aplicando perfiles

presentada por

Omar Ríos González Ing. en Sistemas Computacionales por el I. T. de Minatitlán

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. Hugo Estrada Esquivel

Jurado:

Dr. Javier Ortiz Hernández – Presidente Dra. Azucena Montes Rendón – Secretario Dr. José Antonio Zarate Marceleño – Vocal

Dr. Juan Gabriel González Serna – Vocal Suplente

Cuernavaca, Morelos, México. Febrero de 2010

RESUMEN

En el presente documento se describe una metodología para la generación automática de

mapas croquis en formato SVG-Tiny en el proyecto “Generador de mapas tipos croquis en

formato SVG-Tiny para dispositivos móviles aplicando perfiles”, se identifican las

características técnicas del dispositivo celular que envía la solicitud para generar el mapa

en función de las características del dispositivo.

Este proyecto tiene como objetivo proporcionar servicios de búsquedas contextuales, para

localizar puntos de interés o prestadores de servicios que se encuentren cerca de la

ubicación del usuario que realiza la consulta.

El resultado de estas consultas es un mapa de tipo croquis en formato vector escalable

gráfico tiny (SVG-Tiny), el servicio utilizado para el envío de las solicitudes se realiza vía

HTTP, el resultado de esta solicitud es enviado en un archivo SVG-Tiny que contiene el

mapa croquis mostrando los resultados de la búsqueda contextual, por medio de

conexiones HTTP, la parte innovadora de este trabajo es la adopción de métodos para

identificar el perfil del dispositivo celular y en función de sus capacidades es generado un

mapa a la medida.

ABSTRACT

This document describes a methodology for automatic generation of sketch maps in SVG-

Tiny format in the "Generator type-sketch maps in SVG-Tiny format for mobile devices

applying profiles", identifies the technical characteristics of the mobile device that sends

the request to generate the map based on device characteristics.

The objective of this project is to provide services of contextual searches to locate points

of interest or service providers that are near the location of the user who make the

consultation.

The result of these consultations is a type sketch map in format tiny scalable vector

graphics (SVG-Tiny), the service used for sending the request is performed via HTTP, the

result of this request is sent to a file SVG-Tiny containing the sketch map showing the

contextual search results through HTTP connections, the innovative part of this work is the

adoption of methods to identify the profile of mobile device and based on their capacities is

generated a map to the measure.

i

TABLA DE CONTENIDO

CAPÍTULO I INTRODUCCIÓN _______________________________________ 1

1. Introducción __________________________________________________ 2

1.1 Descripción del problema _________________________________________ 3

1.2 Objetivo ________________________________________________________ 3

1.3 Justificación y beneficios __________________________________________ 4

1.4 Antecedentes ____________________________________________________ 5

1.5 Alcances y limitaciones ___________________________________________ 7

1.5.1 Alcances _____________________________________________________________ 7

1.5.2 Limitaciones __________________________________________________________ 7

1.6 Estado del arte ___________________________________________________ 8

1.6.1 Desarrollo de servicios de rutas de mapas para celulares basados en G-XML ______ 8

1.6.2 Mapas adaptivos para aplicaciones móviles _________________________________ 9

1.6.3 Mejorando las direcciones de ruta en dispositivos móviles _____________________ 11

1.6.4 Sistema de soporte para contenido multimedia dinámico personalizado en dispositivos

móviles ___________________________________________________________________ 12

1.6.5 Visualización Adaptiva de información geográfica en dispositivos móviles _________ 13

1.6.6 gvSIG para dispositivos móviles _________________________________________ 14

1.6.7 Sistema de Información Geográfica basado en SVG _________________________ 15

1.6.8 Procesando datos interoperables por Aplicaciones Geoespaciales Móviles _______ 16

1.6.9 Tabla comparativa del estado del arte _____________________________________ 19

1.7 Organización del documento ______________________________________ 20

CAPÍTULO II MARCO TEÓRICO ____________________________________ 21

2. Marco teórico ________________________________________________ 22

2.1 Mapa tipo croquis _______________________________________________ 22

2.2 LBS. Servicios basados en localización _____________________________ 22

2.2.1 Componentes de los LBS _______________________________________________ 23

2.2.2 Funcionamiento ______________________________________________________ 24

2.2.3 Clasificación _________________________________________________________ 24

2.3 Sistema de información geográfica _________________________________ 26

2.3.1 GIS Vectoriales _______________________________________________________ 27

2.3.2 GIS Raster __________________________________________________________ 28

2.4 Imágenes Gráficos Vectoriales Escalables (SVG) _____________________ 29

2.5 Mensajería SMS _________________________________________________ 30

2.6 Mensajería MMS ________________________________________________ 31

ii

CAPÍTULO III ANÁLISIS Y DISEÑO __________________________________ 33

3. Análisis y diseño _____________________________________________ 34

3.1 Análisis________________________________________________________ 34

3.1.1 Arquitectura del generador de mapas croquis _______________________________ 34

3.1.2 Base de datos espacial ________________________________________________ 35

3.1.3 Algoritmo de ruta _____________________________________________________ 39

3.1.4 Casos de uso de la aplicación móvil SketchMap4U __________________________ 42

3.1.4.1 Caso de uso general ______________________________________________ 42

3.1.4.2 Caso de uso: Configurar RMS _______________________________________ 43

3.1.4.3 Caso de uso: Construir petición HTTP _________________________________ 48

3.1.4.4 Caso de uso: Enviar petición HTTP ___________________________________ 49

3.1.5 Casos de uso de la aplicación web SketchMapServer ________________________ 50

3.1.5.1 Casos de uso general______________________________________________ 50

3.1.5.2 Caso de uso: recibir petición HTTP ___________________________________ 51

3.1.5.3 Caso de uso: Interpretar petición HTTP ________________________________ 52

3.1.5.4 Caso de uso: Generar mapa SVG-Tiny ________________________________ 53

3.1.5.5 Caso de uso: Enviar mapa SVGTiny __________________________________ 61

3.2 Diseño ________________________________________________________ 62

3.2.1 Paquetes diseñados ___________________________________________________ 63

3.2.1.1 Paquete mx.edu.cenidet.gateway.database ____________________________ 63

3.2.1.2 Paquete mx.edu.cenidet.gateway.maps _______________________________ 64

3.2.1.3 Paquete mx.edu.cenidet.gateway.maps.coordinates ______________________ 67

3.2.1.4 Paquete mx.edu.cenidet.gateway.servlet_______________________________ 69

3.2.1.5 Paquete mx.edu.cenidet.gateway.mobiledevice _________________________ 70

3.2.1.6 Paquete mx.edu.cenidet.gateway.routing ______________________________ 71

3.2.1.7 Paquete mx.edu.cenidet.gateway.SVGTiny _____________________________ 72

3.3 Base de datos MobileDevice ______________________________________ 74

3.3.1 DeviceMine v3.0 ______________________________________________________ 74

3.3.2 DeviceAtlas __________________________________________________________ 74

3.3.3 WURFL (Wireless Universal Resource File) ________________________________ 75

CAPÍTULO IV IMPLEMENTACIÓN __________________________________ 77

4. Implementación ______________________________________________ 78

4.1 Recibir petición HTTP ____________________________________________ 78

4.2 Interpretar la petición HTTP _______________________________________ 79

4.3 Conexión a las bases de datos ____________________________________ 79

4.3.1 Obtener el perfil del dispositivo móvil ______________________________________ 81

4.3.2 Obtener puntos de interés ______________________________________________ 82

4.3.3 Obtener puntos de referencia ____________________________________________ 83

4.4 Generar mapa SVGTiny __________________________________________ 84

iii

4.5 Enviar mapa SVGTiny ____________________________________________ 94

CAPÍTULO V PRUEBAS Y RESULTADOS ____________________________ 95

5. Pruebas y resultados__________________________________________ 96

5.1 Realización de las pruebas _______________________________________ 96

5.2 Evaluación de los resultados _____________________________________ 102

CAPÍTULO VI CONCLUSIONES ____________________________________ 103

6.1 Conclusiones __________________________________________________ 104

6.2 Aportaciones __________________________________________________ 105

6.3 Problemas encontrados _________________________________________ 105

6.4 Trabajos futuros _______________________________________________ 106

6.5 Publicaciones _________________________________________________ 108

ANEXOS ______________________________________________________ 109

ANEXO A Análisis para representar puntos de interés ________________ 110

ANEXO B Estudio de plataformas móviles __________________________ 119

ANEXO C Plan de pruebas _______________________________________ 131

ANEXO D Scalable Vector Graphics (SVG) __________________________ 152

REFERENCIAS _________________________________________________ 163

iv

Listado de figuras

Figura 1-1 Usuarios de dispositivos móviles por cada 100 habitantes _______________________ 4

Figura 1-2 Representación del servicio de rutas ________________________________________ 8

Figura 1-3 Procedimiento para generar la ruta del mapa _________________________________ 9

Figura 1-4 Segmento de ruta presentado vía Web _____________________________________ 11

Figura 1-5 Descripción de ruta _____________________________________________________ 11

Figura 1-6 Navegación de mapas en PDA (CityMap) ___________________________________ 12

Figura 1-7 Arquitectura de MM4U __________________________________________________ 13

Figura 1-8 Interfaz de usuario de gvSIG Mobile _______________________________________ 14

Figura 1-9 Sincronización de datos desde gvSIG desktop _______________________________ 15

Figura 1-10 Arquitectura de GIAS __________________________________________________ 16

Figura 1-11 Creación de archivo SVG _______________________________________________ 16

Figura 1-12 Arquitectura para integrar aplicaciones móviles especificando dispositivos al SDI ___ 17

Figura 1-13 Principales componentes del prototipo del cliente móvil _______________________ 18

Figura 1-14 Representación y visualización de datos ___________________________________ 18

Figura 2-1 Representación de un Mapa tipo croquis ____________________________________ 22

Figura 2-2 Áreas que conforman los LBS ____________________________________________ 22

Figura 2-3 Componentes básicos LBS ______________________________________________ 23

Figura 2-4 Funcionamiento LBS____________________________________________________ 24

Figura 2-5 Clasificación de los LBS _________________________________________________ 25

Figura 2-6 Operaciones de geometría _______________________________________________ 27

Figura 2-7 Representación de un mapa vectorial ______________________________________ 28

Figura 2-8 Representación de un mapa ráster ________________________________________ 28

Figura 2-9 Perfiles SVG __________________________________________________________ 30

Figura 2-10 Estructura de un mensaje SMS. __________________________________________ 30

Figura 2-11 Esquema de composición de páginas en un mensaje MMS. ____________________ 31

Figura 3-1 Arquitectura del generador de mapas croquis en un contexto de cliente/servidor ____ 34

Figura 3-2 Tablas de metadatos de la especificación OpenGIS ___________________________ 36

Figura 3-3 Representación de un BBOX _____________________________________________ 37

Figura 3-4 Algoritmo de Dijkstra ____________________________________________________ 40

Figura 3-5 Representación del área de interés ________________________________________ 40

Figura 3-6 Aristas y nodos del área de interés ________________________________________ 41

Figura 3-7 Grafo con los nodos inferidos _____________________________________________ 41

Figura 3-9 Diagrama de flujo del proceso de obtención de la ruta _________________________ 42

Figura 3-8 Ruta obtenida del algoritmo de Dijkstra _____________________________________ 42

Figura 3-10 Diagrama general de los casos de uso de la aplicación SketchMap4U ____________ 43

Figura 3-11 Diagrama de caso de uso: CU1 Configurar RMS _____________________________ 43

Figura 3-12 Diagrama de actividad del caso de uso: CU1 Configurar RMS __________________ 44

Figura 3-13 Diagrama de actividad del caso de uso: CU1.1 Crear RMS ____________________ 45

Figura 3-14 Diagrama de actividad del caso de uso: CU1.2 Leer RMS _____________________ 46

Figura 3-15 Diagrama de actividad del caso de uso: CU1.3 Actualizar RMS _________________ 47

Figura 3-16 Diagrama de caso de uso: CU2 Construir petición HTTP ______________________ 48

Figura 3-17 Diagrama de actividad del caso de uso: CU2 Construir petición HTTP ____________ 48

Figura 3-18 Diagrama de caso de uso: CU3 Enviar trama _______________________________ 49

Figura 3-19 Diagrama de actividad del caso de uso: CU3 Enviar trama _____________________ 49

v

Figura 3-20 Diagrama general de casos de uso de la aplicación SketchMapServer ___________ 50

Figura 3-21 Diagrama de caso de uso: CU4 Recibir petición HTTP ________________________ 51

Figura 3-22 Diagrama de actividad del caso de uso: CU4 Recibir petición HTTP _____________ 51

Figura 3-23 Diagrama de caso de uso: CU5 Interpretar petición HTTP _____________________ 52

Figura 3-24 Diagrama de actividad del caso de uso: CU5 Interpretar petición HTTP ___________ 53

Figura 3-25 Diagrama de caso de uso: CU6 Generar mapa SVGTiny ______________________ 53

Figura 3-26 Diagrama de actividad del caso de uso: CU6.1 Obtener perfil del dispositivo _______ 54

Figura 3-27 Diagrama de caso de uso: CU6.2 Crear imagen SVGTiny _____________________ 55

Figura 3-28 Diagrama de actividad del caso de uso: CU6.2.1 Obtener mapa SVG ____________ 56

Figura 3-29 Diagrama de actividad del caso de uso: CU6.2.2 Convertir SVG a SVGTiny _______ 57

Figura 3-30 Diagrama de actividad del caso de uso: CU6.2.3 Generar ruta __________________ 58

Figura 3-31 Diagrama de actividad del caso de uso 6.2.4 Obtener puntos de referencia________ 59

Figura 3-32 Diagrama de actividad del caso de uso: CU6.2.5 Agregar datos al SVGTiny _______ 60

Figura 3-33 Diagrama de caso de uso: CU7 Enviar mapa SVGTiny ________________________ 61

Figura 3-34 Diagrama de actividad del caso de uso: CU7 Enviar mapa SVGTiny _____________ 61

Figura 3-35 Diagrama general de paquetes del generador de mapas croquis SVGTiny ________ 62

Figura 3-36 Diagrama de clases del paquete mx.edu.cenidet.gateway.database _____________ 63

Figura 3-37 Diagrama de secuencia para una conexión a postgres ________________________ 64

Figura 3-38 Diagrama de clases del paquete mx.edu.cenidet.gateway.maps ________________ 65

Figura 3-39 Diagrama de secuencia para la obtención del mapa SVG ______________________ 66

Figura 3-40 Diagrama de secuencia para la obtención de los datos del SVGTiny _____________ 67

Figura 3-41 Diagrama de clases del paquete mx.edu.cenidet.gateway.maps.coordinates_______ 68

Figura 3-42 Diagrama de secuencia para convertir coordenadas UTM y georeferenciales ______ 69

Figura 3-43 Diagrama de clases del paquete mx.edu.cenidet.gateway.servlets _______________ 69

Figura 3-44 Diagrama de secuencia para dar al servlet el mapa SVGTiny ___________________ 70

Figura 3-45 Diagrama de clases del paquete mx.edu.cenidet.edu.gateway.mobiledevice _______ 70

Figura 3-46 Diagrama de secuencia para la obtención del dispositivo móvil _________________ 71

Figura 3-47 Diagrama de clases del paquete mx.edu.cenidet.gateway.routing _______________ 71

Figura 3-48 Diagrama de secuencia para generar la ruta mínima _________________________ 72

Figura 3-49 Diagrama de clases del paquete mx.edu.cenidet.gateway.SVGTiny ______________ 73

Figura 3-50 Diagrama de actividad para crear el mapa SVGTiny __________________________ 73

Figura 3-51 Diagrama relacional de la base de datos MobileDevice ________________________ 76

Figura 4-1 Recepción de la petición HTTP. ___________________________________________ 79

Figura 4-2 Interpretación de la petición HTTP _________________________________________ 79

Figura 4-3 Conexión a la base de datos Postgres ______________________________________ 80

Figura 4-4 Conexión a la extensión PostGIS de la base de datos Postgres __________________ 80

Figura 4-5 Ejemplo de conexión a la base de datos ____________________________________ 81

Figura 4-6 Obtención del perfil del dispositivo móvil ____________________________________ 82

Figura 4-7 Obtención de los puntos de interés ________________________________________ 83

Figura 4-8 Obtención de los puntos de referencia ______________________________________ 84

Figura 4-9 Obtención del mapa SVGTiny ____________________________________________ 86

Figura 4-10 Generación y obtención del área de interés (BBOX) __________________________ 87

Figura 4-11 Obtención del mapa SVG _______________________________________________ 88

Figura 4-12 Conversión SVG a SVGTiny _____________________________________________ 89

Figura 4-13 Obtención de la ruta ___________________________________________________ 90

Figura 4-14 Conversión de coordenadas georeferenciales a pixeles _______________________ 91

vi

Figura 4-15 Ejemplo para convertir coordenadas georeferenciales a pixeles _________________ 92

Figura 4-16 Métodos de elementos que se agregan al mapa SVGTiny _____________________ 93

Figura 4-17 Métodos para agregar datos al mapa SVGT ________________________________ 94

Figura 4-18 Enviar el mapa SVGT al dispositivo móvil __________________________________ 94

Figura 5-1 Parámetros de conexión para el MBDR PostgreSQL __________________________ 97

Figura 5-2 Parámetros de conexión de la extensión PostGIS SBLAGWMMS ________________ 97

Figura 5-3 Interpretación del mensaje recibido ________________________________________ 97

Figura 5-4 Perfil del dispositivo móvil ________________________________________________ 98

Figura 5-5 Proceso de obtención del mapa imagen en consola ___________________________ 99

Figura 5-6 Mapa obtenido ________________________________________________________ 99

Figura 5-7 Representación de la ruta en nodos ________________________________________ 99

Figura 5-8 Visualización de la ruta mediante Netbeans ________________________________ 100

Figura 5-9 Obtención de los POR(Point of Reference - puntos de referencia) _______________ 100

Figura 5-10Visualización del proceso de una petición del servicio de taxis. _________________ 101

Listado de tablas

Tabla 1-1 Costos de mensajería de las telefónicas en México, 2009 ________________________ 5

Tabla 1-2 Comparativa de los trabajos del estado del arte _______________________________ 19

Tabla 2-1 Necesidades de los usuarios móviles _______________________________________ 25

Tabla 3-1 Descripción del caso de uso: CU1 Configurar RMS ____________________________ 44

Tabla 3-2 Descripción del caso de uso: CU1.1 Crear RMS _______________________________ 45

Tabla 3-3 Descripción del caso de uso: CU1.2 Leer RMS _______________________________ 46

Tabla 3-4 Descripción del caso de uso: CU1.3 Actualizar RMS ___________________________ 47

Tabla 3-5 Descripción del caso de uso: CU2 Construir petición HTTP ______________________ 48

Tabla 3-6 Descripción del caso de uso: CU3 Enviar trama _______________________________ 49

Tabla 3-7 Descripción del caso de uso: CU4 Recibir petición HTTP ________________________ 51

Tabla 3-8 Descripción del caso de uso: CU5 Interpretar petición HTTP _____________________ 52

Tabla 3-9 Descripción del caso de uso: CU6.1 Obtener perfil del dispositivo móvil ____________ 53

Tabla 3-10 Descripción del caso de uso: CU6.2.1 Obtener mapa SVG _____________________ 55

Tabla 3-11 Descripción del caso de uso: CU 6.2.2 Convertir SVG a SVGTiny ________________ 56

Tabla 3-12 Descripción del caso de uso: CU6.2.3 Generar ruta ___________________________ 57

Tabla 3-13 Descripción del caso de uso: CU6.2.4 Obtener puntos de referencia ______________ 58

Tabla 3-14 Descripción del caso de uso: CU6.2.5 Agregar datos al SVGTiny ________________ 59

Tabla 3-15 Descripción del caso de uso: CU7 Enviar mapa SVGTiny ______________________ 61

Tabla 3-16 Descripción de los paquetes de la aplicación SketchMapServer. _________________ 62

Tabla 3-17 Comparación de los repositorios de dispositivos móviles _______________________ 75

Tabla 3-18 Descripción de las de la base de datos MobileDevice _________________________ 76

Tabla 5-1 Evaluación de resultados ________________________________________________ 102

GLOSARIO API Application Programming Interface. Interfaz de programación de

aplicación. Es el conjunto de funciones y procedimientos que ofrece cierta

librería para ser utilizado por otro software como una capa de abstracción.

Representa una interfaz de comunicación entre componentes de software.

BDE Base de Datos Espacial. Provee todos los servicios de los Sistemas

manejadores de bases de datos relacionales y una administración efectiva

y eficiente de datos espaciales

BBOX Bounding BOX. Es un rectángulo orientado por líneas x-y, contiene un

conjunto de datos geográficos especificado por dos coordenadas: xmin,

ymin and xmax, ymax.

Capa Unidad básica de información geográfica que puede solicitarse a un

servidor como un mapa.

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.

CDMA Code Division Multiple Access. El acceso múltiple por división de código o

CDMA es un término genérico para varios métodos de multiplexación o

control de acceso al medio basados en la tecnología de espectro

extendido (spread spectrum). Generalmente se emplea en

comunicaciones inalámbricas (por radiofrecuencia), aunque también

puede usarse en sistemas de fibra óptica o de cable.

DBMS Sistema Manejador de bases de datos.

Gateway Hardware o software que realiza la conversión de protocolos entre

diferentes tipos de redes.

GIS Geographic Information System. Los sistemas de información geográfica

son una integración organizada de hardware, software, datos geográficos

y personal, diseñado 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.

GPS Global Positioning System. Sistema de Posicionamiento Global. Sistema

Global de Navegación por Satélite que permite determinar en todo el

mundo la posición de un objeto.

GPRS General Packet Radio Service. Es un servicio de datos móvil orientado a

paquetes. Está disponible para los usuarios del Sistema Global para

Comunicaciones Móviles (GSM). Permite velocidades de transferencia de

56 a 114 Kbps.

GSM Global System for Mobile communications. Es un sistema estándar para

comunicación utilizando teléfonos móviles que incorporan tecnología

digital.

HTTP HyperText Transfer Protocol. Es un protocolo orientado a transacciones

Web y sigue el esquema petición-respuesta entre un cliente y un servidor.

IEEE Institute of Electrical and Electronics Engineers. Instituto de Ingenieros

Eléctricos y Electrónicos, una asociación técnico-profesional mundial

dedicada a la estandarización, entre otras cosas. Es la mayor asociación

internacional sin fines de lucro formada por profesionales de las nuevas

tecnologías, como ingenieros de telecomunicaciones, ingenieros

electrónicos, Ingenieros en informática e Ingenieros en computación.

JCP Java Community Process. Es un proceso formalizado que permite a las

partes interesadas involucrarse en la definición de futuras versiones y

características de la plataforma Java.

JSR Java Specification Request. Son documentos formales que describen las

especificaciones y tecnologías propuestas para que sean añadidas a la

plataforma Java.

LBS Location Based Service. Ofrecen un servicio personalizado a los usuarios

basado en su información de ubicación geográfica. Para su operación

utiliza tecnología de sistemas de información geográfica, alguna

tecnología de posicionamiento y tecnología de comunicación de redes

para transmitir información hacia una aplicación LBS que pueda procesar

y responder la solicitud.

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.

Mapa croquis Se define como una representación gráfica de la ubicación exacta de una

dirección o lugar que se está localizando por medio de coordenadas o

puntos de referencia, básicamente se utiliza para localizar una dirección

en particular. Los puntos de interés que se muestran en el mapa sirven

como referencia visual para orientar al usuario, presentándose la ruta con

la información pertinente representada mediante símbolos y textos.

MIDP Mobile Information Device Profiles. Perfil para dispositivos móviles de

información.

MMS Multimedia Messaging Service. Servicio de mensajería multimedia. Es un

estándar de para los sistemas de mensajería de las telefonías celulares

que permite el envío de mensajes que incluyen objetos de multimedia

tales como: imágenes, audio, video y texto enriquecido.

PostGIS Módulo que añade soporte de objetos geográficos a la base de datos

objeto relacional PostgreSQL para su utilización en Sistema de

Información Geográfica. Se publica bajo la GNU (General Public License).

PostgreSQL Servidor de base de datos libre desarrollado en su primera versión con el

nombre de Ingres, proyecto desarrollado en la universidad de Berkeley.

Considerado como el referente a los sistemas manejadores de base de

datos libres.

Shapefile Formato de archivo de tipo vectorial con extensión .shp desarrollado por la

empresa Esri para la representación de la información a través de

geometrías y un sistema de referencia espacial.

SRS Spatial Referencing System or Coordinate Reference System (CRS) es

un sistema de coordenadas locales, regionales o globales usados para

localizer entidades geográficas.

SVG Es un lenguaje para describir gráficos bidimensionales en XML. Soporta

tres tipos de objetos gráficos: figuras vectoriales (por ejemplo rutas

formadas por líneas rectas y curvas), imágenes y texto. Estos objetos se

pueden agrupar, estilizar, transformar y componer en nuevos objetos

previamente representados.

URL Uniform Resource Locator. Es una secuencia de caracteres, de acuerdo a

un formato estándar, que se usa para nombrar recursos como

documentos e imágenes en Internet para su localización.

URI Uniform Resource Identifier. Es una cadena corta de caracteres que

identifica inequívocamente un recurso (servicio, página, documento,

dirección de correo electrónico, enciclopedia, etc.). Normalmente estos

recursos son accesibles en una red o sistema.

WAP Wireless Application Protocol. Es un estándar abierto internacional para

aplicaciones que utilizan las comunicaciones inalámbricas, p.ej. acceso a

servicios de Internet desde un teléfono móvil.

Wi-Fi Es un sistema de envío de datos sobre redes computacionales que utiliza

ondas de radio en lugar de cables.

WMA Wireless Messaging API. Es un paquete opcional para J2ME que

proporciona acceso independiente de la plataforma a recursos de

comunicación inalámbrica como SMS.

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.

XML eXtensible Markup Language. Lenguaje de marcado extensible. Es un

meta-lenguaje que permite definir lenguajes de marcado adecuados a

usos determinados. En la práctica corresponde a un estándar que permite

a diferentes aplicaciones interactuar entre sí a través de una red.

CAPÍTULO I

INTRODUCCIÓN En este capítulo se presenta una visión general del tema de investigación, se describe la

problemática que se abordó, el objetivo, la justificación, los beneficios, los alcances y las

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 I Introducción

Página 2

1. Introducción Actualmente las interacciones con las aplicaciones móviles son limitadas por las

restricciones propias de los dispositivos, teniendo los desarrolladores el reto de diseñar

sistemas de mapas para dispositivos móviles, tomando en consideración las restricciones

conocidas para desarrollar aplicaciones de utilidad y de gran impacto en los usuarios.

Las restricciones de los dispositivos incluyen las limitaciones del tamaño de pantalla que

muestra el contenido de mapas descritos por un conjunto de datos, el bajo ancho de

banda para la transmisión de datos que son utilizados para renderizar1 los mapas y el

pobre poder computacional para procesar los datos, [Hampe, 2005].

Es por ello que las investigaciones con respecto a las cuestiones de diseño, interacción y

elaboración de modelos de los servicios de mapas móviles se han incrementado,

dominando los estilos de presentación en los dispositivos móviles, así como las diversas

formas de adaptación y comunicación entre los mismos.

La comunicación a través de dispositivos móviles ha mostrado un crecimiento interesante

como resultado de la facilidad de manejo, la reducción del costo y la disponibilidad de

servicios, abarcando un sector importante en la sociedad. Como resultado del crecimiento

en el uso de dispositivos móviles han surgido nuevas tecnologías y servicios basados en

la ubicación del usuario, es decir, servicios basados en localización (LBS pos sus siglas

en inglés), [LBSWiki, 2009].

Cabe señalar que las aplicaciones implementadas son apoyadas por servicios web, así

como la mayoría de las investigaciones realizadas a la fecha están enfocadas a los

sistemas de navegación utilizando dispositivos GPS (Global Positioning System)

[GPSWiki, 2009] para la transmisión de datos georeferenciales, desarrollando con ello

aplicaciones LBS.

Se propone una innovadora combinación de tecnologías de información dependiente de la

ubicación del usuario, para ofrecer un nuevo tipo de servicios multimedia móvil de valor

agregado. El estudio muestra que los nuevos servicios móviles se pueden desarrollar

utilizando información sobre la localización.

En la investigación de los servicios que prestan los principales proveedores de tecnología

móvil, se puede observar que este trabajo de investigación abarcó todos los servicios con

los que se cuenta actualmente en México.

El resultado de las consultas realizadas por el usuario es un mapa de tipo croquis en

formato vector escalable gráfico tiny [SVG, 2009], se utilizaron conexiones HTTP para

brindar el servicio de envío y recepción, el resultado es un archivo en formato SVG-Tiny

que contiene un mapa tipo croquis que muestra los resultados de la búsqueda contextual,

la parte innovadora de este trabajo es la adopción de métodos para identificar el perfil del

dispositivo celular y en función de sus capacidades se genera un mapa a la medida.

1 El concepto de renderizar en campo de los gráficos por computadora define el proceso de creación de

imágenes sintéticas.


Página 3

1.1 Descripción del problema

Hoy en día las comunicaciones por medio de conexiones HTTP y los servicios de

multimedia MMS son explotados en el envío de diversos tipos de información, tales como:

imágenes estáticas ó dinámicas con texto plano, videos, entre otros.

Asimismo los servicios basados en localización (LBS) están siendo explotados en el área

de la telefonía celular, específicamente en consultas contextuales la respuesta que

obtiene el usuario es enviado mediante mensajes SMS. En el área de Sistemas

Distribuidos de CENIDET se desarrolló una API para la gestión de mapas de navegación

en dispositivos móviles, mediante el sistema GPS y mensajería SMS/MMS, haciendo falta

una aplicación en el lado del servidor que proporcione los mapas a dicha API.

Para esta tesis se realizó una investigación que permitió identificar las limitantes que

tienen los dispositivos móviles, tales como: tamaño de la pantalla, capacidad de

procesamiento y almacenamiento. Aunado a esto, se identificó que el uso de imágenes

comunes tales como: JPG, GIF, BMP tienden a distorsionarse cuando se realizan

acercamientos y alejamientos (zoom-in y zoom-out) además de que el peso del archivo se

considera otra limitante.

En resumen, el problema que se plantea es resolver solicitudes de información de

consultas contextuales mediante el uso de formatos de imágenes compatibles con la

mayoría de las plataformas de dispositivos celulares de última generación, utilizando un

modelo de mapas tipo croquis que identifiquen puntos de interés, que serán

representados por una imagen en función del perfil del dispositivo, siendo la solución

propuesta la siguiente:

Desarrollar un generador de mapas tipo croquis en formato SVG-Tiny, que dé respuesta a

las solicitudes que sean enviadas por el dispositivo móvil haciendo uso de la API2 ,

enviando el mapa mediante solicitudes basadas en conexiones HTTP, que se pueda

visualizar en dispositivos móviles con diferentes características funcionales.

Cabe destacar que al mapa tipo croquis elimina información no pertinente, con el fin de

mostrar al usuario sólo la información necesaria para dar respuesta a la petición realizada.

1.2 Objetivo

Generación de mapas tipo croquis en formato SVG-Tiny considerando información del

perfil del dispositivo, aplicando técnicas de destilado para eliminar información geográfica

no pertinente para el usuario, utilizando el esquema de mensajes de tipo

solicitud/respuesta mediante mensajería de SMS así como conexiones basadas en

HTTP/GRPS.

2 API para la Gestión de Mapas de Navegación en Dispositivos Móviles Mediante el Sistema GPS y

Mensajería SMS/MMS. Desarrollado en el Laboratorio de Sistemas Distribuidos de Cenidet.


Página 4

1.3 Justificación y beneficios

Hoy en día México tiene un gran crecimiento en la telefonía celular, teniendo más énfasis

en las promociones del servicio a bajo costo, el surgimiento de nuevos servicios para los

usuarios en cuanto a promociones vía mensajes SMS y la venta de descargas de archivos

multimedia. COFETEL [COFETEL, 2009] indica que 72 de cada 100 personas tiene al

menos un dispositivo móvil, tal como se muestra en la Figura 1-1, en la cual se puede ver

en una tabla a los usuarios existentes hasta el segundo trimestre del año 2009, y se

puede observar el crecimiento de los usuarios comprendidos desde el año 1990 a la

fecha.

AÑO MILES DE USUARIOS

1990 63.9

1991 160.9

1992 312.6

1993 386.1

1994 571.8

1995 688.5

1996 1,021.9

1997 1,740.8

1998 3,349.5

1999 7,731.6

2000 14,077.9

2001 21,757.6

2002 25,928.3

2003 30,097.7

2004 38,451.1

2005 47,141.0

2006 55,395.5

2007 66,559.5

2008 p/ 75,303.5

ago-09 78,257.3

El uso del servicio de mensajería SMS y MMS ha ido en aumento por los diversos

servicios que se brindan a través de ellos, los primeros brindan servicios de publicidad por

parte de las empresas privadas, mientras que los Mensajes Multimedia están tomando un

alto impacto en los usuarios en la compra-venta de tonos, videos, imágenes, entre otros,

por otro lado los Servicios Basados en Localización (LBS) lo brindan empresas tales como

Google, Multimap, Mapquest, iLocator de Nextel, entre otros, las cuales se tiene acceso

por medio de conexiones vía WiFi y GPRS. Uno de los limitantes en México para brindar

1990

1991

1992

1993

1994

1995

1996

1997

1998

1999

2000

2001

2002

2003

2004

2005

2006

2007

2008 p

/

jun

-09

0.1 0.2 0.4 0.4 0.6 0.8 1.1 1.83.5

8.0

14.2

21.6

25.429.1

36.3

45.1

52.6

62.6

70.372.3

Figura 1-1 Usuarios de dispositivos móviles por cada 100 habitantes


Página 5

servicios de multimedia es el costo, en la Tabla 1-1 se presenta el análisis de costos

mensajería SMS/MMS y GPRS en México.

Tabla 1-1 Costos de mensajería de las telefónicas en México, 2009

Movistar Telcel Iusacell Nextel

SMS $ 0.98 $ 0.85 $1.00 $0.86

MMS $2.00 $ 2.00 $5.00 $3.45

GPRS $0.14 x Kb $0.04 x Kb $0.12 x Kb Incluido en Renta mensual

Como resultado de la limitada capacidad de los mensajes de SMS para transportar

información, en la presente tesis se propone el desarrollo de un generador de mapas en

formato SVG-Tiny, que permita proporcionar un servicio más eficiente al usuario,

presentando el resultado de su consulta en formato gráfico, lo que permite enviar mayor

cantidad de información de manera más amigable y comprensible por el usuario.

Los resultados serán dados de acuerdo a la ubicación y los sitios de interés del usuario,

para ello se debe de ingresar el perfil del usuario, la ubicación se adquiere del dispositivo

móvil, siendo estos datos necesarios para realizar la consulta, asimismo se considera el

perfil del dispositivo y el tipo de tecnología de transmisión de datos por el cual se realiza

dicha comunicación.

Los beneficios que se obtienen al término de este trabajo de tesis son los siguientes:

Generación de mapas tipo croquis en formato SVG-Tiny para dispositivos móviles

en función de la ubicación del usuario.

Ofrecer a los usuarios de telefonía móvil Servicios Basados en Localización (LBS),

haciendo uso de mensajería SMS y WiFi mediante conexiones HTTP/GPRS.

1.4 Antecedentes

Se describen tres proyectos que se consideran antecedentes de este trabajo de tesis que

fueron desarrollados en CENIDET durante el período 2005-2008, los cuales se describen

a continuación:

1. API SMS para el procesamiento de consultas georeferenciadas y no

georeferenciadas [Ruiz, 2007]. El proyecto consta de un conjunto de funciones para

desarrollar e implementar aplicaciones en dispositivos móviles para procesar

consultas dependientes/independientes de la ubicación de un usuario de dispositivos

móviles, utilizando mensajería de SMS y el sistema de posicionamiento global.

Cuando se trata de una consulta georeferenciada, la API es capaz de obtener la

ubicación del cliente móvil a través de un dispositivo GPS. Para ello, la API cuenta

con un paquete llamado Conexión, el cual realiza las tareas de detección y conexión

con el dispositivo GPS así como la extracción de los datos. También cuenta con un

paquete llamado Mensaje, que contiene las clases encargadas de la formación del

mensaje de SMS, su envío y recepción.


Página 6

La API se diseñó en el marco de los servicios basados en localización, los cuales

responden a las preguntas ¿Qué hay cerca de..?, ¿Cómo llego a..?, ¿Qué pasa cerca

de..? y ¿Qué clima hay en..? Con base en lo anterior, identifica cuatro tipos de

objetos:

1. Punto de interés (georeferenciado o no georeferenciado). Para el primer caso, la

localización del usuario se realiza a través de información que obtiene de un

GPS Bluetooth3; para el segundo caso, la localización se realiza a través de

información que el usuario proporciona (calle, número, colonia, código postal,

ciudad).

2. Camino. Sucesión de puntos que unen dos o más lugares.

3. Evento (político, religioso, cultural, etc.).

4. Clima.

2. Gateway SMS Pull para Servicios Basados en Localización con una Arquitectura de

Servicio Web [Quiñonez, 2007]. En este proyecto se desarrolló un gateway (pasarela)

para el procesamiento de mensajes de SMS/MMS identificando si es una consulta

dependiente o independiente de la ubicación del cliente móvil. Una vez identificado el

tipo de consulta, se procesa de manera local o externa sobre una arquitectura que

soporte las tecnologías de los servicios Web.

Los tipos de búsqueda que soporta la arquitectura del gateway mencionado, se

definen mediante un conjunto de palabras clave, cada una representa un servicio

reconocido por el servidor de consultas, y en base a éstas retorna la información

solicitada en el formato adecuado. A continuación se listan las palabras clave

soportadas por el gateway:

Banco

CCamion

Cine

Farmacia

Hospital

Restaurante

SMercado

NPOI (retorna el punto de interés más cercano a la posición del dispositivo móvil,

basado en una búsqueda por radio predefinido).

POI (regresa las palabras claves de los puntos de interés cercanos a la posición

del dispositivo móvil en un radio de 20 a 30 metros).

WIA (retorna la calle y colonia donde se encuentra el dispositivo móvil).

RCORTA (regresa la ruta para llegar al servicio definido por la palabra clave

enviada desde la posición actual del dispositivo).

3 Es una especificación para redes inalámbricas de área personal (WPANs) que hace posible transmitir

voz y datos entre distintos dispositivos mediante un enlace por radiofrecuencia segura y globalmente libre.


Página 7

3. API para la gestión de mapas de navegación de dispositivos móviles mediante el

sistema GPS y la mensajería SMS/MMS [Victoria, 2008]. Se desarrolló una API bajo la

plataforma J2ME para procesar consultas georeferenciadas/no georeferenciadas a

través de mensajes SMS/MMS para representar puntos de interés sobre un mapa

vectorial SVG en un dispositivo móvil, que permita al usuario orientarse de mejor

manera al visualizar e interactuar con la información de referencia solicitada.

Los servicios basados en localización (LBS) así como los mapas de navegación, son

aplicaciones cada vez más comunes en los dispositivos móviles. Es posible

coleccionar datos y atributos geoespaciales para resolver necesidades de ubicación y

orientación de los usuarios. Se desarrolló una API para dispositivos móviles que

permite visualizar e interactuar con información georeferencial representada como

puntos de interés sobre un mapa vectorial SVG que se podrá obtener vía un mensaje

MMS o una conexión HTTP/GPRS. Busca aprovechar la tecnología actual de los

dispositivos móviles como Smartphones y PocketPCs para proporcionar servicios de

localización a los usuarios en un momento determinado, ya sea de manera textual o

gráfica.

1.5 Alcances y limitaciones

1.5.1 Alcances

La aplicación del servidor realiza los puntos siguientes: o Recibe e interpreta la trama de la petición o Realiza peticiones al servidor de mapas. o Para generar el camino se implementa un algoritmo de ruta, en la

obtención de los puntos de referencia es necesario realizar consultas a la base de datos espacial.

o La imagen SVG obtenido del servidor de mapas es convertida al formato SVG-Tiny, se añade el camino y los puntos de referencia.

Las peticiones y el envío del mapa en formato SVG-Tiny es enviado por medio de conexiones HTTP.

1.5.2 Limitaciones

Sólo se muestran los puntos de referencia que cumplan con la condición de

búsqueda del camino generado.

El medio para enviar la respuesta es vía HTTP.

La aplicación cliente está limitado a los dispositivos móviles que soporten

como mínimo la configuración Java CLDC 1.1 (JSR 179) y el perfil MIDP 2.0

(JSR 118).

Los dispositivos móviles deben soportar las siguientes APIs para J2ME:

o Location API(JSR 179),

o Wireless Messaing API 2.0 (JSR 205) y

o Scalable 2D Vector Graphics API (JSR 226).


Página 8

1.6 Estado del arte

En el desarrollo de un proyecto es necesario tomar en cuenta el conocimiento disponible

en la actualidad en torno al tema de investigación, con el fin de que el conocimiento que

se produzca tenga carácter novedoso. En esta investigación se han tomado diversos

trabajos de diferentes centros de investigación.

Se ha realizado un estudio en cada uno de ellos, tomando en cuenta aquellos que están

más relacionados con la temática a tratar, seleccionando los puntos fundamentales, así

como la comparación de dichos puntos mostrando las ventajas que se obtienen como

resultado en esta investigación.

1.6.1 Desarrollo de servicios de rutas de mapas para celulares basados en G-XML

Este proyecto [ichiro, 2002] describe el desarrollo de servicios de rutas de mapas basados

en G-XML para dispositivos móviles, permitiendo al usuario describir diversos datos

espaciales en relación con las mismas condiciones, siendo tecnología clave para el

servicio de mapas móviles.

Figura 1-2 Representación del servicio de rutas

G-XML tiene un impacto mayor para el intercambio de información espacial a través de

Internet, porque es la especificación para codificar la información espacial con XML. En

estas circunstancias hicieron uso de G-XML para desarrollar un servicio de rutas en

mapas para la telefonía móvil como una variedad de la navegación. La característica


Página 9

principal de este servicio es la presentación de un mapa de datos basados en G-XML,

[JIPDC, 2006].

En la Figura 1-2 se muestran los 4 tipos de representaciones en el servicio, las cuales

son:

1. Ruta. Describe una ruta de origen a destino, la información que se muestra es la adecuada para pantallas pequeñas del dispositivo móvil.

2. Lista de etiquetas. Representación mediante iconos para indicar instrucciones de guiado, por ejemplo: seguir a la derecha, izquierda o derecho, para reconocer en donde se encuentra o a donde se debe dirigir.

3. Mapa. Permite a los usuarios reconocer que dirección se debe tomar de manera visual.

4. Descripción general. Presenta el mapa con una ruta indicando el origen y hacia donde se desea ir.

El procedimiento para generar la ruta de los mapas mostrado en la Figura 1-3 se

desarrolla en tres etapas:

Primera etapa. Buscar la ruta óptima desde el principio hasta el fin. Al mismo tiempo se obtienen los nodos y los enlaces de la ruta.

Segunda etapa. Se especifican las posiciones de los nodos y los vínculos (NodeRelativePoint y m) de la ruta como un elemento S-GXML y se representa mediante una sentencia, lista de símbolos o un mapa.

Figura 1-3 Procedimiento para generar la ruta del mapa

1.6.2 Mapas adaptivos para aplicaciones móviles

En este proyecto Hampe se enfoca en las limitaciones de los dispositivos móviles tales

como: pantallas pequeñas y capacidad limitada de memoria. Teniendo estas limitaciones

se asegura una carga de información mínima, utilizando técnicas y experiencia de diseño

de interfaces de usuarios útiles, [Hampe, 2005].

Las características y restricciones de los dispositivos móviles, tienen un gran impacto

sobre el diseño de las interfaces de usuario. Para ello se diseñan presentaciones visuales

sujetas a un número de restricciones, siendo las más relevantes los siguientes:

Resolución limitada. Restricción clave que debe ser dirigida mediante diseñadores

de interfaces.

Búsqueda de ruta

Obtener nodo y enlazarlo con

una ruta

Obtener nodo relativo con una

ruta

Renderizando (Sentencia, lista puntos de

interés, mapa simple)

S-GXML

Datos espaciales

Datos de la ruta

ID Nodo, ID Enlace


Página 10

Tamaño de pantalla. Restricción para aplicaciones que son encaminados a

diversos usuarios en donde se consideran los posibles problemas de visión.

Número de colores disponibles. Es relevante para el diseño de la presentación

visual, porque limita el uso de color para información y la aplicabilidad de técnicas

basadas en transparencias, que pueden ser utilizadas en diversas capas de

información y

Poder de procesamiento. Restringe la interactividad de animaciones en tiempo real

y la generación de gráficos complejos en pantalla.

Adicionalmente las diferencias introducidas mediante un contexto móvil de uso está

relacionado a lo siguiente:

Ambiente auditivo. Puede ser limitado si el dispositivo es usado en un ambiente

público, ya que el ruido del ambiente puede enmascarar la salida del sonido o

cuando el sonido de la aplicación es indeseable (museo, biblioteca, etc.),

Ambiente visual. Los dispositivos móviles pueden ser usados en varios contextos y

rangos desde el oscuro total hasta la luz solar en aplicaciones al aire libre.

Nivel de atención. Las aplicaciones móviles se utilizan en cualquier lugar, por lo

que el nivel de atención del usuario es mínima y podría ser limitado o la interacción

del usuario podría ser interrumpida por atender eventos externos.

Un mapa adaptivo implica acomodarse a las especificaciones necesarias y requerimientos

del usuario y al dispositivo móvil. El sistema tiende a decidir acerca de la relevancia de

información para cada usuario y cada uso. Para determinar las preferencias del usuario,

se puede identificar la cantidad de información que se puede dar en la respuesta. Como

no existen muchos usuarios expertos el sistema puede decidir automáticamente qué

información es relevante para cierto usuario en cierta situación.

Reichenbacher [Reichenbacher, 2004] identifica cuatro dominios de adaptación:

Dominio de información

Dominio de interfaz de usuario

Dominio de presentación

Dominio de tecnología

Basado en ello se determinaron los posibles objetos de adaptación. Siendo los siguientes

subconjuntos los se ajustan al proceso:

Visualización

o Diseño del mapa

o Sección del mapa

o Escala del mapa

o Generalización del mapa

o Dimensión

o Elementos gráficos

Geo información

o Cantidad

o Clasificación

o Nivel de detalle

o Área geográfica

Interfaz de usuario


Página 11

1.6.3 Mejorando las direcciones de ruta en dispositivos móviles

Este proyecto se enfoca en el descubrimiento de rutas para dispositivos móviles y trata de

describir cómo se llega al objetivo destino desde un estado inicial en el mundo real. Las

rutas tienen un alto nivel de descripción y proporciona un método para llevar a cabo la

instrucción de mayor prioridad. Se enfoca en las propiedades salientes del entorno y la

vista de rutas en un alto nivel de abstracción, siendo aspectos claves en el proceso de

guía en las rutas, dando como consecuencia el entendimiento de instrucciones

complejas, [Sabine, 2004].

La ruta se segmenta y se resume de manera significativa para ser representada mediante

un lenguaje de marcado. La estructura de la segmentación se desarrolló en un generador

jerárquico y las heurísticas son usadas para la identificación de segmentaciones

apropiadas.

Figura 1-4 Segmento de ruta presentado vía Web

Desarrollaron un lenguaje de marcado llamado RPML (Route Plan Markup Language) que

les permite entregar combinaciones de diferentes modalidades (texto, gráfico, y

eventualmente también voz). El mecanismo mencionado de segmentación produce

estructuras RPML como estructura de salida, a su vez usan XLST para entregar una ruta

completa vía Web (ver Figura 1-4), mientras que la Palm permite hacer exploración

interactiva paso a paso de la descripción cuando los usuarios realizan la tarea de

navegación como se muestra en la Figura 1-5.

Figura 1-5 Descripción de ruta


Página 12

En resumen, no proporciona suficiente información para que el conductor pueda encontrar

la ruta correcta hacia el destino, excepto en el camino de regreso al punto de partida.

1.6.4 Sistema de soporte para contenido multimedia dinámico personalizado en

dispositivos móviles

Este proyecto tiene por objetivo representar mapas y rutas en tiempo real, para ello el

operador toma una imagen de tamaño arbitrario de una ciudad como entrada que

representa el mapa de la ciudad, una lista de puntos que consta de un ID y un factor x el

cual representa una posición global en el espacio para re-calcular las posiciones de los

puntos de interés en el mapa, [Scherp, 2004].

Para aprovechar al máximo la utilización de las pantallas de los dispositivos móviles,

utilizan los medios de comunicación para la visualización en el dispositivo móvil y, por

consiguiente, la cantidad de datos que se transfiere por medio de la red inalámbrica se

reduce.

Figura 1-6 Navegación de mapas en PDA (CityMap)

Los medios de comunicación son pertinentes a las limitaciones técnicas del dispositivo

móvil y de acuerdo al entorno del usuario, tal como ubicación, hora del día, el clima, o el

ruido. En lo que respecta a la ubicación, el usuario recibe sólo la presentación multimedia

de la vista. Además, si el entorno durante una visita de la ciudad es demasiado ruidoso,

los medios de comunicación audibles no son seleccionados para la presentación, sólo los

medios de comunicación visual.

La aplicación CityMap mostrada en la Figura 1-6 pregunta por los objetos multimedia que

coincidan con la preferencia de los intereses del usuario. Si el perfil de usuario cambia

durante la visita de la ciudad, la ruta es personalizada eliminando o añadiendo lugares de

interés turístico en el mapa.

Se desarrollaron generadores de SMIL, SVG, y HTML en el contexto de presentaciones

multimedia, considerando la limitación de los dispositivos móviles por medio de la

determinación de los perfiles que son especialmente diseñados para uso en dispositivos

móviles.


Página 13

El perfil SVG-Tiny está destinado a multimedia para dispositivos móviles y el SVG-Basic

tiene por objeto el perfil de las computadoras de bolsillo como PDAs y computadoras de

mano.

En la Figura 1-7 se muestra la arquitectura cliente-servidor de CityMap, la información

sobre el perfil del usuario, los medios de comunicación y los metadatos se obtienen desde

Internet utilizando la red inalámbrica y en bases de datos.

Figura 1-7 Arquitectura de MM4U

1.6.5 Visualización Adaptiva de información geográfica en dispositivos móviles

En este trabajo se establece un punto de vista del marco conceptual para cartografía

móvil y la visualización de adaptación de información geográfica a dispositivos móviles. La

investigación se extiende enriqueciendo la teoría cartográfica, así como los métodos en el

ámbito de la información geográfica, comunicación en entornos móviles y los métodos de

adaptación para la visualización cartográfica en los dispositivos móviles.

Las soluciones cartográficas en un entorno móvil se centran en el uso de información

geográfica en ambientes urbanos, siendo como principal objetivo comunicar en forma de

aprendizaje (rutas, áreas forestales, etc.) o para explorar información geográfica mediante

los dispositivos móviles. Se hace hincapié en el apoyo de las actividades cotidianas de los

usuarios móviles, ofreciendo presentaciones de información no intrusiva tomando

decisiones rápidas. La siguiente lista describe los objetivos generales:

Proporciona un marco de trabajo para la cartografía móvil y geovisualización adaptable.

Identifica los enlaces e interfaces para relacionar métodos de geovisualización.

Los objetivos específicos incluyen:

Desarrollo de métodos de adaptación para geovisualización. Demostrar el potencial del SVG para móviles y geovisualización adaptables. Desarrollo de un prototipo que brinde servicios de geovisualización móvil.

La adaptación se lleva a cabo en los componentes de las actividades relacionadas con los

objetivos. Los usuarios demandan los servicios mediante solicitudes al servidor web

consumiendo datos geoespaciales, dando como resultado un archivo en el lenguaje de

marcado geográfico (GML), mismo que se transforma mediante el lenguaje de

transformación de estilo extensible (XSLT) a un documento en formato vector gráfico

PDA usando PoketSMIL

WinCE

HHC usando SVGBasic

Player

Celular móvil con

SVGTiny

Internet

Aplicación

multimedia

personaliza

da

Servidor Cliente móvil


Página 14

escalable (SVG). Las adaptaciones del documento SVG pueden ser manipulados

mediante el modelo objeto-documento (DOM).

Aunque el progreso de la tecnología en el campo de la computación móvil es significante

y la investigación está dirigida a los móviles con información geográfica, son varios los

problemas aun sin resolver y muchos conocimientos que se van adquiriendo al

desarrollar soluciones móviles para el contexto que se describe a continuación:

Geovisualización. La visualización en los dispositivos móviles está limitado por el

tamaño y resolución de la pantalla, la falta de poder de procesamiento, la

memoria, la duración de la batería y el ancho de banda de la red móvil.

Usabilidad. El uso de las soluciones móviles se obstaculiza por el uso de mapas

escaneados o la producción ilegible de mapas con resoluciones que no soportan

los dispositivos móviles.

Lectura ilegible. La limitación de las pantallas pequeñas implica que no hay lugar para elementos auxiliares tales como un mapa leyenda, lo que hace que la lectura de mapas sea un proceso difícil.

Movilidad. La movilidad del usuario tiene muchas consecuencias, el uso de la información geográfica se ve afectada por los cambios de ubicación del usuario, las diferentes actividades, asimismo se tienen diferentes distracciones en un entorno público siendo rápidos los cambios de contexto haciendo más difícil las condiciones de uso.

1.6.6 gvSIG para dispositivos móviles

gvSIG Mobile es una herramienta para dispositivos móviles, siendo sus características

principales las siguientes: soporte de los formatos de imágenes más utilizados para

almacenar datos geográficos, el acceso a diversas bases de datos, los servicios de

mapas, manipulación de datos vectoriales y ráster. Tiene la funcionalidad de un

visor/editor de cartografía con un módulo de GPS para la auto-localización de puntos de

interés mediante servicios remotos [Montesinos, 2008].

En la Figura 1-8 se muestra la interfaz de usuario del sistema en el que se incorpora el

concepto de grupo de barras de herramientas y un sistema de ayuda contextual.

Figura 1-8 Interfaz de usuario de gvSIG Mobile


Página 15

Este proyecto es una extensión de gvSIG desktop que permite enviar datos a gvSIG

Mobile, configurar los aspectos de visualización de capas, definir formularios

personalizados y revisar las modificaciones realizadas por gvSIG Mobile, en la Figura 1-9

se muestra la sincronización de datos desde gvSIG desktop.

Figura 1-9 Sincronización de datos desde gvSIG desktop

1.6.7 Sistema de Información Geográfica basado en SVG

El Sistema de Análisis de Información Geográfica (GIAS), es un sistema autónomo que

utiliza técnicas de gráfico renderizado para aplicaciones locales. Describe una estructura

interna en la que se incluye la base de datos, los mecanismos de extracción de

información, el tratamiento de datos y su mantenimiento. Se expande mediante el

desarrollo de funciones para su uso en la Web a través de la utilización de los SVG.

Demuestra que el SVG tiende a ser una herramienta de gran alcance, siendo un reto para

la interfaz de programación de gráficos en la web, [Cabral, 2005].

GIAS fue desarrollado en la plataforma Borland Delphi 6, la arquitectura que proponen se

muestra en la Figura 1-10, describiendo de manera general el sistema.

La base de datos contiene información acerca de la ubicación real de toda la región en

estudio, así como las imágenes geométricas presentable de la región.

El uso del formato SVG permite representar tres tipos de objetos gráficos: formas de

vectores (definidos por líneas rectas y curvas), imagen y texto. Los vectores de objetos

tienen información sobre las curvas y líneas de una imagen, en lugar de información

acerca de los pixeles que componen la misma. Se utiliza la técnica de la agrupación en

capas, por lo que es posible tener en un dominio los elementos que tienen características

similares.


Página 16

Figura 1-10 Arquitectura de GIAS

En la figura anterior el módulo de “Administración y registro de datos” es el responsable

de aplicar los intercambios y la manipulación de datos a través de la Web. El componente

“Servidor de mapas” es utilizado con el fin de extraer información de la base de datos y

generar datos en SVG (véase Figura 1-11) utilizando la información extraída, teniendo

como resultado un mapa en formato SVG.

Figura 1-11 Creación de archivo SVG

1.6.8 Procesando datos interoperables por Aplicaciones Geoespaciales Móviles

En este proyecto se propone una arquitectura de servicio para integrar clientes móviles a

una infraestructura de datos espaciales (SDI4 por siglas en inglés). Esta arquitectura

permite proveer mapas y objetos geoespaciales acorde a los requerimientos del

dispositivo móvil, apoya las fases locales (offline) y suministra documentos de contexto

que contienen información de los servicios relevantes, [Brinkhoffi, 2008].

Observan que existen diferencias en sus interfaces de usuario y en su rendimiento

tomando en cuenta las diversas categorías de dispositivos móviles, las plataformas y los

sistemas operativos, Por lo que no se asume que los servicios web geoespaciales

4 SDI: Spatial Data Infrastructure


Página 17

puedan ser usadas como aplicaciones tradicionales. Es por ello que se adaptan los

resultados de los servicios a las necesidades de los dispositivos móviles. Estos

tratamientos se pueden hacer mediante:

1. Llamadas a los servicios SDI con un conjunto de parámetros para los

requerimientos del cliente móvil y/o

2. Modificando los resultados de los servicios SDI para simplificar o procesar

posteriormente mediante el móvil cliente.

La Figura 1-12 representa la arquitectura que provee mapas y datos. Las flechas indican

el flujo de datos. Para determinar los parámetros correctos para llamar a los servicios SDI

y para procesar sus resultados, una base de datos para administrar el perfil de cada tipo

de dispositivo.

Figura 1-12 Arquitectura para integrar aplicaciones móviles especificando dispositivos al SDI

El prototipo es desarrollado e implementado para la administración de desastres, dirigido

a dispositivos móviles tales como PDA‟s o Tablet PCs. La aplicación móvil consiste de los

siguientes módulos: el componente de visualización que consta de datos almacenados,

sensores e interfaces de comunicación, la Figura 1-13 representa los principales

componentes del prototipo.


Página 18

Figura 1-13 Principales componentes del prototipo del cliente móvil

La estructura de datos del componente de visualización está basada en un documento

SVG, en la Figura 1-14 se representan las capas que son mapeadas, en donde cada capa

corresponde a un elemento imagen del documento SVG.

El administrador de capas es el responsable de visualizar las texturas de las capas

visibles en respuesta de eventos de los dispositivos de entrada como puede ser un

dispositivo señalador, un ratón o un lápiz óptico.

Figura 1-14 Representación y visualización de datos


1.6.9 Tabla comparativa del estado del arte

A continuación se muestra la Tabla 1-2, en donde se compara los trabajos relacionados con el proyecto de investigación. Se puede

observar que todos los trabajos están enfocados a lo siguiente: al desarrollo de sistemas LBS, generar las rutas de los mapas, el

medio de transmisión de datos mediante GPRS y HTTP. Una ventaja del proyecto es el envío de mensajería SMS obteniendo la

respuesta por medio de conexión HTTP, teniendo como resultado un archivo en formato SVG-Tiny, que tiene la característica de

mostrar mapas estáticos, en 3D, audio y video5, otro punto a destacar es J2ME como lenguaje de desarrollo, esto nos permitió

desarrollar el proyecto sin depender de algún software propietario, dando un enfoque heterogéneo al resultado que sean enviados a

la mayoría de los dispositivos móviles.

Tabla 1-2 Comparativa de los trabajos del estado del arte

PROYECTO ORIENTADO

A LBS LENGUAJE DE DESARROLLO

GENERA RUTA

SOPORTE DE MENSAJERIA MEDIO DE

TRANSPORTE FORMATOS

SMS MMS

[ichiro,2002] S-GXML HTTP SVG-Tiny

[Hampe, 2005] No especifica HTTP SVG-Tiny

[Sabine, 2004] Windows Mobile /

RPML, XSLT GPRS | HTTP XSLT

[Scherp, 2004] Windows Mobile / WFS, WMS, WMC HTTP SMIL, SVG-Tiny

[Reichembacher, 2004] J2ME / GML

GPRS | UMTS, HTTP

SVGB

[Montesinos, 2008] J2ME/

WMS, WFS HTTP-WMS

ECW, JPEG, PNG, GIF

/SHP

[Cabral, 2005] DELPHI 6 /

XML HTTP SVG

[Brinkhoffi, 2008] VC++ NET GPRS | HTTP-

WMS SVG

Proyecto de tesis J2ME GPRS | HTTP -

WMS SVG-Tiny

5 http://www.w3c.es/Prensa/2006/nota060810_SVGTiny


Página 20

1.7 Organización del documento

El documento de tesis se organizó en 6 capítulos cada uno de los cuales presenta la

siguiente información:

Capítulo II Marco Teórico. Describe los conceptos principales del tema de investigación

que facilitarán la comprensión del presente trabajo.

Capítulo III Análisis y Diseño. En este capítulo se presenta el análisis y diseño realizado

para desarrollar el sistema. Para ello se describe la arquitectura, los diagramas de casos

de uso, diagramas de actividad, diagramas de secuencia y los diagramas de clases.

Capítulo IV Implementación. En este capítulo se describen las clases implementadas que

muestran la funcionalidad del sistema.

Capítulo V. Presenta las pruebas y los resultados obtenidos que permitieron verificar el

funcionamiento de la aplicación web SketchMapServer de acuerdo a un plan de pruebas

elaborado conforme al estándar IEEE 829-1998.

Capítulo VI. Presenta las conclusiones, aportaciones y trabajos futuros de la investigación

realizada en esta tesis, de acuerdo a los resultados obtenidos y experiencia adquirida.

Anexos. Contiene el Análisis para representar puntos de interés, el estudio de plataformas

móviles (Sistemas operativos y Lenguajes de programación), el Plan de Pruebas

elaborado y un estudio del formato SVG.

CAPÍTULO II

MARCO TEÓRICO En este capítulo se presentan los conceptos relevantes en el desarrollo del proyecto, lo

que se está desarrollando en la misma área de investigación.

Capítulo II Marco teórico

Página 22

2. Marco teórico

2.1 Mapa tipo croquis

Mapa tipo croquis se define como una representación gráfica de la ubicación exacta de

una dirección o lugar que se está localizando por medio de coordenadas o puntos de

referencia, básicamente se utiliza para localizar una dirección en particular. Los puntos de

interés que se muestran en el mapa sirven como referencia visual para orientar al usuario,

presentándose la ruta con la información pertinente representada mediante símbolos y

textos.

Figura 2-1 Representación de un Mapa tipo croquis

En la Figura 2-1 se representa un mapa tipo croquis en donde el punto inicial “A” parte de

la calle Adolfo López Mateos doblando por la Úrsulo Galván para finalmente llegar a la

calle Gustavo Díaz Ordaz donde se localiza el punto destino “B”, también se observa que

en el trazado de la ruta se presentan puntos de referencia para orientar a las personas.

2.2 LBS. Servicios basados en localización

Las NICTs (New Information and Communication Technologies, Tecnologías Nuevas de

Información y Telecomunicación), describe a los LBS como una intersección entre:

sistemas y dispositivos móviles, Internet y GIS (Geographic Information Systems,

Sistemas de información geográfica) con base de datos espaciales, [Steiniger, 2006].

Figura 2-2 Áreas que conforman los LBS

A

B


Página 23

En la Figura 2-2 se observa que existen algunas características en común entre los LBS y

los GIS, tales como el manejo de datos con referencia posicional y funciones de análisis

espacial, las cuales responden preguntas como: ¿Dónde estoy…? ¿Qué está cerca

de…? ¿Cómo puedo llegar a…?

Sin embargo los LBS y los GIS tienen diferentes orígenes y grupos de usuarios.

Los GIS han sido desarrollados durante varias décadas en base a aplicaciones de datos

geográficos profesionales, mientras que los LBS surgieron recientemente por la evolución

de servicios móviles públicos. En lo que se refiere a grupos de usuarios, los GIS pueden

ser vistos como un sistema profesional y tradicional, destinado a usuarios con amplia

experiencia en sistemas geográficos, además de que consumen extensos recursos de

cómputo.

En contraste los LBS se desarrollaron como servicios limitados para un gran número de

usuarios no profesionales. La aplicaciones LBS operan con las restricciones del ambiente

de cómputo móvil como baja potencia computacional, pantallas pequeñas, o limitaciones

debidas al alto consumo de batería.

2.2.1 Componentes de los LBS

Los elementos necesarios para el funcionamiento de los LBS se muestran en la Figura

2-3, [Magon, 2006].

Figura 2-3 Componentes básicos LBS

Posicionamiento o localización. Se refiere a la forma de determinar la posición del

dispositivo móvil. Existen distintas tecnologías de posicionamiento entre las que destacan

las basadas en red y las basadas en dispositivos,

Datos geográficos. Se refiere al GIS que funciona como una base de datos con

información geográfica (datos alfanuméricos) que se encuentra asociada por un

identificador común a los objetos gráficos de un mapa digital. De esta forma, señalando

un objeto se conocen sus atributos e, inversamente, preguntando por un registro de la

base de datos se puede saber su localización en la cartografía.


Página 24

Red de comunicaciones. Se refiere al medio de transporte de datos. La información de

ubicación puede enviarse por medio de SMS o de datos utilizando GPRS.

Centro de control. Es el administrador de los datos, recibe la información de ubicación,

accede al GIS para poder satisfacer los requerimientos del usuario y envía la respuesta.

2.2.2 Funcionamiento

A continuación se describe del funcionamiento de los sistemas basados en localización:

1. Se obtiene la posición del dispositivo móvil y se envía la solicitud, la cual contiene

el objetivo de la búsqueda y la ubicación del usuario, ésta se envía a través de la

red de comunicaciones a un determinado servidor de consultas contextuales.

2. El servidor tiene la tarea de intercambiar mensajes entre la red de comunicación e

Internet. Encamina la solicitud a un servidor específico. El servidor guarda

información acerca del dispositivo que ha solicitado la información.

3. El servidor de aplicaciones lee la solicitud y activa el servicio apropiado.

4. El servicio analiza nuevamente el mensaje y decide que información adicional

necesita, además del criterio de búsqueda y posición de usuario.

5. El servicio encontrará la información necesaria que satisfaga la solicitud.

6. Teniendo toda la información necesaria, el servicio hará una consulta de ruteo,

para obtener la respuesta a la solicitud. Una vez obtenida la respuesta esta se

envía al usuario.

Los resultados se pueden presentar al usuario ya sea como una lista de texto, o un dibujo

en un mapa.

Figura 2-4 Funcionamiento LBS

2.2.3 Clasificación

Los LBS se pueden clasificar según las necesidades que satisfacen. En la Tabla 2-1 se

resumen las necesidades que satisfacen los LBS, [Steiniger, 2006].

Posicionamiento

GPS

Red de

comunicaciones

Internet Servidor

Envío de SMS

BD

Dispositivos móviles


Página 25

Tabla 2-1 Necesidades de los usuarios móviles

Acción Preguntas Operaciones

Orientación y localización. ¿Dónde estoy? ¿Dónde está…?

Posicionamiento, geocodificación.

Navegación a través de espacio, trazado de ruta.

¿Cómo puedo llegara? Posicionamiento, geocodificación, ruteo.

Búsqueda de personas y objetos.

¿Qué hay cerca o de interesante…?

Posicionamiento, geocodificación, cálculo de distancia y área, búsqueda de relaciones.

Identificación y reconocimiento de personas u objetos.

¿Qué es? Directorio, selección, búsqueda temática o espacial.

Verificación de eventos, determinación del estado de objetos.

¿Qué ocurre aquí, allá, etc.?

Posicionamiento, cálculo de área, geocodificación, búsqueda de relaciones.

En la Figura 2-5 se muestra la clasificación de los LBS según las necesidades que

satisfacen.

Figura 2-5 Clasificación de los LBS


Página 26

2.3 Sistema de información geográfica

Los sistemas de información geográfica por sus siglas en inglés Geographic Information

System(GIS), son una tecnología para el manejo de información geográfica. Son un

conjunto de herramientas que permiten manejar eficientemente datos espaciales junto con

sus características alfanuméricas asociadas. Otra definición es la siguiente: un software

GIS se asemeja a un programa de base de datos, ya que analiza y relaciona información

almacenada bajo la forma de registros, con una diferencia crucial: cada registro en una

base de datos GIS contiene información que permite dibujar formas (normalmente un

punto, una línea, o un polígono) también denominada información espacial [Quiñonez,

2007].

El objetivo primordial de un GIS es abstraer la complejidad del mundo real a una

representación simplificada entendible para el lenguaje de las computadoras actuales.

Este proceso tiene diversos niveles y comienza con la concepción de la estructura de una

base de datos organizada generalmente en capas.

En los GIS existen relaciones espaciales entre los objetos geográficos que el sistema no

puede obviar; es lo que se denomina topología y se utiliza en la definición de las

relaciones espaciales entre los objetos geográficos. Los sistemas de información

geográfica se clasifican en dos categorías vectoriales y ráster que cuentan con

características diferentes para su procesamiento y utilización.

Los GIS representan toda una realidad en diversas capas, distinguidas principalmente en

tres tipos:

i. Puntos. Representan entidades únicas como: individuos, árboles, carros, ciudades y/o cualquier entidad que pueda representarse mediante un punto.

ii. Líneas. Representan entidades como carreteras, calles, ríos etc. iii. Polígonos. Representan cualquier superficie que tenga un perímetro, por ejemplo:

estados, municipios, países, colonias, cuadras etc. Las consultas espaciales se pueden realizar mediante operaciones geométricas definidas

en [SFS, 2009], se obtiene información sobre objetos se encuentran cerca, la distancia

entre ellos, que objetos se encuentran dentro de una geometría y la relación entre

geometrías de distinta topología, en la Figura 2-6 se muestran las operaciones de

geometrías sobre las entidades GIS.

En las definiciones siguientes el término P se utiliza para referirse a dimensiones

geométricas 0 (Points y MultiPoints), L se utiliza para referirse a una dimensión

geometrías (LineStrings y MultiLineStrings) y A se utiliza para referirse a las geometrías

en dos dimensiones (Polígonos y MultiPolygons).


Página 27

Figura 2-6 Operaciones de geometría

Operación toque. Son relaciones entre dos geometrías a y b se aplica a los A/A, L/L, L/A,

P/A y P/L de los grupos de relaciones, pero no a la relación P/P grupo.

Operación cruce. La relación se aplica a los cruces de P/L, P/A, L/L y situaciones L/A.

Operación en. La relación se aplica a las intersecciones de dos geometrías a y b

resultando b contenido en a.

Operación traslape. Se define entre dos geometrías para situaciones en las que se

tengan A/A, L/L y P/P.

2.3.1 GIS Vectoriales

Son GIS que utilizan vectores definidos por pares de coordenadas relativas a algún

sistema cartográfico para la descripción de los objetos geográficos. Con un par de

coordenadas y su altitud gestionan un punto, con dos puntos generan una línea y con una

agrupación de líneas forman polígonos. En la Figura 2-7 se muestra cómo se estructura la

información geográfica dentro de tablas en algún manejador de base de datos que

permita el tratamiento de esta información [Ortiz, 2001].


Página 28

Figura 2-7 Representación de un mapa vectorial

En el modelo de datos vectorial los objetos se describen como puntos, líneas o áreas

(polígonos). Estos elementos existen como elementos geométricos no como objetos

físicos. Este modelo es adecuado cuando trabajamos con objetos geográficos con límites

bien establecidos, como pueden ser fincas, carreteras, puntos de interés etc.

2.3.2 GIS Raster

Los Sistemas de Información Raster basan su funcionalidad en una relación de vecindad

entre los objetos geográficos. Su funcionamiento se basa en dividir la zona en una retícula

o malla de pequeñas celdas (pixel) y atribuir un valor numérico a cada celda como

representación de su valor temático. Debido a que la malla es regular (el tamaño del pixel

es constante) y se conoce la posición en coordenadas del centro de cada una de las

celdas, se puede decir que todos los pixeles están georeferenciados [Ortiz, 2001].

Figura 2-8 Representación de un mapa ráster

El inconveniente de estos sistemas es que a mayor número de filas y columnas en la

malla (más resolución), existe mayor esfuerzo en el proceso de captura de la información

Código de las celdas: 1 = Bosque 2 = Carretera 3 = Casa


Página 29

y mayor costo computacional a la hora de procesar la misma. La Figura 2-8 muestra la

representación de éste tipo de GIS.

Los datos de un mapa ráster se visualizan como una rejilla sobrepuesta sobre un terreno.

Cada celda almacena un código que describe el terreno de una celda en particular. El

modelo de datos ráster es útil en la descripción de objetos geográficos con límites difusos,

por ejemplo: la dispersión de una nube de contaminantes, o los niveles de contaminación

de un acuífero subterráneo, donde los contornos no son absolutamente nítidos; en esos

casos, el modelo ráster es más apropiado que el vectorial.

2.4 Imágenes Gráficos Vectoriales Escalables (SVG)

Como se explica en [SVG, 2009], SVG es un lenguaje para describir gráficos

bidimensionales en XML. Soporta tres tipos de objetos gráficos: figuras vectoriales (por

ejemplo rutas formadas por líneas rectas y curvas), imágenes y texto. Estos objetos se

pueden agrupar, estilizar, transformar y componer en nuevos objetos previamente

representados.

SVG se utiliza en diversas áreas incluyendo gráficos Web, animaciones, interfaces de

usuario, aplicaciones móviles, entre otros. Sus principales características son las

siguientes [Devmobi, 2007]:

Forma compacta de representar gráficos vectoriales.

Son gráficos escalables, es decir, es posible aumentar o modificar su tamaño arbitrariamente sin pérdida de calidad.

Es un estándar abierto, es una recomendación de W3C (Wide Web Consortium).

Está basado en XML (Extensible Markup Language).

SVG se integra con otros estándares como DOM6 (Document Objetc Model) y XSL (Extensible Stylesheet Language).

SVG surgió para cubrir las necesidades de diversos casos de uso para gráficos

bidimensionales orientados a computadoras de escritorio; sin embargo, la industria móvil

se unió al grupo de trabajo de W3C para especificar un perfil dirigido a dispositivos

móviles. Estas demandas originaron inicialmente dos perfiles SVG: SVG Full y SVG

Mobile.

La especificación SVG Mobile está dirigida a dispositivos de recursos limitados y es parte

de la plataforma 3GPP para la tercera generación de teléfonos móviles. Un único perfil

móvil no es suficiente para una gran variedad de dispositivos debido a las distintas

características en términos de velocidad de CPU, memoria y soporte de colores. Por esta

razón, se definieron dos perfiles dirigidos al amplio rango de familias de dispositivos:

SVG Basic. Es un subconjunto estricto de SVG Full, es decir, los gráficos que se realizan en SVG Basic son compatibles con SVG Full, está dirigido a PDAs y dispositivos móviles de última generación con capacidades avanzadas.

6 Es un modelo computacional a través del cual los programas y scripts pueden acceder y modificar

dinámicamente y en tiempo real el contenido, estructura y estilo de los documentos HTML y XML.


Página 30

SVG Tiny. Es un subconjunto estricto de SVG Basic, es decir, los gráficos que se realizan en SVG Tiny son compatibles con SVG Basic y Full, está dirigido a dispositivos móviles de capacidades limitadas.

Figura 2-9 Perfiles SVG

Los perfiles SVG se pueden mostrar como una pirámide que represente las capacidades

computacionales de los dispositivos para los cuales está dirigido un perfil en específico

así como las características SVG que soporta (ver Figura 2-9). En la parte alta y media de

la pirámide se encuentra el conjunto de características de los teléfonos móviles y PDAs y

en la base, el conjunto de características correspondientes a una computadora de

escritorio.

La principal diferencia entre SVG Tiny y SVG Basic es que SVG Tiny no proporciona

soporte para scripts y definición de estilos. Esto para evitar desbordamiento de memoria

al mantener el modelo de objeto del documento (DOM) en anexo D se describe de forma

extensa el formato SVG en específico el perfil Mobile.

2.5 Mensajería SMS

De acuerdo con la definición de [Roldán, 2005], el servicio de mensajes cortos SMS

(Short Message Service) permite enviar mensajes compuestos por un máximo de 140

bytes (el número de caracteres depende de la codificación que se utilice).

Un mensaje SMS se compone por una cabecera en la que se indican datos relativos al

protocolo de transmisión del mensaje (dirección de origen, tipo de codificación, etc.) y el

cuerpo del mensaje que contiene el texto que se transmite (ver Figura 2-10).

1120 bits Codificación de 7 bits: 160 caracteres (mensaje de texto latino). Codificación de 6 bits: 140 bytes (mensaje de datos). Codificación Unicode: 70 caracteres (mensaje de texto griego o árabe).

Perfil

MOBILE

Perfil

FULL

DATOS CABECERA

Figura 2-10 Estructura de un mensaje SMS.


Página 31

El servicio SMS emplea los canales de señalización y control de la red GSM. La

comunicación a través de un mensaje SMS es una comunicación en tiempo diferido, es

decir, que no existe ninguna conexión directa entre los dos extremos. De hecho, la red

almacena el mensaje antes de enviarlo durante un corto espacio de tiempo (generalmente

entre 0,5 y 2 s).

Las aplicaciones más comunes de los SMS son las destinadas al público en general. Es

posible clasificarlas en cuatro grandes grupos:

Información. Envío de información al usuario sobre algún tema en concreto como:

horóscopo, eventos deportivos, noticias, clima, entre otros (requiere suscripción).

Personalización. Descarga de logos, melodías, fondos de pantalla, imágenes,

fotos, etc.

Chat. Consiste en el intercambio de mensajes SMS.

Entretenimiento. El usuario que envía un SMS participa en un juego, concurso, sorteo, etc.

2.6 Mensajería MMS

MMS (Multimedia Messaging System) es una evolución de SMS para enviar mensajes

multimedia. MMS ofrece mayor flexibilidad en el contenido del mensaje ya que, además

de mensajes de texto, soporta otro tipo de formatos (sonidos, animaciones, imágenes,

etc.) e integra otros servicios de mensajería como el correo electrónico o los mensajes de

voz. El usuario puede escribir el mensaje MMS desde su teléfono móvil, su computadora,

su PDA o cualquier otro dispositivo con un cliente MMS instalado [Roldán, 2005].

El servicio MMS permite adjuntar archivos y como valor añadido y diferenciador permite

utilizar presentaciones animadas. Esto es posible mediante la inclusión de un elemento de

presentación llamado SMIL (Synchronized Multimedia Integration Language). El mensaje

se puede componer por varias páginas consecutivas, denominadas slides, cada una con

un tiempo de presentación que se determina al formar el mensaje (ver Figura 2-11). Cada

slide contiene uno o varios de los siguientes campos: texto, imágenes (simples o

animadas), sonido e incluso vídeo.

Figura 2-11 Esquema de composición de páginas en un mensaje MMS.


Página 32

MMS es un estándar abierto, especificado por el Foro WAP (Wireless Application

Protocol) y 3GPP (Third Generation Partnership Project). La especificación de 3GPP

define la arquitectura de la red y funciones generales. La especificación del Foro WAP

define la encapsulación de los mensajes y los protocolos de aplicación. Sin embargo, el

estándar no especifica un tamaño máximo para un MMS. Esto es para asegurar la

interoperabilidad futura y evitar limitaciones similares a las de los mensajes SMS. El

tamaño del mensaje depende del operador, quien probablemente establezca un tamaño

estandarizado para propósitos particulares de 100 ó 300 Kb [NokiaMMS, 2007].

CAPÍTULO III

ANÁLISIS Y DISEÑO En este capítulo se presenta el análisis y diseño realizado para este proyecto de tesis.

Para ello se describe la arquitectura, los diagramas de casos de uso, diagramas de

actividad, diagramas de secuencia y los diagramas de clases.

Capítulo III Análisis y diseño

Página 34

3. Análisis y diseño

3.1 Análisis

Se describe la arquitectura del generador de mapas croquis desarrollado. Se presentan

los diagramas de caso de uso, la definición de escenarios y los diagramas de actividad

que corresponden a la fase de análisis del proyecto.

3.1.1 Arquitectura del generador de mapas croquis

El generador de mapas croquis en formato SVG para dispositivos móviles permite

satisfacer las peticiones de información del cliente considerando el perfil del dispositivo,

es decir, se generarán los mapas de acuerdo a las características propias del dispositivo.

En la Figura 3-1 se muestra la arquitectura donde se presentan los módulos

implementados para el desarrollo del proyecto. Los componentes y tecnologías sobre las

cuales se desarrolló esta plataforma son las siguientes:

Negocio2sms. Está relacionado con el proveedor del servicio que registra sus

productos o servicios mediante una interfaz Web.

GW-SMS. Realiza la interacción con el cliente que demanda los servicios.

Geoserver. Servidor de mapas que provee los mapas cartográficos en diferentes

formatos, los cuales se explotarán a través de servicios Web.

SketchMapServer. Realiza la generación del mapa SVG-Tiny realizado por capas

que contienen información de los puntos de interés, ruta y los puntos de

referencia.

Base de datos espacial. Proporciona toda la información al módulo que interactúa

con el cliente y sirve para almacenar y registrar nuevos proveedores de servicios

desde el módulo Negocio2sms.

Figura 3-1 Arquitectura del generador de mapas croquis en un contexto de cliente/servidor

El proceso para obtener un mapa tipo croquis en formato SVG-Tiny se describe a

continuación en los siguientes pasos:


Página 35

1. Se realiza una petición a la aplicación Web SketchMapServer vía HTTP mediante un dispositivo móvil para obtener un mapa tipo croquis.

2. La aplicación Web SketchMapServer recibe e interpreta la petición enviada por el dispositivo móvil.

3. Se realizan consultas relacionales y espaciales a partir de los datos interpretados por la aplicación web. La consulta relacional se realiza para obtener el perfil del dispositivo móvil, mientras que las consultas espaciales son realizadas para obtener coordenadas georeferenciales del punto o los puntos de interés destino.

4. Se obtiene el área de interés mediante los puntos georeferenciales origen y destino, dicha área de interés se utiliza para realizar una petición WMS al servidor de mapas para obtener como respuesta una imagen en formato SVG v1.0 que contiene los polígonos que representan las manzanas delimitadas por las calles. La imagen SVG (Basic) v1.0 obtenida del servidor de mapas es convertido al formato SVG (Tiny) v1.1 el cual es compatible con los dispositivos móviles.

5. Se obtienen los nodos y las aristas mediante consultas espaciales, para ello se utiliza el área de interés obtenido en el punto anterior. A partir de los nodos y las aristas se genera el grafo del cual se obtiene la ruta origen-destino compuesta por la unión de nodos mediante las aristas.

6. Se realizan consultas de radio a la base de datos espacial para obtener los puntos de referencia de cada nodo que contiene la ruta obtenida.

7. Se agregan los elementos ruta y sus puntos de referencia a la imagen SVG-Tiny. 8. Por último se envía la imagen SVG-Tiny del mapa tipo croquis al dispositivo móvil

en respuesta de la petición realizada vía HTTP.

3.1.2 Base de datos espacial

Los Sistemas de Administración de Bases de Datos Espaciales (SDBMS) tienen como

objetivo el proveer todos los servicios de los DBMS relacionales y una administración

efectiva y eficiente de datos espaciales. Los requerimientos y técnicas que se necesitan

para modelar objetos geográficos que tienen extensión, ubicación, operaciones

geométricas (unión, intersección, resta, entre otros) y relaciones especiales son

complejos, haciendo insuficientes los servicios que ofrecen los sistemas de bases de

datos tradicionales.

Los sistemas de base de datos espaciales cuentan con dos tipos de representaciones:

1. Objetos espaciales. Son entidades geográficas distribuidas en un espacio de

representación que se pueden distinguir, consultar y manipular, por ejemplo

ciudades, rutas, zonas de reforestación, etc.

2. Espacio. Describe el espacio en sí mismo, esto es que se quiere decir algo sobre

cada punto del espacio, es utilizado para describir mapas temáticos como la

división política de un país.

El modelo en el que nos basamos es el estándar SQL de OpenGIS que contiene dos tipos

de atributos: los atributos espaciales que son valores geométricos de dos dimensiones

con interpolación lineal entre sus vértices y los atributos descriptivos.

Las consultas espaciales en este proyecto de tesis se realizan en el SDBMS PostGIS, el

cual es una extensión al DBMS PostgreSQL que permite el uso de objetos GIS


Página 36

(Geographic Information Systems). La especificación para SQL de características simples

de OpenGIS define tipos de objetos GIS estándar, los cuales son manipulados por

funciones y un conjunto de tablas de metadatos. Esta especificación tiene dos tablas de

metadatos:

SPATIAL_REF_SYS

PK SRID

AUTH_NAME

AUTH_SRID

SRTEXT

PROJ4TEXT

GEOMETRY_COLUMNS

SRID

F_TABLE_CATALOG

F_TABLE_SCHEMA

F_TABLE_NAME

F_GEOMETRY_COLUMN

COORD_DIMENSION

TYPE

Figura 3-2 Tablas de metadatos de la especificación OpenGIS

Se describen las columnas de las tablas de los metadatos de la especificación OpenGIS

que se muestran en la Figura 3-2:

Tabla GEOMETRY_COLUMNS

F_TABLE_CATALOG, F_TABLE_SCHEMA, F_TABLE_NAME. Distingue totalmente la tabla de características que contiene la columna geométrica.

F_GEOMETRY_COLUMN. Nombre de la columna geométrica en la tabla de características.

COORD_DIMENSION. Dimensión espacial de la columna (2D o 3D).

SRID. Es una clave foránea que referencia SPATIAL_REF_SYS.

TYPE. Tipo de objeto espacial (POINT, LINESTRING, POLYGON, MULTYPOINT, GEOMETRYCOLLECTION). Para un tipo heterogéneo se usa el tipo GEOMETRY.

Tabla SPATIAL_REF_SYS

SRID: Valor entero que identifica el sistema de referencia espacial.

AUTH_NAME: Nombre del estándar para el sistema de referencia. Por ejemplo:

EPSG.

AUTH_SRID: Identificador según el estándar AUTH_NAME. En el ejemplo anterior

es el id según EPSG.

SRTEXT: Una Well-know text 7 representación para el sistema de referencia

espacial. Ejemplo: WKT para SRS.

PROJ4TEXT: Proj4 es una librería que usa PostGIS para transformar coordenadas. Esta columna contiene una cadena con definición de las coordenadas de Proj4 para un SRID dado.

7 WKT (Well-Know Text) es la codificación o sintaxis diseñada específicamente para describir objetos

espaciales expresados de forma vectorial.


Página 37

PostGIS soporta los objetos GIS definidos por OpenGIS y el API de representación de la

especificación OpenGIS pero no tiene varios de los operadores de comparación. A

continuación se muestran unos ejemplos de la representación en modo texto:

POINT(0 0 0) LINESTRING(0 0,1 1,1 2) POLYGON((0 0 0,4 0 0,4 4 0,0 4 0,0 0 0),(1 1 0,2 1 0,2 2 0,1 2 0,1 1 0)) MULTIPOINT(0 0 0, 1 2 1) MULTILINESTRING((0 0 0, 1 1 0, 1 2 1),(2 3 1,3 2 1,5 4 1)) MULTIPOLYGON(((0 0 0,4 0 0,4 4 0,0 4 0,0 0 0),(1 1 0,2 1 0,2 2 0,1 2 0,1 1 0)),(-1 -1 0 -1 -2 0,-2 -2 0,-2 -1 0,-1 -1 0)) GEOMETRYCOLLECTION(POINT(2 3 9),LINESTRING(2 3 4,3 4 5))

En los ejemplos se pueden ver características con coordenadas en 2D y 3D, las funciones

force_2d() y force_3d() son para convertir una característica a 3D o 2D.

Las consultas espaciales en este proyecto de tesis localizan puntos de interés a partir de

una ubicación geoespacial, se obtiene la distancia de dos puntos geográficos y se obtiene

un número finito de información de los puntos de referencia localizados en un área

específica.

La siguiente sentencia representa la forma de obtener puntos de interés a una

determinada distancia de la ubicación georeferencial del dispositivo móvil.

SELECT distance(s.the_geom, GeometryFromText(„POINT(Longitud Latitud)‟, -1))*100000 as distancia, s.nomservicio, col.descripcion, s.calle, s.numero, col.cp FROM servicios As s, categoria As c, colonia As col WHERE distance(s.the_geom, GeometryFromText(„POINT(Longitud Latitud)‟, -1))*100000 <= Distancia ORDER BY distancia

Para la búsqueda de información en un contexto geoespacial se necesita tener un área de

interés llamado Bounding Box (BBOX) que contenga información referente a datos

geográficos. En esta área de interés existe información asociada a un mapa o un

repositorio geoespacial. En la Figura 3-3 se muestra la representación de los puntos

máximos y mínimos de un BBOX.

.

xMin xMax

yMax

yMin

Figura 3-3 Representación de un BBOX


Página 38

En el contexto de los servicios basados en localización se encuentra información de las

manzanas, calles, puntos de interés y puntos de referencia que representan instituciones

públicas o privadas que prestan algún servicio a usuarios o instituciones.

La siguiente sentencia SQL genera un BBOX definido por un punto georeferencial y una

distancia radial.

SELECT CAST(ST_Expand(ST_GeomFromText(„POINT(x y)‟), distance) AS BOX2D)

Sin embargo, al utilizar esta área para realizar peticiones Web Map Service al servidor de

mapas se obtiene un mapa con áreas innecesarias y un incremento en el tiempo para la

generación de las rutas, ya que se obtiene información no pertinente para el usuario. Por

ello se realiza un proceso para obtener el BBOX de búsqueda a partir de los puntos de

interés. El procedimiento para generar el BBOX es el siguiente:

i. Obtener puntos de interés mediante consulta a la base de datos espacial.

ii. Comparar los valores georeferenciales de longitud de los puntos de referencia

que se obtuvieron y la ubicación georeferencial del dispositivo móvil, con el fin

de obtener los valores georeferenciales de longitud mínimo y máximo.

iii. Comparar los valores georeferenciales de latitud de los puntos de referencia

que se obtuvieron y la ubicación georeferencial del dispositivo móvil, con el fin

de obtener los valores georeferenciales de latitud mínimo y máximo.

iv. Generar el BBOX a partir de los datos obtenidos en los pasos ii y iii, el BBOX

se presenta de la siguiente forma: (minLongitud minLatitud, maxLongitud

maxLatitud).

En la siguiente sentencia SQL se utiliza el BBOX generado para obtener las aristas que

representan las calles.

SELECT DISTINCT street.gid, sum(length(street.the_geom))*100000 as largo, numpoints(the_geom), astext(startpoint(street.the_geom)) as inicio, x(startpoint(street.the_geom)), y(startpoint(street.the_geom)), astext(endpoint(street.the_geom))as fin, x(endpoint(street.the_geom)), y(endpoint(street.the_geom)), sum(length(street.the_geom))*100000 as largo, astext(reverse(the_geom)) as geom_inverso FROM street WHERE street.the_geom && „BOX3D(xMin yMin, xMax yMax)‟::box3d GROUP BY street.the_geom,street.gid

La siguiente sentencia SQL se utiliza para obtener los nodos que representan las

intersecciones de las calles.

SELECT DISTINCT nodos.gid as id, AsText(nodos.the_geom) as nodos, X(the_geom),Y(the_geom) FROM nodos WHERE nodos.the_geom && „BOX3D(xMin yMin, xMax yMax)‟::box3d ORDER BY id

Los puntos de referencia se obtienen a partir de las consultas espaciales realizadas a los

nodos que integran la ruta mínima. La siguiente sentencia SQL obtiene los puntos de

referencia, en donde cada nodo es representado por una coordenada georeferencial


Página 39

longitud-latitud, la distancia máxima que se puede ubicar un punto de referencia con

respecto al nodo de la ruta mínima es de 10 metros.

SELECT DISTINCT s.nomservicio, s.calle, s.numero, c.descripcion, distance(the_geom,

GeomFromText(„POINT(longitudPOI latitudPOI)‟, -1))*100000 as distancia, astext(the_geom) as point FROM servicios as s, colonia as c WHERE distance( s.the_geom, GeometryFromText(„POINT(longitudPOI latitudPOI)‟, -1))*100000 <= 10 ORDER BY distancia

3.1.3 Algoritmo de ruta

Las aplicaciones actuales para la búsqueda de rutas usualmente calculan la ruta desde un

origen hacia algún destino basado en el camino más corto ó el camino más rápido. Sin

embargo, las investigaciones en esta área indican que la generación de las instrucciones

de las rutas depende de diversos factores, tales como la distancia, la cantidad de puntos

de la red a analizar y la complejidad de factores externos (tráfico, cierre de calles, etc.)

externos al momento de decidir cuál es el camino idóneo para obtener la ruta final.

Los enfoques recientes para representar una ruta se hace por medio de instrucciones de

la ruta previamente calculada, es decir, se calcula la ruta mínima o la ruta más rápida

añadiéndoles información a cada nodo asociado a datos contenidos en repositorios.

Nuestro algoritmo busca la ruta entre un origen y un destino dado una red geográfica. El

algoritmo está basado en el algoritmo de camino mínimo de Dijkstra que se muestra en la

Figura 3-4. Los libros especifican dos principios importantes que se emplean cuando se

proveen instrucciones a las rutas, los puntos de referencia como el primer principio y el

segundo consta de una combinación de múltiples puntos de decisión consecutivos dentro

una instrucción simple los puntos de referencia.

Los puntos de referencia en esta tesis son importantes porque permiten mostrar servicios

públicos y privados en el espacio geográfico de la ruta, lo que permite una mejor

orientación en la búsqueda del punto de interés.

1 N=número de nodos 2 //se crea un arreglo grafo[N][N] 3 mientras i < grafoTamaño hacer 4 mientras j < grafo[i]Tamaño hacer 5 grafo[i,j]=infinito 6 fin_mientras 7 fin_mientras 8 double[] Ruta (grafo) 9 //se crean dos arreglos del tamaño del grafo, nodoProcesado y caminoMinino 10 mientras i < nodoProcesadoTamaño hacer 11 nodoProcesado[i] = verdadero 12 fin_mientras 13 //se crean las distancias de los nodos, tomando como origen el nodo 0 14 mientras i < caminoMinimoTamaño hacer 15 caminoMinimo[i]=grafo[0][i] 16 fin_mientras 17 //Se busca el nodo que no se haya calculado 18 mientras i < nodoProcesadoTamaño -2 hacer 19 mientras ¡nodoProcesado[k] hacer 20 k = k + 1


Página 40

21 fin_mientras 22 //Se comprueba que el vértice elegido es el de menor distancia al origen 23 l=k 24 mientras k < nodoProcesadoTamaño hacer 25 si nodoProcesado[k] y caminoMinimo[l] > caminoMinimo[k] entonces 26 l=k 27 fin_si 28 fin_mientras 29 nodoProcesado[l]=falso 30 k=1 31 //Se actualizan las distancias 32 mientras k < nodoProcesadoTamaño hacer 33 si nodoProcesado[k] y caminoMinimo[k] > caminoMinimo[l]+grafo[l][k] entonces 34 caminoMinimo[k]=caminoMinimo[l]+grafo[l][k] 35 fin_si 36 fin_mientras 37 fin_mientras

Figura 3-4 Algoritmo de Dijkstra

El proceso para obtener la ruta mínima se describe en el diagrama de flujo de la Figura

3-9, para aplicar el algoritmo de Dijkstra se requiere un grafo conexo representado por

una matriz de adyacencia donde se almacenan los nodos totales, las aristas adyacentes

de cada nodo y la distancia de cada arista como su peso.

El procedimiento que se realizó se describe a continuación:

i. El primer paso es obtener el área de interés de la búsqueda, para ello se realizan

consultas a la base de datos espacial LBS en función de las coordenadas origen y

destino. En la Figura 3-5(a) se muestra una red geográfica de calles, mientras que

en la Figura 3-5(b) se muestra un área de interés que se obtiene de la consulta

realizada a la base de datos espacial.

ii. El área de interés que se obtiene se utiliza para obtener las aristas que

representan las calles y los nodos que representan las intersecciones de calles,

para ello se realizan una consultas espaciales a las tablas street y nodos de la

a

b

Figura 3-5 Representación del área de interés


Página 41

BDE. En la Figura 3-6(a) se muestran las aristas, en (b) se muestran los nodos y

en (c) se observa la integración de las aristas y los nodos.

iii. Este paso consiste en verificar la correspondencia de las aristas con los nodos

obtenidos en el paso anterior, en la Figura 3-6(c) se observan algunas aristas que

no tienen nodos terminales, estos nodos se infieren a partir de las coordenadas

inicio-fin de la arista, la coordenada que no exista en el contenedor de nodos se

etiqueta y es agregado al contenedor temporal de nodos. La Figura 3-7 muestra el

grafo que se obtiene con los nodos inferidos.

iv. Se desarrolló una clase en Java con métodos y datos temporales que permiten el

almacenamiento de datos temporales. En una matriz bidimensional llamada grafo

se almacenan las longitudes de las calles. Los índices de la matriz representan los

nodos terminales de cada arista, por lo que cada nodo tiene asociado una etiqueta

numérica única.

v. Finalmente se aplica el algoritmo de Dijkstra, el método obtenerRutaCorta recibe

los parámetros para ejecutar el algoritmo. Al final retorna una lista que representan

los nodos que representan la ruta. Los valores de la lista sirven para buscar en las

geometrías en los vectores temporales que retornan la ruta más corta del nodo

origen al destino como se muestra en la Figura 3-8.

a

Figura 3-6 Aristas y nodos del área de interés

b

c

Figura 3-7 Grafo con los nodos inferidos


Página 42

Figura 3-9 Diagrama de flujo del proceso de obtención de la ruta

3.1.4 Casos de uso de la aplicación móvil SketchMap4U

El diseño de la aplicación móvil se basa en los diagramas de casos de uso y los

diagramas de actividades, en la Figura 3-10 se muestra el diagrama general de casos de

uso de la aplicación móvil.

3.1.4.1 Caso de uso general

Se consideran como actor al dispositivo móvil cliente, los casos de uso principales son:

configurar RMS, crear y enviar petición HTTP.

Origen

Destino

Figura 3-8 Ruta obtenida del algoritmo de Dijkstra


Página 43

Figura 3-10 Diagrama general de los casos de uso de la aplicación SketchMap4U

3.1.4.2 Caso de uso: Configurar RMS

La Figura 3-11 representa el caso de uso que permite al usuario configurar la aplicación

en su dispositivo móvil. MIDP8 define una sencilla base de datos orientada a registros que

permite almacenar a las aplicaciones datos de forma persistente. Esta base se denomina

Record Management System (RMS). Este caso de uso incluye tres casos: crear, leer y

actualizar RMS, así también se puede actualizar RMS.

Figura 3-11 Diagrama de caso de uso: CU1 Configurar RMS

8 Mobile Information Device Profile (MIDO) define el ambiente de ejecución estándar para aplicaciones Java

que se ejecutan en teléfonos celulares.

uc SketchM...

Dispositiv o Móv il

Construir petición

HTTP

Env iar petición HTTP

Configurar RMS


Página 44

Tabla 3-1 Descripción del caso de uso: CU1 Configurar RMS

ID: CU1 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-12.

Nombre: Configurar RMS

Actores: Dispositivo móvil.

Descripción: Permite configurar una base de datos simple mediante RMS

Precondiciones: 1. Los datos de configuración default deben ser leídos y guardados en memoria volátil.

Poscondiciones: La aplicación tendrá la configuración de acceso al servidor.

Escenario de éxito 1 1. Se crea la base de datos RMS con los datos de configuración default. 2. No se actualizan los datos del RMS. 3. Se termina el proceso.

Escenario de éxito 2 1. Se crea la base de datos RMS con los datos de configuración default. 2. Se leen los datos del RMS a visualizar. 3. Se actualizan los datos del RMS. 4. Se termina el proceso.

Escenario de fracaso 1: 1. Se crea la base de datos RMS con los datos de configuración default. 2. No se crea el RMS. 3. Se lanza una excepción. 4. Se termina el proceso.

Escenario de fracaso 2: 1. Se crea la base de datos RMS con los datos de configuración default. 2. Se leen los datos del RMS a visualizar. 3. No se leen correctamente los datos. 4. Se lanza una excepción. 5. Se termina el proceso.

Incluye: CU1.1 Crear RMS, CU1.2 Leer RMS, CU1.3 Actualizar RMS

Suposiciones: Se supone que la configuración está disponible cada vez que se quiera actualizar.

Figura 3-12 Diagrama de actividad del caso de uso: CU1 Configurar RMS


Página 45

Tabla 3-2 Descripción del caso de uso: CU1.1 Crear RMS

ID: CU1.1 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-13.

Nombre: Crear RMS


Descripción: Permite crear una base de datos simple mediante RMS en el dispositivo móvil.

Precondiciones: 1. Los datos de configuración default deben ser leídos y guardados en memoria volátil.

Poscondiciones: Se crea una base de datos en el dispositivo móvil para acceder al servidor.

Escenario de éxito 1. Se crea el registro de almacenamiento. 2. Se instancia el detector de registros (RecordListener). 3. Se agregan los registros. 4. Se cierra el almacenamiento de registros. 5. Se termina el proceso.

Escenario de fracaso 1. Se crea el registro de almacenamiento. 2. No se crea correctamente el registro de almacenamiento. 3. Se lanza una excepción. 4. Se termina el proceso.

Incluye:

Suposiciones: Se supone que se ha creado la base de datos RMS en memoria del dispositivo móvil.

Figura 3-13 Diagrama de actividad del caso de uso: CU1.1 Crear RMS

act CrearRMS

Inicio

Crear registro de almacenamiento

(RecordStore)

Instanciar detector de registro

(RecordListener)

Agregar registro

Añadir mas registros

Cerrar almacenamiento de registro

(closeRecordListener)

Fin

RecordStore correctoExcepción

No

Si

No

Si


Página 46

Tabla 3-3 Descripción del caso de uso: CU1.2 Leer RMS


Nombre: Leer RMS


Descripción: Permite leer los datos de la base de datos RMS contenido en el dispositivo móvil.

Precondiciones: 1. Se han de haber guardado los datos en la base de datos RMS.

Poscondiciones: Se leen los datos de la base de datos en el dispositivo móvil para acceder al servidor.

Escenario de éxito 1. Se abre el RMS. 2. Se instancia el detector de registros (RecordListener). 3. Se leen correctamente los registros que contiene el RMS 4. Cerrar almacenamiento de registros. 5. Se termina el proceso.

Escenario de fracaso 1. Se abre el registro de almacenamiento. 2. Se instancia el detector de registros (RecordListener). 3. Se leen los registros que contiene el RMS. 4. No se leen correctamente los registros del RMS. 5. Se lanza una excepción. 6. Se termina el proceso.

Incluye:

Suposiciones: Se supone que se obtienen los datos de configuración que contiene el RMS.

Figura 3-14 Diagrama de actividad del caso de uso: CU1.2 Leer RMS

act LeerRMS

Inicio

Abrir registro de alamacenamiento

(RecordStore)

Instanciar detector de registros

(RecordListener)

Leer registro por indices

getRecord(index)

Leido correctamente Leer otro registroExcepción

Cerrar el registro de

almacenamiento

Fin

No

Si

No Si


Página 47

Tabla 3-4 Descripción del caso de uso: CU1.3 Actualizar RMS


Nombre: Actualizar RMS


Descripción: Permite actualizar la base de datos RMS contenido en el dispositivo móvil.

Precondiciones: 1. Se leen los datos contenidos en la base de datos RMS.

Poscondiciones: Se actualizan los datos de la base de datos en el dispositivo móvil para acceder al servidor.

Escenario de éxito 1. Se abre el RMS. 2. Se instancia el detector de registros (RecordListener). 3. Se actualizan los registros que contiene el RMS mediante índices. 4. Cerrar almacenamiento de registros. 5. Se termina el proceso.

Escenario de fracaso 1. Se abre el registro de almacenamiento. 2. Se instancia el detector de registros (RecordListener). 3. Se actualizan los registros que contiene el RMS mediante índices. 4. No se agregan correctamente los registros del RMS. 5. Se lanza una excepción. 6. Se termina el proceso.

Incluye:

Suposiciones: Se supone que se obtienen los datos de configuración que contiene el RMS.

Figura 3-15 Diagrama de actividad del caso de uso: CU1.3 Actualizar RMS

act ActualizarRMS

Inicio

Abrir Registro de almacenamiento

(openRecordStore)

Instanciar detector de registros

(RecordListener)

Actualizar registro por índice

(setRecord(index, dato))

Actualizar más registros

Cerrar almacenamiento de registro

(closeRecordStore)

Fin

Agregado

correctamenteExcepción

No

Si

Si


Página 48

3.1.4.3 Caso de uso: Construir petición HTTP

El caso de uso de la Figura 3-16 representa la construcción de la trama en el dispositivo

móvil. Permite a la aplicación móvil SketchMap4U crear la trama de petición HTTP.

Figura 3-16 Diagrama de caso de uso: CU2 Construir petición HTTP

Figura 3-17 Diagrama de actividad del caso de uso: CU2 Construir petición HTTP

Tabla 3-5 Descripción del caso de uso: CU2 Construir petición HTTP


Nombre: Construir trama


Descripción: Permite construir la trama de la petición HTTP.

Precondiciones: 1. Tener la configuración realizada correctamente.

Poscondiciones: Se construye la trama que servirá para realizar la petición HTTP.

Escenario de éxito 1. Se crea un dato. 2. Se agregan los datos 3. Se crea la trama a partir de los datos agregados 4. Se termina el proceso.

uc ConstruirPeticionHTTP

Dispositiv o Móv il

Construir petición

HTTP

act ConstruirPeticionHTTP

Crear dato

Dato compatible

Existen otros datos

Crear petición

Excepción

Fin

Inicio

Agregar dato

No

No

SiSi


Página 49

Escenario de fracaso 1. Se crea dato. 2. Dato no válido 3. Se lanza excepción 4. Se termina el proceso.

Incluye:

Suposiciones: Se supone que se tiene la trama de la petición HTTP creada.

3.1.4.4 Caso de uso: Enviar petición HTTP

El caso de uso de la Figura 3-18 representa la construcción de la petición HTTP en el

dispositivo móvil.

Figura 3-18 Diagrama de caso de uso: CU3 Enviar trama

Figura 3-19 Diagrama de actividad del caso de uso: CU3 Enviar trama

Tabla 3-6 Descripción del caso de uso: CU3 Enviar trama


Nombre: Enviar trama


Descripción: Envía una petición HTTP al servidor.

Precondiciones: 1. Tener creado la trama de envío.

uc Env iarTrama

Dispositiv o móv il

Env iarTrama

act Env iarTrama

Inicio

Establecer conexión con

el serv idor

Conexión

establecida

Env iar tramaTrama

enviada

Fin

Excepción

Terminar proceso

No

No


Página 50

Poscondiciones: La trama es enviada al servidor.

Escenario de éxito 1. Se establece conexión con el servidor 2. Se envía la trama por HTTP. 3. Terminar proceso.

Escenario de fracaso 1. Se establece conexión con el servidor. 2. No se establece la conexión. 3. Se lanza excepción 4. Terminar proceso.

Escenario de fracaso 1. Se establece conexión con el servidor. 2. Se envía la trama. 3. Ocurre error en el envío de la trama. 4. Se lanza excepción. 5. Terminar proceso

Incluye:

Suposiciones:

3.1.5 Casos de uso de la aplicación web SketchMapServer

El diseño de la aplicación servidora SketchMapServer se basa en los diagramas de casos

de uso y los diagramas de actividades. Se muestra en la Figura 3-20 el diagrama general

de casos de uso, mostrándose las funciones principales que éste ofrece.

3.1.5.1 Casos de uso general

Se considera como actor el servidor. Los casos de uso principales son: recibir petición

HTTP, interpretar petición, generar mapa SVGTiny y enviar mapa SVGTiny.

Figura 3-20 Diagrama general de casos de uso de la aplicación SketchMapServer

uc GeneralSketchMapSer...

Recibir petición HTTP

Interpretar petición

HTTP

Generar mapa SV GT

Env iar mapa SVGT

Serv idor


Página 51

3.1.5.2 Caso de uso: recibir petición HTTP

La Figura 3-21 muestra el diagrama de caso de uso Recibir petición HTTP. Se describe la

recepción de la petición HTTP que contiene datos pertinentes para realizar una consulta

al servidor SketchMapServer.

Figura 3-21 Diagrama de caso de uso: CU4 Recibir petición HTTP

Figura 3-22 Diagrama de actividad del caso de uso: CU4 Recibir petición HTTP

Tabla 3-7 Descripción del caso de uso: CU4 Recibir petición HTTP


Nombre: Recibir petición HTTP

Actores: Servidor.

Descripción: Recibe una petición HTTP.

Precondiciones: 1. Servidor de aplicaciones ejecutándose.

uc RecibirPeticionHTTP

Serv idor

Recibir petición

HTTP

act RecibirPeticionHTTP

Inicio

Ejecutar aplicación Web

SketchMapServ er

Esperar peticiones HTTP

Servidor Web

ejecutandose

Recibir petición HTTP

Petición correcta

Excepción

Fin

Si

No

No

Si


Página 52

Poscondiciones:

Escenario de éxito 1. Se ejecuta la aplicación web SketchMapServer. 2. Se esperan peticiones HTTP. 3. Se reciben las peticiones HTTP 4. Terminar proceso.

Escenario de fracaso 1. Se ejecuta la aplicación web SketchMapServer. 2. Error al ejecutar la aplicación. 3. Se lanza excepción. 4. Terminar proceso.

Escenario de fracaso 1. Se ejecuta la aplicación web SketchMapServer. 2. Se esperan peticiones HTTP 3. Se reciben las peticiones HTTP. 4. Error en la recepción de la petición. 5. Se lanza excepción. 6. Terminar proceso

Incluye:

Suposiciones:

3.1.5.3 Caso de uso: Interpretar petición HTTP

La Figura 3-23 muestra el diagrama de caso de uso Interpretar petición HTTP. Se

describe la obtención de los datos que contiene la petición HTTP.

Figura 3-23 Diagrama de caso de uso: CU5 Interpretar petición HTTP

Tabla 3-8 Descripción del caso de uso: CU5 Interpretar petición HTTP


Nombre: Interpretar petición HTTP

Actores: Servidor.

Descripción: Interpreta una petición HTTP.

Precondiciones: 1. Petición HTTP recibida

Poscondiciones:

Escenario de éxito 1. Se obtiene la petición HTTP 2. Se lee la petición HTTP. 3. Se obtienen los datos. 4. Terminar proceso.

Escenario de fracaso 1. Se obtiene la petición HTTP 2. Error al obtener la petición. 3. Se lanza excepción. 4. Terminar proceso.

Escenario de fracaso 1. Se obtiene la petición HTTP 2. Se lee la petición HTTP. 3. La petición no es válida. 4. Se lanza excepción.

uc InterpretarPeticionHTTP

Serv idor

Interpretar petición

HTTP


Página 53

5. Terminar proceso.

Suposiciones:

Figura 3-24 Diagrama de actividad del caso de uso: CU5 Interpretar petición HTTP

3.1.5.4 Caso de uso: Generar mapa SVG-Tiny

La Figura 3-25 muestra el diagrama de caso de uso CU6 Generar mapa SVGTiny. Se

describen las funciones básicas para generar la imagen SVGTiny adecuado para el

dispositivo móvil.

Figura 3-25 Diagrama de caso de uso: CU6 Generar mapa SVGTiny

Tabla 3-9 Descripción del caso de uso: CU6.1 Obtener perfil del dispositivo móvil


Nombre: Obtener perfil del dispositivo móvil.

act InterpretarPeticionHTTP

Inicio

Fin

Obtener petición HTTP

Petición

correcta

Leer petición

Obtener datos

Trama

válida

Excepción

No

No

Si

Si


Página 54

Actores: Servidor.

Descripción: Obtener perfil del dispositivo móvil.

Precondiciones: 1. Petición HTTP interpretada

Poscondiciones:

Escenario de éxito 1. Se abre conexión a postgres. 2. Se consulta compatibilidad del dispositivo móvil. 3. Se obtiene el perfil del dispositivo móvil. 4. Se cierra la conexión a postgres. 5. Terminar proceso.

Escenario de fracaso 1. Se abre conexión a postgres. 2. Error: conexión a postgres cerrada. 3. Se lanza excepción. 4. Terminar proceso.

Escenario de fracaso 1. Se abre conexión a postgres. 2. Se consulta compatibilidad del dispositivo móvil. 3. No existe compatibilidad con la aplicación. 4. Se lanza excepción. 5. Terminar proceso.

Incluye:

Suposiciones:

Figura 3-26 Diagrama de actividad del caso de uso: CU6.1 Obtener perfil del dispositivo

La Figura 3-27 muestra el caso de uso CU6.2 Crear imagen SVGTiny. Describen las

funciones básicas para generar la imagen SVGTiny.

act ObtenerPerfilDispositi...

Inicio

Abrir conexión postgres

Conexión

abierta

Consultar dispositiv o

móv il

EncontradoObtener perfil del

dispositiv o móv il

Cerrar conexión postgres

Excepción

Fin

Si

Si

No

No


Página 55

Figura 3-27 Diagrama de caso de uso: CU6.2 Crear imagen SVGTiny

Tabla 3-10 Descripción del caso de uso: CU6.2.1 Obtener mapa SVG

ID: CU6.2.1 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-28.

Nombre: Obtener mapa SVG.

Actores: Servidor.

Descripción: Obtener el mapa imagen SVG del servidor de mapas.

Precondiciones: 1. Tener el tamaño del mapa de acuerdo al perfil del dispositivo móvil.

Poscondiciones:

Escenario de éxito 1. Se abre conexión a postgis. 2. Se obtiene el BBOX mediante consultas a Postgis mediante las

coordenadas georeferenciales origen. 3. Se realiza una petición WMS al servidor de mapas con los parámetros del

dispositivo móvil y el BBOX. 4. Se obtiene el mapa SVG del servidor de mapas. 5. Terminar proceso.

Escenario de fracaso 1. Se abre conexión a Postgis. 2. Error: conexión a Postgis cerrada. 3. Se lanza excepción. 5. Terminar proceso.

Escenario de fracaso 1. Se abre conexión a Postgis. 2. Se obtiene el BBOX mediante consultas a Postgis mediante las

coordenadas georeferenciales origen. 3. Se realiza una petición WMS al servidor de mapas con los parámetros del

dispositivo móvil y el BBOX. 4. El servidor de mapas no está ejecutándose. 5. Se lanza excepción


Página 56

6. Terminar proceso.

Incluye:

Suposiciones:

Figura 3-28 Diagrama de actividad del caso de uso: CU6.2.1 Obtener mapa SVG

Tabla 3-11 Descripción del caso de uso: CU 6.2.2 Convertir SVG a SVGTiny


Nombre: Convertir SVG a SVGTiny.

Actores: Servidor.

Descripción: Se realiza la conversión de la imagen SVG a SVGTiny.

Precondiciones: 1. Tener el archivo imagen SVG.

Poscondiciones:

Escenario de éxito 1. Se obtiene la imagen SVG. 2. Se crea un objeto SAX para lectura. 3. Se obtiene el elemento root y la lista de sus propiedades. 4. Se crea el elemento root del SVGTiny y el namespace 5. Se leen los atributos del elemento SVG y se agregan al elemento root del

SVGTiny. 6. Se leen los elementos hijos del SVG y se agregan a al elemento hijo del

SVGTiny. 7. Se agrega el elemento hijo SVGTiny al root SVGTiny 8. Se crea documento y su docType. 9. Se agregan al documento el elemento root SVGTiny y el docType. 10. Terminar proceso.

Incluye:

Suposiciones:

act ObtenerMapaSVG

Inicio

Abrir conexión postgis

Conexión

correcta

Obtener BBOX consultado a la

BDE mediante las coordenadas

georeferenciales

Realizar petición WMS al serv idor

de mapas con los parámetros del

dispositiv o móv il y el BBOX

Servidor de Mapas

activo

Excepción

Obtener Mapa SVG

Fin

SiNo

No No


Página 57

Figura 3-29 Diagrama de actividad del caso de uso: CU6.2.2 Convertir SVG a SVGTiny

Tabla 3-12 Descripción del caso de uso: CU6.2.3 Generar ruta


Nombre: Generar ruta.

Actores: Servidor.

Descripción: Generar ruta a partir de una red de calles contenida en la base de datos espacial.

Precondiciones: 1. Tener los puntos georeferenciales origen y destino.

Poscondiciones:

Escenario de éxito 1. Ingresar grafo G, nodo origen y el nodo destino. 2. Construir arreglo de tamaño del total de nodos contenidos en G. 3. Iniciar valores del arreglo, D[nodo_inicial] =0, el resto -1. 4. Posicionarse en el primer vértice asumiendo a Di como ruta mínima. 5. Existe al menos un nodo adyacente 6. Di > (Da + distancia (a, vi)). 7. Di = Da + distancia (a, vi). 8. Repetir desde el punto 5 hasta encontrar la ruta hacia el nodo final. 9. Guardar ruta generada. 10. Terminar proceso.

act Conv ertirSVGaSVGT

Inicio

Obtener imagen SVG Crear objeto SAX de

lecturaObtener el elemento root y

la lista de sus propiedadesCrear elemento root del

SVGT y su Namespace

El Namespace es http://www.w3.org/2000/svg.

Namespace de referencias es http://www.w3.org/1999/xlink

El docType del archivo SVG es

-//W3C//DTD SVG 1.1 Tiny//EN","http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd

Los atributos que identifican al archivo SVG Tiny son los siguientes:

Version = 1.1

baseProfile=Tiny

viewBox= 0 0 x y

Leer atributo del elemento

root SVG

Agregar atributo leído del

SVG al elemento root SVGT

Existe otro atributoAgregar atributos v ersion,

baseProfile y v iewBox a la

imagen SVGT

Obtener los elemetos

hijos del elemento root

del SVG

Leer elemento hijo del

SVG y agregarlo al

elemento hijo del SVGT

Existen elementos

hijos SVG

Agregar elemento hijo

SVGT al elemento root

SVGT

Crear documento y su

DocType

Agregar docType y el

elemento rootSVGT al

documentoFin

SiNo

Si

No


Página 58

Escenario de fracaso 1. Ingresar grafo G, nodo origen y el nodo destino. 2. Construir arreglo de tamaño del total de nodos contenidos en G. 3. Iniciar valores del arreglo, D[nodo_inicial] =0, el resto -1. 4. Posicionarse en el primer vértice asumiendo a Di como ruta mínima. 5. Existe al menos un nodo adyacente 6. No existe nodo adyacente. 7. Lanzar excepción 8. Terminar proceso.

Incluye:

Suposiciones:

Figura 3-30 Diagrama de actividad del caso de uso: CU6.2.3 Generar ruta

Tabla 3-13 Descripción del caso de uso: CU6.2.4 Obtener puntos de referencia


Nombre: Obtener puntos de referencia.

Actores: Servidor.

Descripción: Generar los puntos de referencia de cada nodo que se obtiene de la ruta generada.

Precondiciones: 1. Tener una ruta generada.

Poscondiciones:

Escenario de éxito 1. Abrir conexión Postgis. 2. Consultar a la BDE areas radiales en base a las coordenadas

georeferenciales de cada nodo de la ruta generada 3. Obtener datos del punto de referencia. 4. Obtener puntos de referencia.

act GenerarRuta

Inicio

Ingresar grafo G, nodo

origen y destino

Construir arreglo del

número total de

elementos del grafo

Se asume Di al v ertice 1

como ruta mínima

Existe nodo

adyacente Vi

Di >(Da+distancia(a, vi)) Di = Da + distancia(a, v i)

Excepción

Da es nodo final

Obtener ruta generada

Fin

No

Si

Si

No

Si

No


Página 59

5. Terminar proceso

Escenario de fracaso 1. Abrir conexión Postgis. 2. La conexión no se establece correctamente. 3. Lanzar excepción. 4. Terminar proceso.

Escenario de fracaso 1. Abrir conexión Postgis. 2. Consultar a la BDE areas radiales en base a las coordenadas

georeferenciales de cada nodo de la ruta generada 3. No existe Punto de interés. 4. Lanzar excepción. 5. Terminar proceso.

Incluye:

Suposiciones:

Figura 3-31 Diagrama de actividad del caso de uso 6.2.4 Obtener puntos de referencia

Tabla 3-14 Descripción del caso de uso: CU6.2.5 Agregar datos al SVGTiny


Nombre: Agregar datos al SVGTiny

Actores: Servidor.

Descripción: Agregar datos a las capas del archivo SVGTiny

Precondiciones: 1. Conversión del SVG a SVGTiny. 2. Ruta generada. 3. Puntos de referencia obtenidos.

Poscondiciones: Mapa croquis generado

Escenario de éxito 1. Obtener la imagen SVGTiny, ruta, puntos de referencia y número de capa. 2. Obtener el documento y el root del SVGTiny. 3. Crear elemento g y agregarle atributos. 4. Leer ruta.

act ObtenerPuntosReferencia

Inicio

Abrir conexión postgis

Conexión correcta

Consultar a la BDE areas radiales en

base a las coordenadas

georeferenciales de cada nodo de la

ruta generada

Existen Puntos de

interés

Excepción

Obtener datos del punto

de referencia

Existe otro punto

de referencia

Obtener los puntos de

referencia

Fin

SiNo

Si

Si

No

No


Página 60

5. Validar ruta. 6. Leer puntos de la ruta. 7. Agregar los elementos línea al SVGTiny. 8. Leer punto de referencia 9. Validar punto de referencia 10. Obtener puntos de referencia. 11. Agregar elemento punto y texto al SVGTiny 12. Crear archivo SVGTiny.

13. Terminar proceso. Incluye:

Suposiciones:

Figura 3-32 Diagrama de actividad del caso de uso: CU6.2.5 Agregar datos al SVGTiny


Página 61

3.1.5.5 Caso de uso: Enviar mapa SVGTiny

La Figura 3-33 muestra el diagrama de caso de uso CU7 Enviar mapa SVGTiny.

Figura 3-33 Diagrama de caso de uso: CU7 Enviar mapa SVGTiny

Figura 3-34 Diagrama de actividad del caso de uso: CU7 Enviar mapa SVGTiny

Tabla 3-15 Descripción del caso de uso: CU7 Enviar mapa SVGTiny


Nombre: Enviar mapa SVGTiny.

Actores: Servidor.

Descripción: Envía el mapa SVGTiny en respuesta a la petición HTTP realizada.

Precondiciones: 1. Mapa SVGTiny generado

Poscondiciones:

Escenario de éxito 1. Crear flujo de salida de datos. 2. Enviar mapa SVGTiny. 3. Terminar proceso

Escenario de fracaso 1. Crear flujo de salida de datos. 2. Error al crear el flujo de salida de datos. 3. Se lanza excepción. 4. Terminar proceso

Escenario de fracaso 1. Crear flujo de salida de datos. 2. Enviar mapa SVGTiny. 3. SVGTiny no enviado. 4. Se lanza excepción.

uc Env iarSVGT

Serv idor

Env iar mapa SVGT

act Env iarMapaSVGT

Inicio

Crear flujo de salida de

datos

Flujo de salida

abiertoExcepción Env iar mapa SVGT

SVGT enviado

Fin

No

No


Página 62

5. Terminar proceso

Incluye:

Suposiciones:

3.2 Diseño

El proyecto del generador de mapas croquis en formato SVGTiny consta de 4 paquetes,

mismos que se describen en la Tabla 3-16, la Figura 3-35 muestra el diagrama general

de los paquetes desarrollados. El nombre de los paquetes se asignó siguiendo las

recomendaciones descritas en el artículo Estructura de paquetes [SG, 2005]

Tabla 3-16 Descripción de los paquetes de la aplicación SketchMapServer.

PAQUETE DESCRIPCIÓN

mx.edu.cenidet.gateway.database Contiene las clases que implementan las conexiones a la base de datos postgres y la extensión a Postgis.

mx.edu.cenidet.gateway.maps Contiene las clases que generan los datos para crear las capas de la imagen SVG-Tiny (mapa, ruta y puntos referencia).

mx.edu.cenidet.gateway.maps.coordinates Contiene las clases que convierten coordenadas Georeferenciales a UTM y viceversa, asimismo se obtiene la distancia entre dos puntos y su punto medio.

mx.edu.cenidet.gateway.servlet Este paquete consta de las clases que reciben y responden las peticiones HTTP.

mx.edu.cenidet.gateway.utils Contiene clases necesarias para la obtención de los directorios, conversión de coordenadas georeferenciales a pixeles.

mx.edu.cenidet.gateway.mobiledevice Este paquete tiene las clases que contiene el perfil del dispositivo móvil.

mx.edu.cenidet.gateway.routing Contiene las clases del algoritmo de ruta.

mx.edu.cenidet.gateway.SVGTiny Es el paquete donde están las clases que convierten la imagen SVG a SVG-Tiny y los métodos para añadirle nuevas capas.

Figura 3-35 Diagrama general de paquetes del generador de mapas croquis SVGTiny


Página 63

3.2.1 Paquetes diseñados

A continuación se describen las clases que contienen los paquetes diseñados, así como

las relaciones que existen entre éstos.

3.2.1.1 Paquete mx.edu.cenidet.gateway.database

Este paquete contiene las clases que representan la conexión a la base de datos

espacial, así como la configuración de dichas conexiones y el registro de usuarios (ver

Figura 3-36).

Figura 3-36 Diagrama de clases del paquete mx.edu.cenidet.gateway.database

Las clases que conforman el paquete son las siguientes:

configuracion. Los métodos de esta clase permiten obtener los datos de

configuración localizados en el archivo confPostgres.properties.


Página 64

postgres. Los métodos que proporciona esta clase permiten abrir y cerrar una

conexión al servidor de datos Postgres.

Postgis. Los métodos que proporciona esta clase permiten abrir y cerrar una

conexión específicamente a la extensión a la base de datos espacial Postgis.

Usuario. Esta clase contiene los datos del usuario.

RegistroUsuarioDAO. Los métodos de esta clase consultan a la base de datos la

existencia del usuario, en caso contrario se agrega.

La aplicación Web obtiene del archivo de configuración los datos necesarios para formar

la URL de conexión. Se abre la conexión y se realizan las consultas a la base de datos

relacional o espacial, si la consulta se realiza con éxito se obtienen los datos y se cierra la

conexión. El diagrama de secuencia de este proceso se muestra en la Figura 3-37.

Figura 3-37 Diagrama de secuencia para una conexión a postgres

3.2.1.2 Paquete mx.edu.cenidet.gateway.maps

Este paquete contiene las clases que representan los elementos para crear el archivo

SVG-Tiny, tales como la obtención del mapa SVG, generación de la ruta y obtención de

los puntos de referencia (ver Figura 3-38).


Página 65

Figura 3-38 Diagrama de clases del paquete mx.edu.cenidet.gateway.maps


DataPointOfInterest. Representa los datos que contiene el punto de interés

PointOfInterestDAO. Los métodos que proporciona esta clase permiten realizar

consultas a la BDE de los puntos de interés y se agregan al tipo de dato

DataPointOfInterest.

DataWebMapService. Permite formar una URL con los parámetros necesarios

para solicitar un mapa a un servidor de mapas.

pkg maps

DataMapImage

+ DataMapImage()

+ getBBOX() : String

+ getBBOXUTM() : String

+ getBBOXUTM1() : String

+ getBOX3D() : String

+ getBOX3DUTM() : String

+ printBBOX() : void

+ setGeoDevice(double, double) : void

+ setGeoPOI(String) : String

+ setGeoPOI(DataPointOfInterest) : void

+ setGeoPOIUTM(DataPointOfInterest) : void

DataMapRoute

+ convertGeoRefToPixel(DataMobileDevice, String) : String

+ DataMapRoute()

+ getPointsRoute() : ArrayList<String>

+ getRouteGeoespatial() : String

+ getRoutePoints() : String

+ getX(double) : int

+ getY(double) : int

+ PORGeoespatial(DataMobileDevice, String) : String

+ setGeoArea(String) : void

+ setPORGeoespatial(String) : void

+ setRouteGeoespatial(String) : void

+ setTamPixel(int, int) : void

DataPointOfInteres t

+ DataPointOfInterest()

+ getCode() : ArrayList<String>

+ getCode(int) : String

+ getDescription() : ArrayList<String>

+ getDescription(int) : String

+ getDistance() : ArrayList<String>

+ getDistance(int) : String

+ getEstado() : String

+ getIdestado() : int

+ getIdmunicipio() : int

+ getMunicipio() : String

+ getNameService() : ArrayList<String>

+ getNameService(int) : String

+ getNumber() : ArrayList<String>

+ getNumber(int) : String

+ getNumReg() : int

+ getStreet() : ArrayList<String>

+ getStreet(int) : String

+ getXPoint() : ArrayList<String>

+ getXPoint(int) : double

+ getYPoint() : ArrayList<String>

+ getYPoint(int) : double

+ resetVar() : void

+ setCode(int, String) : void

+ setCode(String) : void

+ setDescription(int, String) : void

+ setDescription(String) : void

+ setDistance(int, String) : void

+ setDistance(String) : void

+ setEstado(String) : void

+ setIdestado(int) : void

+ setIdmunicipio(int) : void

+ setMunicipio(String) : void

+ setNameService(int, String) : void

+ setNameService(String) : void

+ setNumber(int, String) : void

+ setNumber(String) : void

+ setNumReg(int) : void

+ setStreet(int, String) : void

+ setStreet(String) : void

+ setXPoint(int, String) : void

+ setXPoint(String) : void

+ setYPoint(int, String) : void

+ setYPoint(String) : void

«property get»

+ getPoint() : ArrayList<String>

+ getPoint(int) : String

«property set»

+ setPoint(int, String) : void

+ setPoint(String) : void

MapImage

+ generateMap(DataMobileDevice, String) : void

+ getDirImgSVG() : String

+ getExtensionFile(String) : String

+ getFileInputStreamMap() : InputStream

+ getImageName() : String

+ getWMS() : DataWebMapService

+ imageName() : String

+ MapImage()

MapPOR

+ calculateDistance(ArrayList<String>) : void

+ createPORLayer(DataMapRoute, PoiGeoreferenciado, DataPointOfInterest) : boolean

+ getDistance() : double

+ getPOR() : String

+ MapPOR()

MapPORDAO

+ iniVarPOIs(int) : void

+ MapPORDAO()

+ numeroPOIs(Connection, String) : int

+ obtenerPOIs(PoiGeoreferenciado, DataPointOfInterest, ArrayList<String>) : void

MapRoute

+ createRouteLayer(PoiGeoreferenciado, DataMobileDevice, double, double, String) : void

+ getDataMapRoute() : DataMapRoute

+ getRouteGeospatial() : String

+ MapRoute()

MapRouteDAO

+ addNode(int, double, double) : void

+ datosGrafo(int, String) : void

+ extraerPuntos(String) : String

+ findStreetNear(double, double) : int

+ generatingGraph() : void

+ getDistanceE2Points(String, String, String) : double[]

+ getGeomEdge(int) : String

+ getGeomInverseEdge(int) : String

+ getGrafo() : double[]

+ getNaristas() : int

+ getNodo(int) : Point

+ getNumberNodes() : int

+ getPDestino() : int

+ getPfX(int) : double

+ getPfY(int) : double

+ getPiX(int) : double

+ getPiY(int) : double

+ getPointInitial_Final(String) : String[]

+ getPOrigen() : int

+ getPuntoF(int) : double

+ getPuntoI(int) : double

+ identifyingFinalNodes() : void

+ initializeEdgeVar(int) : void

+ initializeNodesVar(int) : void

+ MapRouteDAO()

+ obtainDBNodes(PoiGeoreferenciado, double, double, String) : void

+ obtainDBStreet(PoiGeoreferenciado, double, double, String) : void

- onStreet(String, double[]) : void

+ positionOnStreet(int) : double[]

+ redimNode(int, int, double, double) : void

+ searchNode(double, double) : int

PointOfInterestDAO

+ getDataPointOfInterest() : DataPointOfInterest

+ PointOfInterestDAO()

+ printData() : void

+ SearchPointOfInterest(String, String, PoiGeoreferenciado) : void

DataWebMapServ ice

+ DataWebMapService()

+ getQueryString() : String

+ getRequest() : String

+ setArchivo() : void

+ setBBox(String) : void

+ setBGColor(String) : void

+ setFormat(String) : void

+ setHeight(String) : void

+ setLayers(String) : void

+ setRequest(String) : void

+ setStyles(String) : void

+ setTransparent(String) : void

+ setUrl(String) : void

+ setVersion(String) : void

+ setWidth(String) : void

«property get»

+ getBBOX() : String

+ getBGCOLOR() : String

+ getFORMAT() : String

+ getHEIGHT() : int

+ getLAYERS() : String

+ getREQUEST() : String

+ getSRS() : String

+ getSTYLES() : String

+ getTRANSPARENT() : boolean

+ getURL() : String

+ getVERSION() : String

+ getWIDTH() : int

«property set»

+ setSRS(String) : void

-mpDAO

-dmr

-dpoi

-dwms


Página 66

MapImage. Los métodos que proporciona esta clase permiten realizar peticiones al

servidor de mapas obteniendo la URL de la clase DataWebMapService, genera

una imagen SVG temporal.

DataMapImage. La función de esta clase es construir el área de petición al

servidor de mapas (BBOX) de acuerdo al punto georeferencial origen.

DataMapRoute. Esta clase representa la ruta a generar y hace referencia a la

conversión de las coordenadas georeferenciales a pixeles.

MapRoute. Permite generar la ruta y se agrega al tipo de dato DataMapRoute.

MapRouteDAO. Los métodos que contiene esta clase realizan consultas a la BDE

para obtener el grafo del cual se generará la ruta.

MapPOR. Representa los puntos de referencia de la ruta.

MapPORDAO. Esta clase realiza consultas a la BDE de los puntos de referencia

de cada nodo georeferencial de la ruta y se agregan al tipo de dato MapPOR.

La aplicación realiza una búsqueda de los puntos de interés a la BDE, mismos que

tomará como etiqueta de destino para generar la ruta, los resultados obtenidos se

agregan a DataPointOfInterest.

Para obtener el mapa SVG se realiza una consulta a la BDE para generar el área de

búsqueda (BBOX) que servirá para crear la URL del WMS, a continuación se realiza la

petición al servidor de mapas mediante WMS y se obtiene el mapa.

El diagrama de secuencia del proceso mencionado se muestra en la Figura 3-39.

Figura 3-39 Diagrama de secuencia para la obtención del mapa SVG

En la Figura 3-40 se muestra el diagrama de secuencia que realiza la generación de la

ruta. Esto se realiza n veces en base al número de puntos de interés obtenidos, se hacen


Página 67

consultas a la BDE para obtener los nodos y aristas agregándolos al dato de tipo

DataMapRoute.

Posteriormente se genera el grafo del cual se obtiene la ruta, los puntos georeferenciales

de la ruta son convertidos a pixeles y se retorna la ruta a la aplicación. Se procede a

obtener los puntos de referencia de cada nodo que integra la ruta mediante consultas a la

base de datos espacial, la información obtenida se agrega al tipo de dato MapPOR y se

retorna a la aplicación SketchMapServer.

Figura 3-40 Diagrama de secuencia para la obtención de los datos del SVGTiny

3.2.1.3 Paquete mx.edu.cenidet.gateway.maps.coordinates

Este paquete contiene las clases que realizan conversiones georeferenciales a UTM y

viceversa (ver Figura 3-41).


Página 68

Figura 3-41 Diagrama de clases del paquete mx.edu.cenidet.gateway.maps.coordinates


CoordenadasUTM. Representa coordenadas UTM(x, y).

CoordenadasGeoreferenciales. Representa coordenadas georeferenciales

(longitud, latitud).

ConvertirCoordinates. Los métodos de esta clase permiten realizar conversiones

de coordenadas UTM a georeferenciales y viceversa.

En la Figura 3-42 se muestra el diagrama de actividad de las conversiones de

coordenadas georeferenciales-UTM y UTM-georeferenciales. El proceso para convertir

coordenadas UTM a coordenadas georeferenciales es el siguiente: se agregan las

coordenadas (x, y) a un objeto de tipo coordenadasUTM, misma que se envía a la clase

ConvertCoordinates realizando la conversión, obteniéndose coordenadas

georeferenciales (longitud, latitud).

El proceso para convertir coordenadas georeferenciales a coordenadas UTM es el

siguiente: se agregan las coordenadas georeferenciales (longitud, latitud) a un objeto de

tipo coordenadasGeorefernenciales, misma que es enviada a la clase ConvertCoordinates

realizando la conversión, y obteniéndose como resultado las coordenadas UTM (x,y).

pkg Coordinates

CoordenadasGeoreferenciale s

+ CoordenadasGeoreferenciales()

+ getLatitud() : double

+ getLongitud() : double

+ getZona() : double

+ setLatitud(double) : void

+ setLongitud(double) : void

+ setZona(double) : void

«property get»

+ getHemisferio() : int

«property set»

+ setHemisferio(int) : void

CoordenadasUTM

+ CoordenadasUTM()

+ getCoordenadaX() : double

+ getCoordenadaY() : double

+ getZona() : double

+ setCoordenadaX(double) : void

+ setCoordenadaY(double) : void

+ setZona(double) : void

«property get»

+ getHemisferio() : int

«property set»

+ setHemisferio(int) : void

Conv ertCoordinates

- DistanciaElipsoidal(double) : double

+ getCoordenadasGeoreferenciales() : CoordenadasGeoreferenciales

+ getCoordenadasUTM() : CoordenadasUTM

+ GradosARadianes(double) : double

+ Lat2UTM(CoordenadasGeoreferenciales) : boolean

- Latitud(double) : double

+ LatLonToUTMXY(double, double, double, double[]) : double

- MapeaGeoRefToXY(double, double, double, double[]) : void

- MapeaXYAGeoRef(double, double, double, double[]) : void

- MeridianoCentralUTM(double) : double

+ RadianesAGrados(double) : double

+ UTM2Lat(CoordenadasUTM) : boolean

+ UTMToGeoRef(double, double, double, boolean, double[]) : void

-cUTM -cg


Página 69

Figura 3-42 Diagrama de secuencia para convertir coordenadas UTM y georeferenciales

3.2.1.4 Paquete mx.edu.cenidet.gateway.servlet

Este paquete contiene las clases principales que representan la generación del mapa

croquis en formato SVGTiny (ver Figura 3-43), el servlet y la clase principal.

Figura 3-43 Diagrama de clases del paquete mx.edu.cenidet.gateway.servlets


servletSketchMap. Esta clase permite instanciar y ejecutar un nuevo objeto Main

para la obtención del mapa SVGTiny.

Main. Esta clase contiene métodos que permiten realizar las funciones para

convertir el SVG a SVGTiny, agregar datos al SVGTiny y obtener la imagen para

ser dado al servlet.

El proceso se visualiza en el diagrama de secuencia mostrado en la Figura 3-44. El

dispositivo móvil realiza una petición HTTP que recibe el servletSketchMap, el cual

instancia un objeto Main que genera el mapa y retorna el mapa SVGTiny al

servletSketchMap que lo envía mediante HTTP al dispositivo móvil.


Página 70

Figura 3-44 Diagrama de secuencia para dar al servlet el mapa SVGTiny

3.2.1.5 Paquete mx.edu.cenidet.gateway.mobiledevice

En la Figura 3-45 se muestra el paquete que contiene las clases que representan el perfil

del dispositivo móvil.

Figura 3-45 Diagrama de clases del paquete mx.edu.cenidet.edu.gateway.mobiledevice


DataMobileDevice. Representa el perfil del dispositivo móvil.

MobileDeviceDAO. Esta clase realiza consultas a la BDE para obtener el perfil del

dispositivo móvil y agregárselo a DataMobileDevice.

En la Figura 3-46 se muestra el proceso de obtención del perfil del dispositivo móvil. Para

obtener el perfil del dispositivo móvil la clase MobileDeviceDAO realiza consultas a la

BDR y agrega el perfil a DataMobileDevice si el dispositivo móvil cumple con las limitantes

de la aplicación cliente.

pkg mobiledev i...

DataMobileDev ice

+ getIdDevice() : String

+ isExist() : boolean

«property get»

+ getBrand() : String

+ getCLDC_1_1() : String

+ getHeight() : int

+ getHeightDisplay() : String

+ getHeightResolution() : String

+ getMIDP_2_0() : String

+ getModel() : String

+ getReceiveMMS() : String

+ getRelease() : String

+ getSendMMS() : String

+ getSizeMaxMMS() : String

+ getSystem() : String

+ getTypeBrowser() : String

+ getVersionTypeBrowser() : String

+ getWidth() : int

+ getWidthDisplay() : String

+ getWidthResolution() : String

MobileDev iceDAO

+ getDataMobileDevice() : DataMobileDevice

+ main(String[]) : void

+ MobileDeviceDAO()

+ MobileDevices() : ArrayList<DataMobileDevice>

+ printData() : void

+ printDataMobileDevice(ArrayList<DataMobileDevice>, int) : void

+ SearchMobileDevice(String, String) : boolean

-dmd


Página 71

Figura 3-46 Diagrama de secuencia para la obtención del dispositivo móvil

3.2.1.6 Paquete mx.edu.cenidet.gateway.routing

En la Figura 3-47 se muestra el paquete que contiene las clases que representan el

algoritmo para generar la ruta mínima.

Figura 3-47 Diagrama de clases del paquete mx.edu.cenidet.gateway.routing

Las clases que contiene el paquete son las siguientes:

Nodo. Representa un nodo del grafo.

Arista. Representa una arista del grafo.

AlgoritmoRuta. Esta clase contiene métodos para obtener la ruta mínima en

función del grafo generado por los nodos y aristas.

En la figura Figura 3-48 se muestra el proceso que genera la ruta mínima, en donde se le

manda un mensaje a la clase AlgoritmoRuta para generar la ruta mínima, para ello es


Página 72

necesario obtener los nodos y aristas contenidas en la BDE, siendo a partir de estos datos

la creación del grafo que se le aplicará el AlgoritmoRuta, se retorna la ruta mínima una

vez terminado el proceso.

Figura 3-48 Diagrama de secuencia para generar la ruta mínima

3.2.1.7 Paquete mx.edu.cenidet.gateway.SVGTiny

En la figura Figura 3-49 se muestran las clases del paquete que permiten crear el mapa

SVGTiny, las clases que contienen son las siguientes:

SVGToSVGT. Clase que permite la conversión del mapa SVG obtenido del

servidor de mapas a un mapa SVGTiny.

ElementSVGT. Esta clase contiene métodos que agregan datos al mapa SVGTiny,

tales como las capas que contienen líneas, puntos y textos.

ArrowDirection. La función de esta clase es identificar la orientación de la ruta.


Página 73

Figura 3-49 Diagrama de clases del paquete mx.edu.cenidet.gateway.SVGTiny

El diagrama de actividad mostrado en la Figura 3-50 representa la conversión del mapa

SVG a SVGTiny, asimismo las capas que se agregan conteniendo el mapa, ruta y los

puntos de referencia. Finalmente se obtiene el mapa SVGTiny al agregar las capas de

acuerdo al número de puntos de interés.

Figura 3-50 Diagrama de actividad para crear el mapa SVGTiny

pkg s...

ArrowDirection

+ ArrowDirection()

+ calculaAngulo() : double

+ calculaDistancia(float, float, float, float) : double

+ calculaPuntoMedio() : double[]

+ setLinea(float, float, float, float) : void

ElementSV GT

+ agregarCapa(Document, String, String, int, double) : void

+ agregarDataToMap(Document, int, int, String) : void

+ agregarPointToMap(Document, int, int, String, String, int) : void

+ createFileSVGT(Document, String) : void

+ dibujarLinea(Document, Element, float, float, float, float) : void

+ dibujarPunto(Document, Element, float, float, String, String, String) : void

+ getDoc() : Document

+ interpretaTrama(String) : void

- obtenerPuntos(String) : Vector

+ printScreen(Document) : void

SVGToSVGT

+ convertSVGtoSVGT() : void

+ createFileSVGT(Document, String) : void

+ getDocumentResult() : Document

+ printScreen(Document) : void

+ setFile(FileInputStream) : void

+ setFile(InputStream) : void

+ SVGToSVGT()


Página 74

3.3 Base de datos MobileDevice

En este trabajo de tesis como parte esencial se considera el perfil del dispositivo móvil, es

decir las características específicas con las que cuenta el dispositivo móvil, tales como: el

envío y recepción de mensajes SMS/MMS, el soporte de los perfiles y configuración de

java (CLDC y MIDP), el tamaño de la pantalla, los tipos de archivos y servicios que

soporte, así como las características generales de marca, modelo, etc.

Es por ello que se analizan tres repositorios que contienen las características esenciales

de los dispositivos móviles, de los cuales uno cuenta con licencia abierta y los otros dos

repositorios cuentan con licencia de empresas privadas teniendo un costo accesible.

Los repositorios que se analizan son los siguientes:

1. DeviceMine v3.0

2. DeviceAtlas

3. Wurfl

A continuación se describen las principales características de cada repositorio que

contiene información de diversos dispositivos móviles.

3.3.1 DeviceMine v3.0

Es un repositorio global privado en donde están contenidos los perfiles de dispositivos que

detallan los atributos y capacidades de los dispositivos móviles. La información contenida

en este repositorio permite optimizar el contenido de diferentes tipos de dispositivos

móviles, elimina la incertidumbre y la complejidad de optimización de los servicios que se

le brinda al usuario final, [Wdsglobal, 2008].

Las características de los dispositivos móviles que están contenidas en el repositorio

DeviceMine 3.0 son las siguientes:

Especificaciones Físicas Plataforma de Software Características de la pantalla Medios de Apoyo Soporte de audio Imágenes

Java Conectividad

Detalles del navegador Red de Información Portadores de datos WAP

3.3.2 DeviceAtlas

Es una completa base de datos de dispositivos móviles, construida a partir de diversas

fuentes en las que se incluyen los fabricantes y los operadores de de la red, haciendo de

esta base de datos la más completa. Las actualizaciones de las características de los

dispositivos móviles recientes ayudan a los desarrolladores en tecnología móvil adaptar y

optimizar el contenido para diversos dispositivos móviles.

La información contenida en DeviceAtlas está compuesta las siguientes características:

Nombre del dispositivo. Contiene la marca y el modelo del dispositivo móvil.

Hardware.

Explorador web. Indica el tipo del explorador y su versión.


Página 75

Reproductor de audio y video. Precisa el soporte de formatos, mp3, mp4, mpg,

entre otros.

Protocolos de red. Indica los tipos de conexiones que se puedan realizar en red,

tales como LAN,WAP, entre otros

Para adquirir una copia de la base de datos DeviceAtlas es necesario adquirir la licencia

con un determinado costo, sin embargo se puede acceder a la versión Web la cual es

gratuita, [Deviceatlas, 2008].

3.3.3 WURFL (Wireless Universal Resource File)

Es un archivo de configuración XML que contiene información de las capacidades y

características de diversos dispositivos móviles. El principal alcance del archivo es

coleccionar información de los dispositivos móviles que acceden a páginas WAP, la

información es utilizada para construir buenos servicios y aplicaciones para los usuarios.

La creación del archivo XML se realiza en colaboración de usuarios y desarrolladores de

los diferentes dispositivos móviles recientes, las características de los dispositivos móviles

con las que el archivo tienen como base a dispositivos móviles genéricos, las

características adicionales que diferencian los móviles de la misma marca dependen del

modelo del dispositivo móvil. El archivo WURFL puede ser utilizado en cualquier

aplicación libre o comercial, [Wurfl, 2008].

Tabla 3-17 Comparación de los repositorios de dispositivos móviles

Repositorios Características del dispositivo móvil Licencia

DeviceMine v3.0 Sí Sí

DeviceAtlas Sí Sí

Wurl Sí No

En la Tabla 3-17 se puede notar que los tres repositorios contienen información de los

dispositivos móviles, los repositorios completos de DeviceMine y DeviceAtlas tienen un

determinado costo para adquirir la licencia, caso contrario del repositorio xml de WURLF

que es de fácil acceso al ser un proyecto libre y consta de una gran diversidad de

características de los dispositivos móviles.

Uno de los objetivos de esta tesis es desarrollar una aplicación que sea compatible con

los dispositivos móviles, teniendo en consideración el perfil MIDP 2.1 y la configuración

CLDC 1.1 de java, ya que se utilizarán características específicas de cada dispositivo

móvil, con el fin de desarrollar mapas ad-hoc dependiendo del tamaño de la pantalla del

dispositivo móvil.

Dado lo anterior es necesario contar con una base de datos, el cual debe contener las

características de los dispositivos móviles. Los datos que contiene la base de datos

MobileDevice son obtenidos del archivo wurfl.xml, en la Figura 3-51 se muestra el

diagrama relacional de la base de datos MobileDevice. En la tabla 3.18 se describen en

forma breve el objetivo de las relaciones.


Página 76

Tabla 3-18 Descripción de las de la base de datos MobileDevice

Relación Descripción

mobile_device Contiene información básica del dispositivo móvil: número del dispositivo, marca, modelo y el id relacionado con las otras tablas.

product_info Esta tabla tiene información del dispositivo móvil (marca, modelo, sistema operativo,…).

display Esta tabla contiene información del tamaño de la pantalla e imagen soportado por los dispositivos móviles.

image_format Contiene información de los diferentes formatos de imagen que pueden ser soportados por el dispositivo móvil.

j2me Esta tabla indica las características soportadas por los dispositivos móviles que incluyen java.

sms Contiene información necesaria de las características del mensaje SMS que soporta el dispositivo móvil.

mms Contiene información necesaria de las características del mensaje MMS que soporta el dispositivo móvil.

Figura 3-51 Diagrama relacional de la base de datos MobileDevice

FK_MOBILE_D_REFERENCE_IMAGE_FO

FK_MOBILE_D_REFERENCE_MMS

FK_MOBILE_D_REFERENCE_PRODUCT_

FK_MOBILE_D_REFERENCE_J2ME

FK_MOBILE_D_REFERENCE_DISPLAY

FK_MOBILE_D_REFERENCE_SMS

display

id

columns

rows

max_image_width

resolution_height

resolution_width

max_image_height

physical_screen_height

physical_screen_width

character varying(50)

double precision

double precision

double precision

double precision

double precision

double precision

double precision

double precision

image_format

id

greyscale

jpg

gif

transparent_png_index

epoc_bmp

bmp

wbmp

gif_animated

colors

svgt_1_1_plus

svgt_1_1

transparent_png_alpha

png

tiff


boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

integer

boolean

boolean

boolean

boolean

boolean

j2me

id

doja_1_5

j2me_datefield_broken

j2me_clear_key_code

j2me_right_softkey_code

j2me_heap_size

j2me_canvas_width

j2me_loctapi

j2me_motorola_lwt

doja_3_5

j2me_wbmp

j2me_rmf

j2me_wma

j2me_left_softkey_code

j2me_jtwi

j2me_jpg

j2me_return_key_code

j2me_real8

j2me_max_record_store_size

j2me_realmedia

j2me_midp_1_0

j2me_bmp3

j2me_midi

j2me_btapi

j2me_siemens_extension

j2me_h263

j2me_audio_capture_enabled

j2me_midp_2_0

j2me_datefield_no_accepts_null_date

j2me_aac

j2me_capture_image_formats

j2me_select_key_code

j2me_xmf

j2me_photo_capture_enabled

j2me_realaudio

j2me_realvideo

j2me_mp3

j2me_png

j2me_au

j2me_screen_width

j2me_mp4

j2me_mmapi_1_0

j2me_http

j2me_imelody

j2me_socket

j2me_3dapi

j2me_bits_per_pixel

j2me_mmapi_1_1

j2me_udp

j2me_wav

j2me_middle_softkey_code

j2me_svgt

j2me_gif

j2me_siemens_color_game

j2me_max_jar_size

j2me_wmapi_1_0

j2me_nokia_ui

j2me_screen_height

j2me_wmapi_1_1

j2me_wmapi_2_0

doja_1_0

j2me_serial

doja_2_0

j2me_bmp

j2me_amr

j2me_gif89a

j2me_cldc_1_0

doja_2_1

doja_3_0

j2me_cldc_1_1

doja_2_2

doja_4_0

j2me_3gpp

j2me_video_capture_enabled

j2me_canvas_height

j2me_https

j2me_mpeg4

j2me_storage_size


boolean

boolean

double precision

double precision

double precision

double precision

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

double precision

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean


double precision

boolean

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

boolean

double precision

boolean

boolean

boolean

double precision

boolean

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

double precision

mms

id

mms_3gpp

mms_wbxml

mms_symbian_install

mms_png

mms_max_size

mms_rmf

mms_nokia_operatorlogo

mms_max_width

mms_max_frame_rate

mms_wml

mms_evrc

mms_spmidi

mms_gif_static

mms_max_height

sender

mms_video

mms_vcard

mms_nokia_3dscreensaver

mms_qcelp

mms_midi_polyphonic

mms_wav

mms_jpeg_progressive

mms_jad

mms_nokia_ringingtone

built_in_recorder

mms_midi_monophonic

mms_3gpp2

mms_wmlc

mms_nokia_wallpaper

mms_bmp

mms_vcalendar

mms_jar

mms_ota_bitmap

mms_mp3

mms_mmf

mms_amr

mms_wbmp

built_in_camera

receiver

mms_mp4

mms_xmf

mms_jpeg_baseline

mms_midi_polyphonic_voices

mms_gif_animated


boolean

boolean

boolean

boolean

double precision

boolean

boolean

double precision

double precision

boolean

boolean

boolean

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

sms

id

ems

text_imelody

nokiaring

siemens_logo_height

ems_variablesizedpictures

sckl_groupgraphic

siemens_ota

sagem_v1

largeoperatorlogo

sagem_v2

ems_version

ems_odi

nokiavcal

operatorlogo

siemens_logo_width

ems_imelody

sckl_vcard

siemens_screensaver_width

sckl_operatorlogo

panasonic

ems_upi

nokiavcard

callericon

gprtf

siemens_screensaver_height

sckl_ringtone

picturemessage

sckl_vcalendar


boolean

boolean

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

boolean

double precision

boolean

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

boolean

mobile_device

id

phone_number

brand

model

id_device

SERIAL





<pk>

product_info

id

is_transcoder

mobile_browser

has_pointing_device

device_os

nokia_series

has_qwerty_keyboard

pointing_method

mobile_browser_version

nokia_edition

uaprof

can_skip_aligned_link_row

device_claims_web_support

ununiqueness_handler

model_name

device_os_version

uaprof2

is_wireless_device

uaprof3

brand_name

model_extra_info

marketing_name

release_date

unique


boolean


boolean


double precision

boolean



double precision


boolean

boolean





boolean






boolean

FK_MOBILE_D_REFERENCE_IMAGE_FO

FK_MOBILE_D_REFERENCE_MMS

FK_MOBILE_D_REFERENCE_PRODUCT_

FK_MOBILE_D_REFERENCE_J2ME

FK_MOBILE_D_REFERENCE_DISPLAY

FK_MOBILE_D_REFERENCE_SMS

display

id

columns

rows

max_image_width

resolution_height

resolution_width

max_image_height

physical_screen_height

physical_screen_width


double precision

double precision

double precision

double precision

double precision

double precision

double precision

double precision

image_format

id

greyscale

jpg

gif

transparent_png_index

epoc_bmp

bmp

wbmp

gif_animated

colors

svgt_1_1_plus

svgt_1_1

transparent_png_alpha

png

tiff


boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

integer

boolean

boolean

boolean

boolean

boolean

j2me

id

doja_1_5

j2me_datefield_broken

j2me_clear_key_code

j2me_right_softkey_code

j2me_heap_size

j2me_canvas_width

j2me_loctapi

j2me_motorola_lwt

doja_3_5

j2me_wbmp

j2me_rmf

j2me_wma

j2me_left_softkey_code

j2me_jtwi

j2me_jpg

j2me_return_key_code

j2me_real8

j2me_max_record_store_size

j2me_realmedia

j2me_midp_1_0

j2me_bmp3

j2me_midi

j2me_btapi

j2me_siemens_extension

j2me_h263

j2me_audio_capture_enabled

j2me_midp_2_0

j2me_datefield_no_accepts_null_date

j2me_aac

j2me_capture_image_formats

j2me_select_key_code

j2me_xmf

j2me_photo_capture_enabled

j2me_realaudio

j2me_realvideo

j2me_mp3

j2me_png

j2me_au

j2me_screen_width

j2me_mp4

j2me_mmapi_1_0

j2me_http

j2me_imelody

j2me_socket

j2me_3dapi

j2me_bits_per_pixel

j2me_mmapi_1_1

j2me_udp

j2me_wav

j2me_middle_softkey_code

j2me_svgt

j2me_gif

j2me_siemens_color_game

j2me_max_jar_size

j2me_wmapi_1_0

j2me_nokia_ui

j2me_screen_height

j2me_wmapi_1_1

j2me_wmapi_2_0

doja_1_0

j2me_serial

doja_2_0

j2me_bmp

j2me_amr

j2me_gif89a

j2me_cldc_1_0

doja_2_1

doja_3_0

j2me_cldc_1_1

doja_2_2

doja_4_0

j2me_3gpp

j2me_video_capture_enabled

j2me_canvas_height

j2me_https

j2me_mpeg4

j2me_storage_size


boolean

boolean

double precision

double precision

double precision

double precision

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

double precision

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean


double precision

boolean

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

boolean

double precision

boolean

boolean

boolean

double precision

boolean

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

double precision

mms

id

mms_3gpp

mms_wbxml

mms_symbian_install

mms_png

mms_max_size

mms_rmf

mms_nokia_operatorlogo

mms_max_width

mms_max_frame_rate

mms_wml

mms_evrc

mms_spmidi

mms_gif_static

mms_max_height

sender

mms_video

mms_vcard

mms_nokia_3dscreensaver

mms_qcelp

mms_midi_polyphonic

mms_wav

mms_jpeg_progressive

mms_jad

mms_nokia_ringingtone

built_in_recorder

mms_midi_monophonic

mms_3gpp2

mms_wmlc

mms_nokia_wallpaper

mms_bmp

mms_vcalendar

mms_jar

mms_ota_bitmap

mms_mp3

mms_mmf

mms_amr

mms_wbmp

built_in_camera

receiver

mms_mp4

mms_xmf

mms_jpeg_baseline

mms_midi_polyphonic_voices

mms_gif_animated


boolean

boolean

boolean

boolean

double precision

boolean

boolean

double precision

double precision

boolean

boolean

boolean

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

sms

id

ems

text_imelody

nokiaring

siemens_logo_height

ems_variablesizedpictures

sckl_groupgraphic

siemens_ota

sagem_v1

largeoperatorlogo

sagem_v2

ems_version

ems_odi

nokiavcal

operatorlogo

siemens_logo_width

ems_imelody

sckl_vcard

siemens_screensaver_width

sckl_operatorlogo

panasonic

ems_upi

nokiavcard

callericon

gprtf

siemens_screensaver_height

sckl_ringtone

picturemessage

sckl_vcalendar


boolean

boolean

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

boolean

double precision

boolean

boolean

double precision

boolean

boolean

boolean

boolean

boolean

boolean

double precision

boolean

boolean

boolean

mobile_device

id

phone_number

brand

model

id_device

SERIAL





<pk>

product_info

id

is_transcoder

mobile_browser

has_pointing_device

device_os

nokia_series

has_qwerty_keyboard

pointing_method

mobile_browser_version

nokia_edition

uaprof

can_skip_aligned_link_row

device_claims_web_support

ununiqueness_handler

model_name

device_os_version

uaprof2

is_wireless_device

uaprof3

brand_name

model_extra_info

marketing_name

release_date

unique


boolean


boolean


double precision

boolean



double precision


boolean

boolean





boolean






boolean

CAPÍTULO IV

IMPLEMENTACIÓN En este capítulo se describen las clases implementadas que muestran la funcionalidad del

sistema.

Capítulo IV Implementación

Página 78

4. Implementación En este apartado se muestran segmentos de código que describen la funcionalidad de la

aplicación Web SketchMapServer. El desarrollo de la aplicación se desarrolló bajo las

siguientes descripciones técnicas de la plataforma de desarrollo:

IDE Netbeans 6.8 Beta Java 2 Enterprise Edition versión 1.5 Java Micro Edition SDK 3.0 Manejador de base de datos PostgreSQL 8.3 Extensión PostGIS para PostgreSQL versión 1.3 Servidor web Apache Tomcat versión 6.0 Servidor de mapas Geoserver versión1.7 Sistema Operativo Windows Vista Home Edition

4.1 Recibir petición HTTP

En la Figura 4-1 se muestra la recepción de la petición HTTP enviada por el cliente, las

clases involucradas están contenidas en el paquete mx.edu.cenidet.gateway.servlets. En

las líneas 37 a la 40 se presenta el método doGet haciendo referencia al método que

procesará la petición recibida llamado processRequest. Los datos de la petición recibida

se obtienen mediante la propiedad getParameter de la petición HttpServletRequest,

mismas que se visualizan en las líneas del 17 a la 19.

1 package mx.edu.cenidet.gateway.servlets;

2 3 public class servletSketchMap extends HttpServlet { 4 String categoria, mapa,distancia, longitud, latitud,trama; 5 String user, password;

6 RegistroUsuarioDAO regUser; 7 PrintWriter out; 8 protected void processRequest(HttpServletRequest request, HttpServletResponse response) 9 throws ServletException, IOException {

10 11 response.setContentType(“text/html;charset=UTF-8”); 12 out = response.getWriter(); 13 Document doc = new Document();

14 15 Main croquis = new Main(); 16 try { 17 trama = request.getParameter(“trama”);

18 user = request.getParameter(“user”); 19 password = request.getParameter(“password”); 20 21 regUser = new RegistroUsuarioDAO();

22 if(regUser.BuscarUsuario(user, password)){ 23 croquis.generateSketchMap(trama); 24 if(croquis.getDataPointOfInterest().getNumReg()>0){ 25 doc = croquis.getMap();

26 }else{ 27 //Error 28 } 29 } 30 }catch(Exception e){

31 e.printStackTrace(); 32 }finally {


Página 79

33 error(croquis);

34 out.close(); 35 } 36 } 37 protected void doGet(HttpServletRequest request, HttpServletResponse response)

38 throws ServletException, IOException { 39 processRequest(request, response); 40 } 41 }

Figura 4-1 Recepción de la petición HTTP.

4.2 Interpretar la petición HTTP

En esta sección se describe la interpretación de la petición HTTP, las clases involucradas

son servletSketchMap y Main contenidas en el paquete mx.edu.cenidet.gateway.{servlet,

mmsserver}. En la línea 23 de la Figura 4-2 se muestra el envío de la trama como

parámetro al método principal generateSketchMap(String) de la clase Main para generar

el mapa, en la Figura 4-2 se muestran las líneas donde recibe la trama, se interpreta en

las líneas 9 y 10 por métodos de la API SMSMMS, finalmente se imprimen los datos

obtenidos indicado en la línea 11.

1 public class Main { 2 public Main(){} 3

4 public void generateSketchMap(String trama){ 5 message = new Mensaje(); 6 try { 7 //Recibir e interpretar Mensaje

8 message.RecibeTrama(trama); 9 poi = new PoiGeoreferenciado(); 10 poi = message.LeeGeoSiguiente(); 11 printMessage(trama);

12 13 md = new MobileDeviceDAO(); 14 if (md.SearchMobileDevice(“Nokia”, “N96”)==true){ 15 //Empieza el proceso de generación del mapa SVGTiny

16 } 17 … 18 } catch (MensajeExcepcion ex) { 19 System.out.println(“La trama no es la correcta!”);

20 } 21 }

Figura 4-2 Interpretación de la petición HTTP

4.3 Conexión a las bases de datos

En esta sección se describe la conexión a la base de datos Postgres, las clases están

contenidas en el paquete mx.edu.cenidet.gateway.database, en la Figura 4-3 se muestra

el conector que realiza la configuración de postgres en las líneas 7 a la 11 que cuenta con

una url, el usuario que tiene acceso a la base de datos y password, en donde la url está

compuesta por los parámetros del servidor y el puerto que indican la dirección en la que

se encuentra instalada la base de datos.

1 public class postgres


Página 80

2 {

3 public Connection getConexionPostgres() 4 { 5 if(conPostgres != null) 6 return conPostgres;

7 url = “jdbc:postgresql://” + servidor + “:” + puerto + “/” + bdMobile; 8 try{ 9 Class.forName(“org.postgresql.Driver”); 10 conPostgres = DriverManager.getConnection(url, usuario, password);

11 return conPostgres; 12 } 13 catch(Exception exception){ 14 System.out.println(“Error al conectarse: “ + exception.toString()); 15 }

16 return null; 17 } 18 }

Figura 4-3 Conexión a la base de datos Postgres

En la siguiente figura se especifica en las líneas 15 y 16 que la conexión permite acceder

a datos geométricos de Postgis.

1 import java.io.PrintStream;

2 import java.sql.*; 3

4 public class Postgis 5 {

6 public Connection getConexionPostGIS() 7 { 8 if(conPostGIS != null) 9 return conPostGIS;

10 11 url = “jdbc:postgresql://” + servidor + “:” + puerto + “/” + baseDatos;

12 try{ 13 Class.forName(“org.postgresql.Driver”);

14 conPostGIS = DriverManager.getConnection (url, usuario, password);

15 ((org.postgresql.PGConnection)conPostGIS).addDataType(“geometry”, “org.postgis.PGgeometry”);

16 ((org.postgresql.PGConnection)conPostGIS).addDataType(“box3d”,”org.postgis.PGbox3d”);

17 18 return conPostGIS;

19 } catch(Exception exception){ 20 System.out.println(“Error al conectarse: “ + exception.toString()); }

21 return null; 22 } 23 }

Figura 4-4 Conexión a la extensión PostGIS de la base de datos Postgres

La Figura 4-5 muestra un ejemplo de conexión a la base de datos espacial descrita por los

siguientes pasos:

1. Se instancia un objeto de la clase Postgis. 2. Se inicializan las variables, se obtienen los datos de la configuración del archivo de

configuración. 3. Se crea un objeto de tipo Connection al cual se le asigna la conexión Postgis

mediante el método instanciado pg.getConexionPostGIS, mostrado en la línea 11. 4. Se llevan a cabo las consultas.


Página 81

1 import java.io.InputStream;

2 import java.sql.Connection; 3 … 4 public class generarMapaCroquis { 5 …

6 public datosPuntoFinal buscandoDestinos() 7 { 8 //Se realiza la conexion a Postgis 9 Postgis pg = new Postgis();

10 pg.Inicializar(); 11 Connection cn = pg.getConexionPostGIS(); 12 13 //Se crea el objeto para realizar consultas a la base de datos 14 cbd = new consultaBaseDatos();

15 //Se crea el objeto que contendrá los puntos destinos 16 dpf = new datosPuntoFinal(); 17

18 //Se identifica la ciudad y el estado a ubicar el punto destino

19 if (cbd.buscarIdCiudad(cn, estado, municipio)){ 20 dpf = cbd.buscarPuntoFinal(cn, dpf, dm); 21 } 22 return dpf;

23 } 24 … 25 }

Figura 4-5 Ejemplo de conexión a la base de datos

4.3.1 Obtener el perfil del dispositivo móvil

En esta sección se describe la obtención del perfil del dispositivo, las clases están

contenidas en el paquete mx.edu.cenidet.gateway.mobiledevice, en la Figura 4-6 se

muestra en las líneas 12 a la 22 la creación de la sentencia SQL que permite obtener las

características del dispositivo móvil contenidas en la base de datos relacional

mobiledevice. El perfil del dispositivo es agregado al objeto dmd que es una instancia de

la clase DataMobileDevice, que permite tener de manera temporal las características

principales del dispositivo móvil.

1 public class MobileDeviceDAO { 2 public boolean SearchMobileDevice(String brand, String model){ 3 4 dmd = new DataMobileDevice();

5 6 postgres conexion = new postgres(); 7 …. 8 if(cn != null){ 9 try{

10 Statement s = cn.createStatement(); 11 12 SELECT = “select d.id, pi.brand_name,pi.model_name,d.max_image_width,

d.max_image_height, d.resolution_height, d.resolution_width, d.physical_screen_height, d.physical_screen_width, pi.mobile_browser, pi.mobile_browser_version, pi.device_os,pi.release_date, m.receiver,m.sender,m.mms_max_size, j.j2me_midp_2_0, j.j2me_cldc_1_1

13 FROM = “FROM display as d, product_info as pi, j2me as j, mms as m”;

14 WHERE = “WHERE pi.model_name=‟” + model + “‟ “ + 15 “AND pi.brand_name=‟” + brand + “‟ “ + 16 “AND pi.id=d.id “+


Página 82

17 “AND m.id=pi.id “+

18 “AND j.id=pi.id “+ 19 “AND m.receiver=‟t‟ “+ 20 “AND j.j2me_midp_2_0=‟t‟ “+ 21 “AND j.j2me_cldc_1_1=‟t‟”;

22 strSQL = SELECT + “ “ + FROM + “ “ + WHERE; 23 24 ResultSet rs = s.executeQuery(strSQL); 25 rs.next();

26 27 dmd.setIdDevice(rs.getString(1)); 28 dmd.setBrand(rs.getString(2)); 29 dmd.setModel(rs.getString(3)); 30 dmd.setWidth(rs.getInt(4));

31 dmd.setHeight(rs.getInt(5)); 32 dmd.setHeightResolution(rs.getString(6)); 33 dmd.setWidthResolution(rs.getString(7)); 34 dmd.setWidthDisplay(rs.getString(8));

35 dmd.setHeightDisplay(rs.getString(9)); 36 dmd.setTypeBrowser(rs.getString(10)); 37 dmd.setVersionTypeBrowser(rs.getString(11)); 38 dmd.setSystem(rs.getString(12));

39 dmd.setRelease(rs.getString(13)); 40 dmd.setReceiveMMS(rs.getString(14)); 41 dmd.setSendMMS(rs.getString(15)); 42 dmd.setSizeMaxMMS(rs.getString(16));

43 dmd.setMIDP_2_0(rs.getString(17)); 44 dmd.setCLDC_1_1(rs.getString(18)); 45 46 if (dmd.getIdDevice().length()>0){

47 found=true; 48 }else 49 found = false; 50 }

51 catch (SQLException sqlexception){ 52 found=false; 53 } 54 }

55 return found; 56 }

Figura 4-6 Obtención del perfil del dispositivo móvil

4.3.2 Obtener puntos de interés

La obtención de los puntos de interés se realizan mediante consultas a la base de datos

espacial, las clases DataPointOfInterest y PointOfInterestDAO se encuentran en el

paquete mx.edu.cenidet.gateway.maps. La clase DataPointOfInterest contiene una lista

de los puntos de interés que localiza la clase PointOfInterestDAO que accede a la base de

datos mediante consultas espaciales, en las líneas 7 a la 10 de la Figura 4-7 se construye

la sentencia SQL para realizar la consulta que extrae los puntos de interés de la base de

datos, los puntos se agregan al objeto que es instanciado de la clase DataPointOfInterest.

1 public void SearchPointOfInterest(String state, String city, PoiGeoreferenciado poi){ 2 //Se realiza la conexion a Postgis

3 postgis pg = new postgis(); 4 5 if(foundCity==true){


Página 83

6 try{

7 SELECT = “SELECT AsText(the_geom), X(the_geom), Y(the_geom), distance(s.the_geom, GeometryFromText(„POINT(“ + poi.LeeLongitudG() + “ “ + poi.LeeLatitudG() + “)‟, - 1))*100000 as distancia, s.nomservicio, col.descripcion, s.calle, s.numero, col.cp”;

8 FROM = “FROM servicios As s, categoria As c, colonia As col”;

9 WHERE = “WHERE distance(s.the_geom, GeometryFromText(„POINT(“ + poi.LeeLongitudG() + “ “ + poi.LeeLatitudG() + “)‟, -1))*100000 <= “ + poi.LeeDistancia() + “AND s.idcategoria = c.idcategoria And col.idestado = “ + idEstado + “ AND col.idmunicipio = “ + idMunicipio + “ AND col.idcolonia = s.colonia and s.idcategoria = (“ + AUXstrSQL +”) “ + “ORDER BY distancia”;

10 strSQL = SELECT + “ “ + FROM + “ “ + WHERE; 11 ResultSet rs1 = s.executeQuery(strSQL); 12 13 for (int i=0; i<dpoi.getNumReg();i++){

14 rs1.next(); 15 16 dpoi.setPoint(rs1.getString(1)); 17 dpoi.setXPoint(rs1.getString(2));

18 dpoi.setYPoint(rs1.getString(3)); 19 dpoi.setDistance(rs1.getString(4)); 20 dpoi.setNameService(rs1.getString(5)); 21 dpoi.setDescription(rs1.getString(6));

22 dpoi.setStreet(rs1.getString(7)); 23 dpoi.setNumber(rs1.getString(8)); 24 dpoi.setCode(rs1.getString(9)); 25 }

26 dpoi.setEstado(state); 27 dpoi.setMunicipio(city); 28 29 }

30 }catch(SQLException sqlexception){} 31 } 32 }

Figura 4-7 Obtención de los puntos de interés

4.3.3 Obtener puntos de referencia

Los puntos de referencia se extraen de la base de datos espacial mediante consultas

espaciales, las clases MapPOR y MapPORDAO se encuentran en el paquete

mx.edu.cenidet.gateway.maps. La clase MapPOR contiene una lista de los puntos de

referencia que localiza la clase MapPORDAO que accede a la base de datos mediante

consultas espaciales. En las líneas 9 a la 11 de la Figura 4-8 se extraen las coordenadas

geoespaciales de los nodos de la ruta, con el fin de obtener los puntos de referencia de

cada intersección de calles, en las líneas 16 a la 19 se construye la sentencia SQL para

realizar la consulta que extrae los puntos de referencia de la base de datos, las líneas 23

al 33 depuran los puntos de referencia al realizar una búsqueda en la lista points, los

puntos de referencia se agregan al objeto instanciado de la clase MapPOR.

1 public void obtenerPOIs(PoiGeoreferenciado poi, DataPointOfInterest dpoi,ArrayList<String> pois){ 2

3 try { 4 Postgis pg = new Postgis(); 5 Connection c = pg.getConexionPostGIS(); 6 …

7 8 for(int i=0;i<cont;i++){


Página 84

9 String p[] = pois.get(i).split(“ “);

10 11 double longitudPOI = Double.parseDouble(p[0]); 12 double latitudPOI = Double.parseDouble(p[1]); 13

14 //Obteniendo los puntos de referencia 15 Statement stRPG = c.createStatement(); 16 SELECT = “SELECT distinct s.nomservicio,s.calle,s.numero,c.descripcion,distance(the_geom,

GeomFromText(„POINT(“+ longitudPOI +” “+ latitudPOI +”)‟, -1))*100000 as distancia, astext(the_geom) as point, s.idcategoria “;

17 FROM =”FROM servicios as s, colonia as c “; 18 WHERE = “WHERE distance( s.the_geom, GeometryFromText(„POINT(“+ longitudPOI +” “ +

latitudPOI + “)‟, -1))*100000 <= “ + 20 + “AND c.idestado=”+ dpoi.getIdestado() +” AND c.idmunicipio=” + dpoi.getIdmunicipio() + “ AND c.idcolonia=s.colonia ORDER BY distancia”;

19 strSQL = SELECT + “ “ + FROM + “ “ + WHERE; 20 ResultSet rsRPG = stRPG.executeQuery(strSQL); 21 22 boolean ban=false;

23 while(rsRPG.next()){ 24 if(numPReferencia>0){ 25 String aux=””; 26 aux=rsRPG.getString(6);

27 //Eliminando puntos de referencias existentes 28 for(int m=0;m<numPReferencia;m++){ 29 if(aux.equals(points[m] )){ 30 ban=true;

31 } 32 } 33 } 34 if(ban==false){

35 servicio[numPReferencia] = rsRPG.getString(1); 36 calle[numPReferencia] = rsRPG.getString(2); 37 numero[numPReferencia] = rsRPG.getString(3); 38 descripcion[numPReferencia] = rsRPG.getString(4);

39 distancia[numPReferencia] = rsRPG.getString(5); 40 points[numPReferencia] = rsRPG.getString(6); 41 idcategoria[numPReferencia] = rsRPG.getString(7); 42 numPReferencia++;

43 } 44 } 45 } 46 } catch (SQLException ex) {}

47 48 }

Figura 4-8 Obtención de los puntos de referencia

4.4 Generar mapa SVGTiny

Las clases del paquete mx.edu.cenidet.gateway.maps son las que permiten la generación

de los datos que se agregaran al mapa croquis SVGTiny, por otro lado, las clases de

paquete mx.edu.cenidet.gateway.svgt son las que realizan la conversión de la imagen

SVG a SVGTiny y contiene funciones que permiten agregar elementos al mapa, tales

como línea, círculo y texto.

A continuación se mostrarán los métodos principales que permiten la generación del

mapa:

1. Obtención del mapa imagen


Página 85

2. Conversión del archivo SVG a SVGTiny

3. Obtención de la ruta

4. Obtención de los puntos de referencia

5. Convertir las coordenadas georeferenciales a pixeles

6. Anadir los datos convertidos al SVGTiny

En la Figura 4-9 se muestra la clase Main, esta clase permite instanciar clases para

obtener los métodos que realizan la funcionalidad de los puntos mencionados

anteriormente.

1 package mx.edu.cenidet.gateway.mmsserver;

2 public class Main { 3 public Main(){} 4 5 public void generateSketchMap(String trama){

6 message = new Mensaje(); 7 try { 8 …. 9 if(dpoi.getNumReg()>0){

10 // Generar el área de búsqueda BBOX 11 …. 12 dmi.setGeoPOI(poi.LeeDistancia()); 13 dmi.printBBOX();

14 15 // 1. Obtener el mapa imagen svg 16 mi = new MapImage(); 17 mi.generateMap(md.getDataMobileDevice(),dmi.getBBOX());

18 dwms = mi.getWMS(); 19 20 // 2. Conversion de svg a svgt 21 svgt = convertSVGT(mi.getFileInputStreamMap());

22 for(int i=0; i< dpoi.getNumReg();i++){ 23 // 3. Obtener ruta de los puntos de interes 24 mr = new MapRoute(); 25 DataPointOfInterest DatoPOI = poiDAO.getDataPointOfInterest(); 26

27 mr.createRouteLayer(poi,md.getDataMobileDevice(), DatoPOI.getXPoint(i), 28 DatoPOI.getYPoint(i), dmi.getBOX3D()); 29 30 dmr = mr.getDataMapRoute();

31 route = mr.getRouteGeospatial(); 32 33 // 4. Obtener Puntos de Referencia 34 mPOR = new MapPOR();

35 //Existen punntos de referenca? 36 37 if(mPOR.createPORLayer(mr.getDataMapRoute(),poi,poiDAO.getDataPointOfInterest())){ 38 numLayer = numLayer+1;

39 POR = mPOR.getPOR(); 40 dmr.setPORGeoespatial(POR); 41 dmr.PORGeoespatial(dmd, dmi.getBOX3D()); 42

43 // 5. Convertir las coordenadas georefenciales a pixeles 44 dmr.setRouteGeoespatial(getRouteGeospatial()); 45 String ruta = dmr.convertGeoRefToPixel(dmd, dmi.getBOX3D()); 46

47 dmr.setPORGeoespatial(getPOR());


Página 86

48 String por = dmr.PORGeoespatial(dmd, dmi.getBOX3D());

49 50 // 6. Anadir los datos al svgt 51 if(numLayer==1){ 52 addOrigenToMap(svgt,Double.parseDouble(poi.LeeLongitudG()),

53 Double.parseDouble(poi.LeeLatitudG()), 54 “Origen”); 55 } 56

57 addDestinityToMap(svgt, DatoPOI.getXPoint(i), DatoPOI.getYPoint(i), 58 DatoPOI.getNameService(i),numLayer); 59 addLayer(svgt,ruta, por,numLayer, mPOR.getDistance()); 60 }else{ 61 //No existen puntos de referencia para esta capa

62 } 63 ….. 64 } catch (MensajeExcepcion ex) { System.out.println(“La trama no es la correcta!”); } 65 }

Figura 4-9 Obtención del mapa SVGTiny

El BBOX9 forma parte esencial en este proyecto, ya que es el área de interés donde se

realiza todo el procesamiento para la obtención del mapa. Esta área delimita lo siguiente:

a. Área a mostrar de la ciudad, es decir el croquis sin información que se

obtiene del servidor de mapas.

b. Delimita la red de calles para obtener el grafo del cual se obtendrá la ruta.

c. Los puntos obtenidos de la ruta serán esenciales para la obtención de los

puntos de referencia en el área descrito por el BBOX.

Este método tiene la funcionalidad de localizar las coordenadas longitud-latitud menor y

mayor a partir de los puntos de interés obtenidos de la petición, esto para generar el par

de coordenadas mínimos y máximos del BBOX que representa el área pertinente de

búsqueda, dicho proceso se muestran en las líneas 12 a la 36 de la Figura 4-10. Para

acceder al BBOX generado se llama al método getBBOX localizado en la línea 43.

1 public class DataMapImage { 2 public DataMapImage(){}

3 public void setGeoPOI(DataPointOfInterest dpoi){ 4 ArrayList<Double> x = new ArrayList<Double>(); 5 ArrayList<Double> y = new ArrayList<Double>(); 6 …..

7 for(int i=0; i < dpoi.getNumReg(); i++){ 8 x.add(dpoi.getXPoint(i)); 9 y.add(dpoi.getYPoint(i)); 10

11 } 12 for(int i=0; i < x.size()-1; i++){ 13 if(x.get(i) < x.get(i+1) && x.get(i)<xMin){ 14 xMin = x.get(i);

15 }else if(x.get(i+1)<xMin){ 16 xMin = x.get(i+1);

9 BBOX(Bounding Box): Es un rectángulo orientado por líneas x-y, contiene un conjunto de datos geográficos

especificado por dos coordenadas: xmin, ymin and xmax, ymax.


Página 87

17 }

18 19 if(x.get(i) > x.get(i+1) && x.get(i)>xMax){ 20 xMax = x.get(i); 21 }else if(x.get(i+1)>xMax){

22 xMax = x.get(i+1); 23 } 24 25 if(y.get(i) < y.get(i+1) && y.get(i)<yMin){

26 yMin = y.get(i); 27 }else if(y.get(i+1)<yMin){ 28 yMin = y.get(i+1); 29 } 30

31 if(y.get(i) > y.get(i+1) && y.get(i)>yMax){ 32 yMax = y.get(i); 33 }else if(y.get(i+1)>yMax){ 34 yMax = y.get(i+1);

35 } 36 } 37 38 xMin=xMin – 0.0010;

39 xMax=xMax + 0.0010; 40 yMin=yMin – 0.0010; 41 yMax=yMax + 0.0010; 42 }

43 public String getBBOX(){ 44 return xMin+”,”+yMin+”,”+xMax+”,”+yMax; 45 } 46 }

Figura 4-10 Generación y obtención del área de interés (BBOX)

En la Figura 4-11 se muestra el método que obtiene el mapa SVG del servidor de mapas

es necesario contar con una URL que realice la petición mediante WMS. Por ello se crea

la URL con los parámetros mostrados en las líneas del 6 a la 17 (URL del servidor,

petición getMap, formato del mapa, tamaño del mapa, transparencia, SRS y el BBOX) que

requiere el servidor de mapa para dar una respuesta. Posteriormente en las líneas de la

17 a la 34 se muestra cómo se procesa el mapa que el servidor da como respuesta de la

petición WMS realizada.

1 public class MapImage { 2 public MapImage(){} 3 4 public void generateMap(DataMobileDevice dmd, String BBOX){

5 try { 6 URL wmsURL = new URL(dwms.getURL()); 7 wms = new WebMapServer(wmsURL); 8 GetMapRequest gmrq = wms.createGetMapRequest();

9 gmrq.setFormat(dwms.getFORMAT()); 10 gmrq.setDimensions(dwms.getWIDTH(),dwms.getHEIGHT()); 11 gmrq.setTransparent(dwms.getTRANSPARENT()); 12 gmrq.setSRS(dwms.getSRS());

13 gmrq.setBBox(dwms.getBBOX()); 14 15 gmrq.addLayer(dwms.getLAYERS(), dwms.getSTYLES()); 16


Página 88

17 GetMapResponse gmrp = (GetMapResponse) wms.issueRequest(gmrq);

18 19 Path path = new Path(); 20 String Dir =path.getImagePATH() + NameImage + “.svg”; 21

22 if (dwms.getFORMAT().equals(“svg”) || dwms.getFORMAT().equals(“svg+xml”) 23 || dwms.getFORMAT().equals(“image/svg+xml”)) { 24 InputStream iss = gmrp.getInputStream(); 25 is=iss;

26 File ff = new File(Dir); 27 28 FileOutputStream fo = new FileOutputStream(ff); 29 int c = -1; 30 while ((c = iss.read()) != -1) {

31 fo.write©; 32 } 33 fo.close(); 34 }

35 } catch (IOException ex) { System.out.println(“Error: Can‟t proccess the image.”); 36 } catch (ServiceException ex) { System.out.println(“Error: Web Server is down.”); } 37 }

Figura 4-11 Obtención del mapa SVG

JDOM se utiliza para la conversión del mapa SVG que se obtiene del servidor de mapas a

SVG-Tiny, para ello se crearon dos objetos uno para lectura y el otro para escritura. El

primero se encarga de leer las líneas de la imagen SVG y se añaden a un nuevo

elemento root. La característica principal de los SVGTiny es que cuentan con dos

atributos: versión 1.1 y baseProfile tiny, dichos atributos son agregados a la etiqueta svg

del SVGTiny y se muestran en las líneas del 17 a la 19. En la línea 49 se añaden al

elemento childLayerMap los hijos del elemento root contenidos en el SVG, que

posteriormente son ingresados al rootSVGT (líneas 57,58), finalmente en la línea 61 se

añade al documento SVGTiny los elementos rootSVGT y su docType.

1 public class SVGToSVGT { 2 public SVGToSVGT(){} 4

5 public void convertSVGtoSVGT(){ 6 //get element root of SVG file and attributes 7 Element root = documentRead.getRootElement(); 8 List rootAtributes = root.getAttributes();

9 10 //Create root SVGT and set the attributes 11 Namespace name = Namespace.getNamespace(“http://www.w3.org/2000/svg”); 12

13 Element rootSVGT = new Element(“svg”); 14 rootSVGT.setNamespace(name); 15 String width=””, height=””; 16 …..

17 rootSVGT.setAttribute(“version”, “1.1”); 18 rootSVGT.setAttribute(“baseProfile”, “tiny”); 19 rootSVGT.setAttribute(“viewBox”, “0 0 “+ width +” “+height); 20

21 Namespace namespace = Namespace.getNamespace(“xlink”,”http://www.w3.org/1999/xlink”); 22 rootSVGT.addNamespaceDeclaration(namespace); 23 24 //List Children of the root

http://www.w3.org/2000/svg

http://www.w3.org/1999/xlink


Página 89

25 List rootChildren = root.getChildren();

26 27 //Creating children of SVG 28 Element layerMapSVGT = new Element(“g”,name); 29 Element defs = new Element(“defs”,name);

30 …. 31 for(int i=0; i< rootChildren.size();i++){ 32 Element elementChild = (Element) rootChildren.get(i); 33 String rootNameElementChildren = elementChild.getName();

34 35 if(rootNameElementChildren.equals(“g”)){ 36 layerMapSVGT.setAttribute(“id”, “capa0”); 37 layerMapSVGT.setAttribute(“display”, “inline”); 38 layerMapSVGT.setAttribute(“stroke”, “black”);

39 40 List rootElementChildren2 = elementChild.getChildren(); 41 42 for(int j=0;j<rootElementChildren2.size();j++){

43 …. 44 List rootElementChildren3 = elementChild2.getChildren(); 45 46 for(int l =0;l<rootElementChildren3.size();l++){

47 for(int m=0; m < childAttributes.size();m++){ 48 Attribute attr = (Attribute) childAttributes.get(m); 49 childLayerMap.setAttribute(attr.getName(), attr.getValue()); 50 }

51 childrenLayerMap.addContent(childLayerMap); 52 } 53 layerMapSVGT.addContent(childrenLayerMap); 54 }

55 } 56 } 57 rootSVGT.addContent(defs); 58 rootSVGT.addContent(layerMapSVGT);

59 60 DocType doctype= new DocType(“svg”,”-//W3C//DTD SVG 1.1 Tiny//EN”,

“http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd”); 61 doc=new Document(rootSVGT,doctype);

62 }

Figura 4-12 Conversión SVG a SVGTiny

En la siguiente imagen se muestra la generación de la capa ruta, para ello se realizan

consultas a la base de datos espacial obteniéndose los nodos (intersección de calles y

calles finales) y aristas (calles conectadas mediante 2 nodos) para la generación del grafo

mostrados en las líneas 5 a la 14, mismo que se ingresa como parámetros al algoritmo de

ruta así como los nodos origen y destino escrito en la línea 25. La obtención de la ruta se

presenta en la línea 34.

1 public class MapRoute { 2 public MapRoute(){} 3

4 public void createRouteLayer(PoiGeoreferenciado poi,DataMobileDevice dmd, double Longitud, double Latitud, String BOX3D){

5 MapRouteDAO mrDAO = new MapRouteDAO(); 6 //Se obtienes las aristas

7 mrDAO.obtainDBStreet(poi, Longitud, Latitud, BOX3D);

http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd


Página 90

8

9 //Se obtienen los nodos 10 mrDAO.obtainDBNodes(poi, Longitud, Latitud, BOX3D); 11 12 //Detectando nodos finales y generando grafo

13 mrDAO.identifyingFinalNodes(); 14 mrDAO.generatingGraph(); 15 16 //Ejecutando algoritmo de ruta con el grafo generado

17 AlgoritmoRuta ar = new AlgoritmoRuta(); 18 int n = mrDAO.getNumberNodes(); 19 for(int i = 0; i <= n; i++) 20 { 21 ar.addNodo(new Nodo(“” + i));

22 } 23 24 double [][] grafo = mrDAO.getGrafo(); 25 for(int i=0;i<=n;i++)

26 for(int j=0;j<=n;j++){ 27 if(grafo[i][j]!=9999999){ 28 ar.addArista(new Arista(ar.getNodo(i),ar.getNodo(j),grafo[i][j])); 29 }

30 } 31 32 ArrayList al=ar.obtenerRutaCorta(ar.getNodo(getPOrigen()),ar.getNodo(getPDestino())); 33

34 layerRuta=”MULTILINESTRING((“; 35 layerRuta=layerRuta+mrDAO.getPuntoI(0)+” “+mrDAO.getPuntoI(1); 36 … 37 layerRuta=layerRuta+”))”;

38 }

Figura 4-13 Obtención de la ruta

Las coordenadas georeferenciales pueden ser positivas y negativas por lo que no pueden

ser representados en los dispositivos móviles, dichas coordenadas son convertidas a

pixeles mapeando el BBOX y la resolución del dispositivo móvil, la clase que realiza la

conversión se muestra en la Figura 4-14, los métodos getX y getY retornan las

coordenadas en pixeles.

1 public class Convert { 2 public void setCoordGeo(double nuevaXMin, double nuevaYMin, double nuevaXMax, double

nuevaYMax){ 3 // Se rechazan valores iguales de máximo y mínimo.

4 if (nuevaXMin == nuevaXMax) return; 5 if (nuevaYMin == nuevaYMax) return; 6

7 // Si los valores de x minimo y máximo están al revés, se guardan dándoles la vuelta.

8 if (nuevaXMin > nuevaXMax){

9 xMin = nuevaXMax; 10 xMax = nuevaXMin; 11 }else{ 12 xMin = nuevaXMin;

13 xMax = nuevaXMax; 14 } 15 // Si los valores de y minimo y máximo están al revés, se guardan dándoles la vuelta.

16 if (nuevaYMin > nuevaYMax){


Página 91

17 yMin = nuevaYMax;

18 yMax = nuevaYMin; 19 }else{ 20 yMin = nuevaYMin; 21 yMax = nuevaYMax;

22 } 23 } 24 25 public void setMapa(int nuevoAncho, int nuevoAlto){

26 // Se rechazan valores de 0 o negativos 27 if (nuevoAncho < 1) return; 28 if (nuevoAlto < 1) return; 29 30 ancho = nuevoAncho;

31 alto = nuevoAlto; 32 } 33 34 public int getX (double x){

35 int xPixel; 36 xPixel = (int)((x - xMin)/(xMax - xMin)*ancho); 37 return xPixel; 38 }

39 40 public int getY (double y){ 41 int yPixel; 42 yPixel = (int)(alto - (y - yMin)/(yMax - yMin)*alto);

43 return yPixel; 44 } 45 }

Figura 4-14 Conversión de coordenadas georeferenciales a pixeles

En la Figura 4-15 se muestra un ejemplo de conversión de coordenadas georeferenciales

a pixeles, en donde se deben especificar el área de conversión en coordenadas

georeferenciales, ingresando los parámetros como se muestran en la siguiente sentencia:

setCoordGeo(coordenadaXMin, coordenadaYMin, coordenadaXMax, coordenadaYMax)

Cabe señalar que las coordenadas se analizan si son efectivamente los mínimos y

máximos, en su defecto se ordenan cambiando las posiciones de los valores. Lo siguiente

es ingresar los pixeles que soporta el dispositivo móvil, para ello se ingresan los

parámetros como se muestra en la siguiente sentencia:

setMapa(Ancho, Alto)

Los pixeles que soporta el dispositivo móvil se extraen de la clase DataMobileDevice que

contiene el perfil del dispositivo móvil. Una vez realizado lo anterior, se ingresan las

coordenadas que se desean convertir llamando al método getX ó getY respectivamente.

1 public static void main(String args[]){ 2 Convert c = new Convert(); 3 c.setCoordGeo(-99.22550000000001,18.9042,-99.22269,18.9077); 4 c.setMapa(280, 232);

5


Página 92

6 System.out.println(c.getX(-99.2237));

7 System.out.println(c.getY(18.90667)); 8 }

Figura 4-15 Ejemplo para convertir coordenadas georeferenciales a pixeles

La clase ElementSVGT contiene métodos que son utilizados para representar las rutas y

los puntos de interés y referencia. Tales elementos son:

Line. Representa las líneas de la ruta.

Circle. Representa la ubicación de un punto de interés y un punto de referencia.

Text. Representa el nombre del punto de interés y un punto de referencia.

Estos elementos son consumidos por los métodos que contiene la clase mostrada en la

Figura 4-16, las cuales son:

dibujarLinea. Se presenta en las líneas 3 a la 37, en donde se agregan al

documento SVGTiny mediante métodos de la librería JDOM, se puede observar en

las líneas 19 a la 30 que se agrega la dirección de dicha línea siempre y cuando

sea mayor a 10mts.

dibujarPunto. Se presenta en las líneas 39 a la 75, en donde son agregados el

punto y texto que representan ya sea un punto de interés o un punto de referencia.

1 public class ElementSVGT { 2 …..

3 public void dibujarLinea(Document doc,Element element, float x1, float y1, float x2, float y2) { 4 this.doc = doc; 5 Document documento = doc.getDocument(); 6 Element root = (Element) documento.getDocument().getRootElement();

7 String namespace = root.getNamespaceURI(); 8 try { 9 Element elemento = new Element(“line”,namespace); 10 elemento.setAttribute(“x1”, x1+””); 11 elemento.setAttribute(“y1”, y1+””);

12 elemento.setAttribute(“x2”, x2+””); 13 elemento.setAttribute(“y2”, y2+””); 14 elemento.setAttribute(“stroke-width”, 2.5f+””); 15 elemento.setAttribute(“fill-opacity”, 0.5f+””);

16 elemento.setAttribute(“stroke”, “#0174DF”); 17 element.addContent(elemento); 18 19 ArrowDirection ad = new ArrowDirection();

20 ad.setLinea(x1, y1, x2, y2); 21 double distance = ad.calculaDistancia(x1, y1, x2, y2); 22 if(distance>10){ 23 double[] pm = ad.calculaPuntoMedio();

24 double angulo = ad.calculaAngulo(); 25 26 Namespace nsXlink = Namespace.getNamespace(“xlink”, “http://www.w3.org/1999/xlink”); 27 Element arrow = new Element(“use”,namespace);

28 arrow.setAttribute(“href”, “#Triangle”,nsXlink); 29 arrow.setAttribute(“transform”,”translate(“+pm[0]+” “+pm[1]+”) rotate(“+angulo+”)”); 30 element.addContent(arrow); 31 }

32 }


Página 93

33 catch(Exception e){

34 e.printStackTrace(); 35 System.out.println(“Error en dibujarLinea(): “ + e.getMessage()); 36 } 37 }

38 …. 39 public void dibujarPunto(Document doc, Element element, float x, float y, String idPunto, String

etiqueta, String idTexto){ 40 this.doc = doc;

41 Element elemento1 = null, elemento2 = null; 42 Document documento = doc.getDocument(); 43 Element root = (Element) documento.getDocument().getRootElement(); 44 String namespace = root.getNamespaceURI(); 45

46 try { 47 elemento1 = new Element(“circle”, namespace); 48 if(etiqueta != null && !etiqueta.equals(“”)) 49 elemento2 = new Element(“text”,namespace);

50 } 51 catch(Exception e){ 52 e.printStackTrace(); 52 System.out.println(“Error en dibujarPunto(): “ + e.getMessage());

54 } 55 56 elemento1.setAttribute(“cx”, x+””); 57 elemento1.setAttribute(“cy”, y+””);

58 elemento1.setAttribute(“r”, 2.0f+””); 59 elemento1.setAttribute(“fill-opacity”, 0.5f+””); 60 elemento1.setAttribute(“stroke-width”, 0.5f+””); 61 elemento1.setAttribute(“fill”, “red”);

62 elemento1.setAttribute(“stroke”, “black”); 63 element.addContent(elemento1); 64 65 if(etiqueta != null && !etiqueta.equals(“”)) {

66 elemento2.addContent(etiqueta); 67 elemento2.setAttribute(“x”, x+5+””); 68 elemento2.setAttribute(“y”, (y-2)+””); 69 elemento2.setAttribute(“font-size”, 5+””);

70 elemento2.setAttribute(“font-family”, “Verdana”); 71 elemento2.setAttribute(“fill”,”#0A2A0A”); 72 elemento2.setAttribute(“stroke-width”,”0.4”); 73 element.addContent(elemento2);

74 } 75 } 76 ….. 77 }

Figura 4-16 Métodos de elementos que se agregan al mapa SVGTiny

A su vez que los métodos dibujarPunto y dibujarLinea son llamados por el método

AgregarCapa. Dichos método se muestra en la Figura 4-17, en donde los elementos que

se agregan se localizan en las líneas 21 y 36.

1 public void agregarCapa(Document doc, String route, String pois, int numLayer, double distance){ 2 this.doc = doc; 3 Document documento = doc.getDocument(); 4 Element root = (Element) documento.getDocument().getRootElement();

5 String namespace = root.getNamespaceURI(); 6 cont = cont + 1;


Página 94

7

8 Element element = new Element(“g”,namespace); 9 element.setAttribute(“id”, “capa”+numLayer); 10 …. 11 puntosxy = obtenerPuntos(route);

12 …. 13 try { 14 if(puntosxy.size()%2 == 0) { 15 for(i=0; i<points-1; i++) {

16 … 17 x1 = Float.parseFloat(strX1); 18 y1 = Float.parseFloat(strY1); 19 x2 = Float.parseFloat(strX2); 20 y2 = Float.parseFloat(strY2);

21 dibujarLinea(doc, element, x1, y1, x2, y2); 22 } 23 } 24

25 puntitos.removeAllElements(); 26 interpretaTrama(pois); 27 int size = puntitos.size()/3; 28

29 String strEtiq, idPunto, idTexto; 30 31 indice1 = -1; 32 for(int j =0; j<size; j++) {

33 … 34 idPunto = “Punto” + contador; 35 idTexto = “Texto” + contador; 36 dibujarPunto(doc,element, x1, y1, idPunto, strEtiq, idTexto);

37 contador++; 38 } 39 root.addContent(element); 40 }

41 catch(Exception e){ 42 System.out.println(“Error en agregarCapa(): “ + e.getMessage()); 43 } 44 }

Figura 4-17 Métodos para agregar datos al mapa SVGT

4.5 Enviar mapa SVGTiny

El bloque que realiza esta función se muestra en la Figura 4-18, en donde el archivo SVG-

Tiny se encuentra en el objeto doc, utilizando el flujo de datos XMLOutputter de JDOM

para enviar el objeto doc al dispositivo móvil en respuesta de la petición vía HTTP

mediante el objeto out de PrintWriter.

1 try{

2 PrintWriter out; 3 Document doc = new Document(); 4 XMLOutputter outXML=new XMLOutputter(Format.getPrettyFormat()); 5 outXML.output(doc,out); 6 System.out.println(“Enviado con éxito!!!”);

7 }catch(Exception e){ 8 e.printStackTrace(); 9 }

Figura 4-18 Enviar el mapa SVGT al dispositivo móvil

CAPÍTULO V

PRUEBAS Y RESULTADOS En este capítulo se presentan los resultados de las pruebas realizadas al Generador de

mapas croquis en formato SVG-Tiny para dispositivos móviles.

Capítulo V Pruebas y resultados

Página 96

5. Pruebas y resultados El documento de plan de pruebas se denominó SBLAGWMMS y se encuentra en el anexo

A. El plan de pruebas se organizó en orden secuencial según las recomendaciones del

estándar IEEE 829-1998 [IEEE829, 2009].

El objetivo es desarrollar un generador de mapas tipo croquis en formato SVG-Tiny

identificando el perfil del dispositivo móvil, utilizando la pasarela Gateway SMS para

identificar el tipo de consulta que será procesado para dar respuesta mediante una

imagen en formato SVG-Tiny.

La descripción del identificador es:

SBL AGW MMS XX XX Identificador de caso de prueba Identificador del grupo de pruebas Mensaje Multimedia Gateway Servicios basados en localización

Las características que se probaron de la aplicación son:

Configuraciones y conexiones a las bases de datos: se probó la correcta

configuración y el acceso a las relaciones existentes, tanto en la base de datos

relacional como la base de datos espacial.

Recepción e interpretación de la información: se verificó que la trama recibida por

medio de peticiones HTTP fuera interpretada correctamente.

Generación del mapa: se probó la obtención del mapa SVG mediante peticiones

WMS al servidor de mapas, la ruta mediante el algoritmo de camino mínimos y los

puntos de referencia; siendo éstos dos últimos puntos agregados al mapa

SVGTiny.

Envío de la información: se probó el envío del mapa SVGTiny al dispositivo móvil,

dicho envío se realizó por medio de HTTP.

Las pruebas se realizaron teniendo como cliente la aplicación SketchMapv4U en el

emulador J2ME de Netbeans versión 6.8 y físicamente instalado en el dispositivo móvil

Nokia N97, la aplicación web SketchMapServer se instaló en el servidor de aplicaciones

Tomcat 6.0.

5.1 Realización de las pruebas

A continuación se muestran los resultados obtenidos en cada caso de prueba efectuado al

sistema.

Caso de prueba: SBLAGWMMS-01-01 Configuración y conexión con la base de datos relacional

Resultado: OK


Página 97

Figura 5-1 Parámetros de conexión para el MBDR PostgreSQL

Observaciones: La conexión se realizó de manera exitosa a la base de datos relacional, en la Figura 5-1 se muestran los datos de configuración para la conexión a la base de datos PostgreSQL.

Responsable de la prueba: Omar Ríos González Cargo: Autor

Caso de prueba: SBLAGWMMS-01-02 Configuración y conexión con la base de datos espacial

Resultado: OK

Figura 5-2 Parámetros de conexión de la extensión PostGIS SBLAGWMMS

Observaciones: La conexión se realizó de manera exitosa a la base de datos espacial, en la Figura 5-2 se muestran los datos de configuración para la conexión a la extensión PostGIS de la base de datos PostgreSQL.


Caso de prueba: SBLAGWMMS-02-01 Recepción e interpretación de mensajes

Resultado: OK

Figura 5-3 Interpretación del mensaje recibido

Observaciones: El mensaje es recibido por medio de la aplicación SketchMapServer vía HTTP, el software SBLAGWMMS espera una petición de mapa, para ello se interpreta el


Página 98

mensaje recibo. En la Figura 5-3 se muestra el mensaje interpretado.


Caso de prueba: SBLAGWMMS-03-01 Obtención del perfil del dispositivo

Resultado: OK

Figura 5-4 Perfil del dispositivo móvil

Observaciones: Se comprobó que el dispositivo móvil que realiza la petición cumple con las características necesarias para realizar peticiones y recibir las respuestas, se muestra el resultado en la Figura 5-4. El dispositivo móvil debe soportar el envío y recepción de mensajes SMS/MMS, soporte de MIDP 2.0 y CLDC 1.1.


Caso de prueba: SBLAGWMMS-03-02 Obtención del mapa imagen

Resultado: OK

URL http://192.168.0.10:8080/geoserver/wms? SERVICE WMS LAYERS 170070001m FORMAT image/svg+xml HEIGHT 320 TRANSPARENT FALSE REQUEST GetMap BBOX -99.2247,18.9046,-99.21929999999999,18.912000000000003 WIDTH 240 STYLES Polygon SRS EPSG:4326 VERSION 1.1.1

http://192.168.0.10:8080/geoserver/wms


Página 99

Figura 5-5 Proceso de obtención del mapa imagen en consola

Figura 5-6 Mapa obtenido

Observaciones: La obtención del mapa fue exitoso, es necesario generar la URL mediante los parámetros descritos en la Figura 5-5 para realizar la petición mediante WMS(Web Map Service) al servidor de mapas, en la Figura 5-6 se muestra el mapa obtenido.


Caso de prueba: SBLAGWMMS-03-03 Generación y obtención de la ruta destino

Resultado: OK

Figura 5-7 Representación de la ruta en nodos


Página 100

Figura 5-8 Visualización de la ruta mediante Netbeans

Observaciones: Se comprobó la obtención de la ruta, tomando como punto origen las coordenadas (18.9067,-99.2237) al destino de central de taxis, la obtención del punto de interés se presenta en el caso de prueba SBLAGWNNS03-04, en la Figura 5-7 se muestra el proceso de obtención de la ruta mostrada en la Figura 5-8.


Caso de prueba: SBLAGWMMS-03-04 Obtención de los POR (Point of Reference)

Resultado: OK

Figura 5-9 Obtención de los POR(Point of Reference - puntos de referencia)

Observaciones: Los nodos se obtienen correctamente de la ruta generada, obteniendo de la base de datos los puntos de referencia que cumplen con los criterios establecidos de una consulta espacial de tipo radial de no más de 10 metros. Estableciendo criterios de eliminación de información de duplicidad, obteniéndose con éxito los POR (Point of reference – Puntos de referencia) mostrados en la Figura 5-9.



Página 101

Caso de prueba: SBLAGWMMS-04-01 Crear y enviar el archivo SVGTiny que contiene el mapa croquis SVGTiny mediante HTTP

Resultado: OK

Figura 5-10Visualización del proceso de una petición del servicio de taxis.

Observaciones: El archivo SVGTiny es creado mediante los datos obtenidos (el mapa,

a b c

d e f

g


Página 102

la ruta y los puntos de referencia). La creación y el envío del archivo SVGTiny al dispositivo móvil se realizan correctamente. El proceso para la visualización del mapa en el dispositivo móvil se muestra en las Figuras 5-10(a-g), en donde las Figuras 5-10(a-c) se muestra la configuración del servicio, se observa en la Figura 5-10(d) las opciones de búsqueda del servicio, se muestra la pantalla de espera del resultado en la Figura 5-10(e), mostrándose finalmente el resultado en las Figuras 5-10(f, g). En el anexo C se muestran los resultados de las diferentes categorías.


5.2 Evaluación de los resultados

El software SBLAGWMMS cumple con los objetivos, el medio de comunicación es

mediante conexión HTTP, la funcionalidad se obtiene por la corrección de los siguientes

puntos:

[1]. El dispositivo móvil cliente realiza una petición de búsqueda a la aplicación web

SketchMapServer de algún punto de interés en un rango no mayor de 300mts y

delimitados por una lista de categorías.

[2]. La aplicación web SketchMapServer recibe e interpreta la trama enviada por el

dispositivo móvil y se realiza una petición al servidor de mapas en base a los datos

interpretados.

[3]. Se obtiene el mapa en formato SVG-Basic versión 1.0, mismo que es convertido a

SVG-Tiny versión 1.1 soportada para dispositivos móviles.

[4]. Se añaden los siguientes datos en capas al archivo SVG-Tiny:

a. Puntos de interés. Cada punto de interés indica una capa.

b. Ruta y sentido de dirección a seguir.

c. Puntos de referencia.

Tabla 5-1 Evaluación de resultados

Grupo Descripción Resultado Conclusión

SBLAGWMMS-01 Pruebas de configuración y conexión

Exitoso La conexión a la base de datos relacional y espacial se realizó de manera correcta.

SBLAGWMMS-02 Pruebas de recepción e interpretación de la información

Exitoso La recepción e interpretación de la información del mensaje son resueltas de manera correcta.

SBLAGWMMS-03 Pruebas de generación del mapa

Exitoso Las diferentes capas para generar el mapa se obtuvieron correctamente.

SBLAGWMMS-04 Pruebas de envío de la información

Exitoso El envío y recepción del archivo SVG-Tiny se realiza correctamente mediante conexiones HTTP.

CAPÍTULO VI

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

Página 104

6.1 Conclusiones

Las tecnologías de sistemas de información geográfica almacenan y despliegan

información que puede ser relacionada con lugares, es decir, información que tiene una

ubicación geográfica en conjunto con el GPS y Servicios Web son utilizados para la

localización de puntos de interés del usuario y los puntos de referencia que sirven de

guía para llegar al destino desde un origen específico, en este caso de las coordenadas

del dispositivo móvil.

Las bases de datos, los servidores de aplicación y los servidores de mapas son

esenciales en los sistemas de información geográfica. Los GIS en los dispositivos móviles

tienen restricciones, dichas restricciones limitan el tamaño de la pantalla que muestra el

contenido de mapas descritos por un conjunto de datos, el ancho de banda bajo para la

transmisión de datos que son utilizados para renderizar los mapas y el pobre poder

computacional para procesar los datos.

Es por ello que se considera una base de datos relacional que contiene las características

de la mayoría de los dispositivos móviles, teniendo mayor posibilidad para realizar

software ad-hoc al dispositivo móvil de acuerdo a su perfil.

El formato SVG-Tiny para la representación de imágenes en los dispositivos móviles ha

tomado un gran auge, por tal motivo es considerado en este proyecto, sin duda está

desplazando los formatos JPG, GIF y PNG entre los más utilizados. La utilización del

SVG-Tiny en los dispositivos móviles se lleva a cabo por la versatilidad de adaptarse a

diferentes tipos de representaciones visuales y el peso del archivo es mínimo, además de

ser capaz de soportar animaciones gráficas y de texto. Los servidores de mapas generan

archivos SVG en versiones 1.0, siendo una limitante la incompatibilidad de algunas

propiedades al ser manipuladas por el dispositivo móvil, por ello se realiza la conversión

desde la aplicación servidor, de igual forma las rutas se añaden al archivo mediante

capas, siendo la habilitación de las capas el único proceso que se realiza en el dispositivo

móvil con el archivo SVG-Tiny.

Los Sistemas Basados en Localización pueden ser representados en pantallas pequeñas

de los dispositivos móviles que soporten la configuración de Java CLDC 1.1 y el perfil

MIDP 2.0 mediante imágenes en formato SVG-Tiny por su versatilidad de uso,

compatibilidad con gran número de dispositivos móviles y la independencia de la

resolución con respecto a los gráficos sin degradarse al aumentar o disminuir el tamaño

de la imagen.

Los algoritmos de generación de ruta corta, óptima y con flujos bidireccionales son muy

utilizados por sistemas LBS, en esta tesis se consideró en esencia el algoritmo de Dijkstra

para obtener la ruta mínima que está en función del número total de nodos y el número de

respuestas requeridas, de igual forma los puntos de referencia son obtenidos en un radio

no mayor de 10 metros.

Por último, se pudo constatar que se pueden representar mapas con contenidos

geoespaciales para dispositivos móviles, gracias a las especificaciones de la OGC y W3C


Página 105

enfocados en las aplicaciones geoespaciales, permitiendo mediante estándares el acceso

a la información contenida en servidores o repositos locales y remotos, mismos que se

procesan en aplicaciones LBS, dicha información se integra textualmente representando

gráficos geoespaciales simples y complejos en una imagen SVG-Tiny, por ello este

proyecto puede ser enfocado en diferentes áreas, tales como la ubicación de algún

establecimiento, eventos en un áreas urbanas, ubicación de objetos o personas en un

plano arquitectónico de dos dimensiones.

6.2 Aportaciones

Se creó la aplicación web SketchMapServer que permite:

o Generar una ruta de un punto origen a un destino.

o Obtener los puntos de referencia localizados en la ruta generada.

o Convertir una imagen SVG-Basic(versión 1.0) recibido mediante WMS del

servidor de mapas a una imagen SVG-Tiny (versión 1.1)

o Añadir capas al mapa SVG-Tiny, las capas constan de la ruta y los puntos

de referencia. Para representar la ruta se añaden elementos de tipo línea y

los puntos de referencia se representan con elementos de tipo círculo y

texto.

Se desarrolló la aplicación SketchMapv4 para el dispositivo móvil con el perfil

MIDP 2.0 y configuración CLDC 1.1. Dicha aplicación realiza peticiones HTTP a la

aplicación web SketchMapServer para obtener un mapa de tipo croquis en formato

SVG-Tiny.

Esta aplicación fue probada en el dispositivo Nokia N97 y en el emulador default

Java Micro Edition SDK 3.0 de Netbeans 6.8.

6.3 Problemas encontrados

Durante esta investigación se presentaron problemas relacionados con el envío de

mensajes multimedia MMS desde el servidor de aplicaciones hacia el dispositivo

móvil, se probaron los siguientes métodos:

o En el dispositivo móvil se instaló una aplicación que permite recibir y gestionar

la información enviada por la computadora, la comunicación se realizó

mediante Sockets. Este método resultó insatisfactorio por la seguridad del

dispositivo móvil Nokia N97, teniendo que interactuar el desarrollador al

aceptar los avisos del dispositivo para que se realice la comunicación en un

lapso de tiempo que en algunas ocasiones se perdía la conexión.

o Se utilizó la librería MMS Java Library de Nokia para la creación de los

mensajes multimedia vía WAP en una aplicación de escritorio. El dispositivo

móvil se configuró para realizar comunicación vía WAP, sin embargo al intentar

enviar el mensaje multimedia los servidores de las telefónicas no dieron acceso

para realizar la comunicación al dispositivo móvil, se probaron en las

telefónicas Movistar y Telcel con los dispositivos móviles Nokia N97 y

Samsung D836.


Página 106

Se analizaron de comandos AT refiriéndose únicamente para envío de mensajes

SMS y no para mensajes MMS, por lo que se desistió enviar el resultado mediante

el envío de mensajes MMS optando por realizarse vía HTTP.

Otro de los problemas encontrados fue el no tener la red de calles de las ciudades

de México, ya que en un inicio no se podían realizar pruebas del algoritmo de ruta,

para solventar este problema se crearon manualmente dos archivos Shapefile

llamados street.shp y nodos.shp con la herramienta GIS TatukGIS. Una vez

teniendo la red de calles se realizaron pruebas de ruta, se obtuvieron diversos

grafos incompletos puesto que sólo se tenían los nodos de las intersecciones del

área de búsqueda, aunado a ello se obtuvieron resultados erróneos al no tener los

nodos finales de todas las calles, se resolvió infiriendo dichos nodos mediante un

proceso de análisis automático de las geometrías del área de búsqueda.

Con respecto a la compatibilidad del formato SVG que se obtiene del servidor de

mapas el cual es SVG-Basic se llevó a cabo una conversión de dicho formato al

SVG-Tiny, ya que existen algunas propiedades que no soporta el SVG-Tiny.

En un principio el proceso para enviar el resultado al dispositivo móvil vía HTTP

era muy tardado, se realizaron los siguientes procesos:

o Los datos se enviaban por bloques, es decir, se enviaba el mapa SVG-

Tiny, el punto de interés y los puntos de referencia por separado, teniendo

el dispositivo móvil un alto costo de procesamiento al momento de añadir

los datos recibidos a la imagen.

o La información de las rutas (puntos de interés, ruta y los puntos de

referencia) se añade en un archivo XML, primero se envía el mapa SVG,

después el archivo XML y al final se añaden las rutas a la imagen SVG en

el dispositivo móvil, teniendo un retraso al momento de presentar en

pantalla las localizaciones encontradas.

o Finalmente se realiza todo el procesamiento en el servidor de aplicaciones,

es decir, las rutas (líneas de calles y puntos de referencia) encontradas por

el algoritmo se agregan al mapa SVG-Tiny mediante capas, por lo que el

procesamiento de la información en el dispositivo móvil disminuye

considerablemente.

6.4 Trabajos futuros

La gran diferencia de procesamiento entre los dispositivos móviles y las computadoras de

última generación ha hecho que la investigación en el área de cómputo móvil aumente

considerablemente. Hoy en día la programación para los dispositivos móviles está

enfocada en consumir los servicios que brinda algún servidor de aplicaciones,

apoyándose de tecnologías tales como WiFi, GPRS, etc.

Durante el desarrollo de este trabajo de investigación se observaron varios aspectos para

complementar una mejor funcionalidad del lado servidor. Para ello se sugiere implementar

los siguientes módulos que apoyen al generador de mapas tipo croquis en formato SVG-

Tiny:


Página 107

1. Generación de la red de calles de una ciudad a partir del archivo de polígonos

representando las manzanas de dicha ciudad, el formato debe ser shape. Es decir,

crear una aplicación que tome de entrada un archivo shapefile de polígonos y

genere como resultado dos archivos shapefile, el primero que contenga elementos

de tipo punto y el otro de elementos poli líneas. Cabe destacar que se deben

utilizar metodologías para generar mapas axiales10.

2. En la estilización del mapa se considera crear una API que pueda manipular la

mayor parte de elementos que son descritos en las especificaciones del SVG en

versiones 1.1 y 1.2, esto por la falta o nula existencia de APIs libres para

manipular archivos SVG Tiny en los dispositivos móviles.

3. Relacionado con el punto anterior, se pueden añadir elementos gráficos que

representen los puntos de interés y referencia, declarando los gráficos como capas

mediante un grupo de elementos “g” que estén contenidos en las definiciones del

mapa “defs”, haciendo referencia a los id declarados. Un ejemplo se muestra en el

Anexo D.

4. Implementar un aplicativo que envíe mensajes MMS mediante un Módem

conectado al gateway SMS, mismo que servirá para responder peticiones de

mapas realizadas por medio de mensajes SMS. Se utilizaría la API MMS Library

de Nokia.

5. Se pueden crear Servicios Web que sean consumidos por diversos tipos de

aplicaciones, ya sea de aplicación de escritorio, Web e incluso mediante

comandos. Dichos servicios web pueden ser:

Obtener el mapa tipo croquis en formato SVG 1.1.

Obtener la ruta de un punto origen a uno destino, dicha ruta debe contener

sus puntos de referencia.

Ambos, es decir el mapa tipo croquis en formato SVG 1.1 y representado

mediante capas la ruta y los puntos de referencia.

6. En la actualidad existen varios modelos de dispositivos móviles que tienen la

característica de tener touchScreen, para ello se debe realizar un aplicativo cliente

en Java ME SDK 3.0 que pueda realizar las funciones para manipular dichas

pantallas, asimismo agregar las clases a la API SMSMMS.

7. Relacionado con el punto anterior, analizar a fondo las diferentes plataformas de

programación de dispositivos móviles y su compatibilidad con java, con la finalidad

de agregar a la API SMSMMS soporte para diversas plataformas permitiendo

heterogeneidad en las aplicaciones que se desarrollen, en su defecto generar

aplicaciones que puedan consumir servicios web o realicen peticiones HTTP.

10

Un mapa axial es aquel que contiene un conjunto de líneas que pasan cada espacio convexo para hacer los enlaces lineales. El termino de línea axial es definido como la línea más larga que puede ser dibujado en un punto arbitrario en el espacio, [Turner, 2003].


Página 108

6.5 Publicaciones

Se logró la publicación de un artículo en el VII Congreso Internacional sobre Innovación y

Desarrollo Tecnológico, celebrado en Cuernavaca, Morelos del 7 al 9 de octubre del 2009.

El artículo se denomina:

“Metodología para la obtención de Mapas tipo Croquis en formato SVG-Tiny identificando

perfiles de celulares”.

ANEXOS

ANEXO A Análisis para representar puntos

de interés Se presenta un análisis de las posibles combinaciones que se puedan realizar para

representar puntos de interés, dependiendo del dispositivo móvil y lo que desea el

usuario.

Anexo A. Análisis para representar puntos de interés

Página 111

Representaciones de puntos de interés Una de las características esenciales de un croquis son los puntos de referencia, es por

ello que se analizan las diferentes formas de representarlos en este trabajo, los cuales se

distinguen por la facilidad de entendimiento, haciendo uso de elementos básicos para los

usuarios como lo son: texto, símbolos e imagen

Texto

La representación de los puntos de interés mediante texto puede ser un tanto simple, el

cual no hay que menospreciar puesto que es parte fundamental en la muestra de

información en cualquier ámbito. En este caso, representa los puntos de interés que son

básicamente negocios que dan servicio al público, dando con ello reconocimiento de las

mismas, se puede observar un ejemplo en la figura A.1.

Figura A.1 Representando los Puntos de interés en texto sobre el Croquis

Símbolos

Esta representación es una de las más utilizadas en los mapas de navegación por la

interoperabilidad con el usuario, puesto que es más fácil la ubicación de puntos de interés

mediante simbología asimilada a la vida cotidiana como son: la representación de

restaurantes mediantes tenedores, cruz roja por una cruz, etc., haciendo de este tipo uno

de los más representativos y por mucho en gusto por los usuarios en comparación con la

representación en texto. Se puede apreciar en la siguiente figura su respectivo ejemplo.

Figura A.2 Representación en Símbolo los puntos de interés en el Croquis


Página 112

Imagen

Las representaciones de los puntos de interés hoy en día han dado un gran avance, al

encontrarse con las imágenes de los puntos de interés, eliminando la ambigüedad de la

ubicación de los mismos, haciendo de ello una opción demasiado útil facilitando la visión

del usuario.

Figura A.3 Representación en Imagen los puntos de interés en el Croquis

Representaciones de ruta La esencia de los puntos de interés no son de gran relevancia si no se cuenta con algún

elemento que complemente su conceptualización, es por ello que se presentan las rutas

como parte fundamental de los croquis, haciendo de ello un análisis de las

representaciones que se pueden tener como herramienta de ayuda al usuario en su

búsqueda del sitio de interés, entre ellos se encuentran los siguientes: texto, líneas,

flechas unidireccionales, árbol, audio y video.

Texto

Esta representación describe mediante un listado la ruta a seguir consecuentemente,

haciendo referencia de forma explícita la ubicación origen, los caminos a seguir asimismo

el destino como fin de la ruta.

Figura A.4 Representación de la ruta en texto


Página 113

Líneas

Una de las representaciones que contiene ambigüedad en el trazo de la ruta es

justamente el de líneas, ya que no presenta sentido de dirección del camino a seguir,

teniendo como apoyo los puntos de interés que se presentan en cualquiera de sus tipos.

Es una manera de representar la ruta, pero es sin duda un método que ha sido

reemplazado por las flechas unidireccionales.

Figura A.5 Representación de rutas en líneas

Flechas unidireccionales

Las flechas unidireccionales es la evolución de las líneas sin dirección, hoy en día es sin

duda una de las representaciones más utilizadas de una ruta, es mediante líneas de

dirección (flechas indicadoras), el cual sigue el mismo tópico que las líneas de partir

desde el punto origen hacia el destino.

Figura A.6 Representación de rutas con flechas unidireccionales


Página 114

Árbol

Esta representación suele ser un poco más compleja, para utilizarla es necesario

aprender cierta simbología para poder determinar la ruta a seguir, es posible decir que es

la versión aumentada de la representación de la ruta mediante texto, teniendo como

añadidura las simbologías.

A continuación se presentan los caracteres que son antepuestos a la descripción del

proceso de la ruta a seguir:

CARÁCTER DE DESCRIPCIÓN

DESCRIPCIÓN

C Comienzo de la ruta I Doblar a la izquierda D Doblar a la derecha T Término de la ruta

Tabla A.1 Descripción de los caracteres utilizados en el árbol

También se describen los símbolos que se utilizan para representar las direcciones de las

calles a seguir, así como la representación de los puntos de interés, véase

SÍMBOLO DESCRIPCIÓN

↑ Ruta recta | Tramo de ruta

Ruta a la izquierda

Ruta a la derecha

∆ Punto de interés

Tabla A.2 Descripción de los símbolos utilizados en el árbol

En la figura siguiente se muestra un ejemplo de lo que sería un árbol implementado en la

búsqueda del sitio de interés por el usuario, utilizando la simbología descrita con

anterioridad.

IZQ REC DER DESCRIPCION

↑ C UPV

| Sigue 200 metros

+ I Bancaixa

| Sigue 160 metros

∆ ↑ Boutique X

↑ ∆ Carrefour

+ D Burguer King

↑ ∆ T Estación de tren Xativa Figura A.7 Representación de rutas mediante un árbol

Hay dos variantes en la representación de rutas: audio y video, los cuales están

revolucionando hoy en día la navegación de mapas en diferentes enfoques, entre los que

se pueden notar, guías turísticas, GPS para automóviles, entre otros.


Página 115

Audio

El audio es uno de los servicios más comunes hoy en día, se presenta como una

alternativa para dar a conocer la ruta que se desea, es más funcional para los

conductores sin dejar de lado a los peatones. Es uno de los medios de comunicación más

efectivos que existe entre un dispositivo y el usuario, ya que mientras se esté realizando

alguna actividad con la vista, queda el sentido auditivo para saber la ubicación deseada.

Video

El sentido de la vista es indispensable para saber en dónde nos encontramos, es por ello

que el video toma parte importante en este trabajo, el video es un la herramienta más

eficaz y preciso que existe hoy en día, en la revelación del camino que se desea llegar,

mediante rutas representadas con algunos tipos descritos con anterioridad, y la

conjunción con el audio hacen de ello la herramienta perfecta para la ubicación de lugares

de interés del usuario.

Representaciones de entorno La representación del entorno debe ser clara, precisa y concisa puesto que es el elemento

primordial en la representación de los mapas. Imagínese mostrar las características de la

zona de alguna provincia, el suelo, vegetación, fauna, urbano, entre otros.

En este proyecto se busca la localización de puntos de interés de un usuario, el cual debe

de representarse en mapas tipo croquis con la ubicación deseada.

Mapas

Los mapas en su esencia son de diferentes tamaños y diversificados en sus diferentes

clasificaciones, esto dependiendo de la utilización del mismo. Los mapas que se utilizarán

son de tipo urbano, el cual debe contener: nombre de la calle, sentido de las calles como

características principales, para que sea manipulada esta información en el traslape con

otras capas que servirán para mostrar información pertinente en la ubicación de la ruta a

seguir así como los puntos de interés que se encuentren en el camino a seguir.

Figura A.8 Representación del entorno en mapa


Página 116

Mapas 3D

Este tipo de entornos está empezando a emerger, ya que no se puede implementar en

cualquier país puesto que todavía no existen, sin embargo se analiza teniendo

implementado como una opción más en la representación del entorno necesario para la

localización de sitios de interés.

Figura A.9 Representación del entorno en 3D

Obteniendo los posibles resultados Los resultados que se esperan van a tener ciertos parámetros de acuerdo a las

características propias del dispositivo móvil. Para ello, se necesita realizar un análisis del

perfil del dispositivo (características del dispositivo). A continuación se muestra como

interactuarán las capas descritas anteriormente como son:

Sitios de interés,

Rutas y

Entorno.

Y sus respectivas formas de representación, en la tabla A.3 se muestran cada uno de los

tipos de representación, en las primeras tres columnas se tienen las representaciones de

los puntos de interés, las dos últimas columnas la representación del entorno, asumiendo

que las filas son las representaciones de las rutas.

Tabla A.3 Tabla de resultados


Página 117

Análisis de los posibles resultados 1. Las rutas descritas en texto sólo pueden relacionarse con la representación de

puntos de interés en texto, puesto que se vuelve innecesario la utilización de

símbolos y/o fotos, siendo los dispositivos básicos los usuarios potenciales de este

resultado, sin descartar que los dispositivos también pueden obtener este

resultado si se desea.

2. La unión de las rutas en línea y la representación de los puntos de interés en

texto, pueden tener la unión en ambos entornos propuestos (mapas planos ó

mapas 3D).

3. La unión de las rutas en línea y la representación de los puntos de interés en

símbolos, pueden tener la unión en ambos entornos propuestos (mapas planos ó

mapas 3D).

4. La unión de las rutas en línea y la representación de los puntos de interés

mediante logos y/o fotos, pueden tener la unión en ambos entornos propuestos

(mapas planos ó mapas 3D).

5. La unión de las rutas en línea indicadoras (sentido de las calles) y la

representación de los puntos de interés en texto, pueden tener la unión en ambos

entornos propuestos (mapas planos ó mapas 3D).


representación de los puntos de interés mediante símbolos, pueden tener la

unión en ambos entornos propuestos (mapas planos ó mapas 3D).


representación de los puntos de interés mediante logos y/o fotos, pueden tener la

unión en ambos entornos propuestos (mapas planos ó mapas 3D).

8. La unión de las rutas mediante un árbol y la representación de los puntos de

interés en texto, pueden tener la unión en ambos entornos propuestos (mapas

planos ó mapas 3D).


interés mediante símbolos, pueden tener la unión en ambos entornos propuestos

(mapas planos ó mapas 3D).


interés mediante logos y/o fotos, pueden tener la unión en ambos entornos

propuestos (mapas planos ó mapas 3D).

11. La representación de rutas en audio hace necesario la utilización de alguno de los

resultados anteriores, puesto que es un adición al resultado haciendo uso el

sentido auditivo y no tanto de la vista, sin descarta ésta última.

12. La representación de las rutas mediante video al igual que el audio, necesita de

alguno de los resultados descritos anteriormente, siendo el servicio más avanzado

en la ayuda de la ubicación del sitio interés del usuario.


Página 118

Resultados extraordinarios Los resultados extraordinarios se presentan cuando el usuario desea saber los puntos de

interés de alguna forma más precisa, para ello los puntos de interés se traslapan,

obteniendo el resultado óptimo en la localización del sitio de interés del usuario.

Tabla A.4 Resultados extraordinarios

A continuación se describen los resultados extraordinarios que se pueden obtener:

1. Representar las rutas mediante líneas con los puntos de interés representados

mediante texto, símbolos, logo y/o foto, teniendo como entorno mapa plano tipo

croquis ó un mapa 3D.

2. Representar las rutas mediante líneas indicadoras (sentido de dirección de las

calles) con los puntos de interés representados mediante texto, símbolos, logo y/o

foto, teniendo como entorno mapa plano tipo croquis ó un mapa 3D.

3. Representar las rutas mediante árbol con los puntos de interés representados

mediante texto, símbolos, logo y/o foto, teniendo como entorno mapa plano tipo

croquis ó un mapa 3D.

4. Representar las rutas mediante audio con alguna de las representaciones

descritas en los tres puntos anteriores.

5. Representar las rutas mediante video con alguna de las representaciones

descritas en los tres puntos anteriores.

Nota: Se describen sólo los resultados óptimos, puesto que se puede tener solamente la

unión de algún tipo de representación de rutas, con dos representaciones de puntos

interés cualesquiera que éstos sean y alguna representación de entorno, ya sea un mapa

plano o bien un mapa en 3D.

ANEXO B Estudio de plataformas móviles

Se presenta un estudio de las diversas plataformas que interactúan con los dispositivos

móviles, mostrándose los sistemas operativos y las tecnologías de desarrollo.

Anexo B. Estudio de plataformas móviles

Página 120

1 Sistemas operativos paras dispositivos móviles En la actualidad muchos desarrolladores de software para dispositivos móviles se

enfrentan a un problema, ¿cuál es la tecnología móvil a utilizar? ¿Por qué?, son muchas

variantes en las que se cuestiona, es muy importante tener en cuenta tanto para las

tecnologías de desarrollo como la base en la que se implementarán (Sistemas Operativos

para dispositivos móviles), puesto que existe una co-dependencia fuerte entre ellos.

Se define sistema operativo como una capa de software que permite la comunicación

maquina-persona, también se le puede entender como un administrador de los recursos

(hardware) que nos ofrece la máquina para permitir un buen uso de ella por medio de los

programas o aplicaciones, [Wikiversidad, 2008].

Jorge L. Arienza define al sistema operativo como una capa compleja entre el hardware y

el usuario, concebible también como una máquina virtual, que facilita al usuario o al

programador las herramientas e interfaces adecuadas para realizar sus tareas

informáticas, abstrayéndole de los complicados procesos necesarios para llevarlas a

cabo, [Arienza, 2008].

Los dispositivos móviles se distinguen por sus características, dependiendo de la empresa

que las elabora, el modelo serializado, sistema operativo y la tecnología de desarrollo de

las aplicaciones con las que realiza las funciones que contienen.

Los desarrolladores tienen una visión de los diversos software que conforman el marco

de trabajo de un sistema operativo del dispositivo móvil. En la Figura B.1 se muestran las

capas con las que cuenta un dispositivo móvil, posteriormente se describirá cada una de

las capas.

Figura B.1 Capas de los dispositivos móviles.


Página 121

Kernel. Es el núcleo que proporciona el soporte necesario para acceder a los diversos

elementos del hardware. Los principales servicios ofrecidos por el kernel a las capas

superiores de la pila de software son los siguientes:

Drivers para el hardware. Acceso y administración de la memoria. Sistema de archives. Administración de procesos.

Middleware. Es un conjunto de módulos de software que hacen posible la existencia de

las aplicaciones para móviles. Esta librería de software es totalmente transparente para el

usuario final, ofrece servicios claves para las aplicaciones como:

Motor de mensajería. Interpretes de páginas web/ WAP. Motor de comunicaciones. Códec multimedia. Administración de dispositivos. Seguridad.

Entorno de Ejecución de Aplicaciones. Consiste de un gestor de aplicaciones y un

conjunto de interfaces programables (APIs) abiertas y accesibles por los programadores

para facilitar la creación de aplicaciones.

Interfaz de Usuario. Facilita la creación de las interfaces de usuario de las aplicaciones

que facilitarán la administración de la interacción con el usuario final y el diseño de la

presentación visual de la aplicación. Los principales servicios que esta capa ofrece a las

aplicaciones son:

Componente gráficos y el marco de interacción.

Descrito lo anterior es necesario tomar en cuenta la base sobre la que se instalarán las

aplicaciones, a continuación se presentan los sistemas operativos más utilizados en la

actualidad como son: Symbian, Windows Mobile, Linux.

1.1 Symbian Es un sistema operativo diseñado específicamente para dispositivos móviles que

funcionan en un espacio pequeño con escasos recursos de memoria y administra de

manera eficiente la energía.

En la siguiente figura se muestran las empresas que hicieron posible el surgimiento de

Symbian para sus dispositivos móviles con capacidad de procesamiento de datos.


Página 122

Figura B.2 Empresas de telefonía móvil

Symbian proporciona rutinas y servicios subyacentes para las aplicaciones. Técnicamente

es una colección compacta de código ejecutable y varios archivos, la mayoría de ellos

bibliotecas DDL. Por norma general, el sistema operativo se encuentra cargado en la

memoria flash del teléfono móvil, de esta forma se puede conservar el sistema operativo

cuando el dispositivo móvil no tenga batería. Además contempla 4 interfaces de usuario

para el sistema operativo: Serie 60, serie 80, serie 90 y UIQ, los dispositivos Nokia

disponen de las Series 60, 80 y 90, la interfaz UIQ es utilizada por Sony Ericsson y

Motorola.

Con respecto al desarrollo de aplicaciones es muy flexible, se puede programar en

lenguajes de programación como C++, Java, VB, Python, Perl, Flash Lite, etc. [Symbian,

2008]

Las aplicaciones que se pueden realizar están enfocadas en su mayoría por juegos,

reproductores de video, traductores, administradores, navegadores web, sistemas

basados en localización, entre etc.

1.2 Windows Mobile 6 Windows Mobile es un sistema operativo compacto, con una suite de aplicaciones

básicas para los dispositivos móviles basados en la API win32 de Microsoft. Los

dispositivos que cuentan con éste sistema operativo son:

Windows Mobile 6 standard para Smartphones (teléfonos sin pantalla táctil),

Windows mobile 6 professional para PDAs con la funcionalidad del teléfono

(Pocket PC Phone Edition) y

Windows mobile 6 classic para PDAs sin telefonía.

El sistema operativo está basado en Windows CE 5.2, soporta resoluciones de 800x480 y

320x320 pixeles, soporta VoIP, Bluetooth, asimismo soporta AJAX, JavaScript y


Página 123

XMLDOM, Generic Access Network (UMA) para algunos países, .Net Framework v2, SQL

Server Compact Edition, formatos Office 2007.

Mantiene mejoras en función de seguridad, en la cual existe una función de borrado

remoto por robo o pérdida del equipo, incluyendo encriptación en los datos y en las

tarjetas de memoria, [MWM, 2008].

En el desarrollo de las aplicaciones se realiza mediante los lenguajes de programación

visuales C++, C# y Basic .Net respectivamente. Se pueden tomar y manipular las

variables de las características de los dispositivos móviles, tales como los gráficos, GPS,

contactos, mensajes, audio, seguridad, entre otras. También se pueden establecer

conexiones de red mediante núcleo (TCP/IP, Socket, IPV6, etc.), remoto (RAPI, VoIP) o

wireless (Bluetooth, Infrared, WiFi). Se cuenta con emuladores de dispositivos, diferentes

aplicaciones, depuración entre otras características no menos importantes.

Se espera la llegado del Windows Mobile 7 en el 2009, la nueva versión del sistema

operativo para móviles incluirá soporte para pantallas multitáctiles, una tienda de

aplicaciones centralizada e interfaces gráficos más cuidados e intuitivos. Al igual que

Google, Microsoft licenciará el sistema operativo para todo tipo de teléfonos y en todo tipo

de formatos. Los habrá con pantalla grande y panorámica, con teclado Qwerty, en formato

barra y concha, [Mundo, 2009].

1.3 Mobile Linux La estrategia está basada en software abierto, haciendo que el usuario tenga una gran

experiencia en este tipo de plataformas. Por lo que se busca explorar al máximo los

dispositivos móviles y los servicios que aceleran el uso de los dispositivos móviles para

el uso de llamadas o envíos de mensajes, sistemas basados en localización, utilización

de internet, entre otras características. Entre los más representativos se presentan

algunos sistemas operativos lanzados al mercado de los dispositivos móviles.

1.4 MOTOMAGX Es un sistema operativo desarrollado por Motorola, incorporando tecnologías abiertas

para encontrar nuevos niveles de flexibilidad y soporte de las aplicaciones que se

encuentren sobre dispositivos móviles de Motorola. Soporta aplicaciones desarrolladas

en J2ME, con planes para introducir ambientes de desarrollo en aplicaciones de WebUI

y Linux.

Contiene más de 200 características con una arquitectura basada en una plataforma

abierta y modular, apoya a las aplicaciones propias y de terceros. Contiene una

innovadora interfaz de usuario con tecnología que permite utilizar un lápiz o dedos para

realizar la navegabilidad sobre el entorno.

1.5 MAEMO Es un sistema operativo para dispositivos Tablet Internet Nokia, originalmente se llamó

Internet tablet OS. Es similar a los sistemas operativos de la competencia, puesto que

tiene en pantalla el inicio como punto central que a partir del cual se pueden acceder a

todas las aplicaciones y configuraciones.


Página 124

Maemo se basa en Debian GNU/Linux y gran parte de la interfaz gráfica, marcos de

trabajo y librerías del proyecto GNOME. Es una plataforma de software que está

basado en código abierto para dispositivos móviles, tales como el Internet tablet Nokia

N810. Esta plataforma ha sido desarrollada por Nokia en colaboración con diversos

proyectos libres, tales como el Kernel de Linux, Debian, GNOME entre otros, ver figura

B.3.

Figura B.3 Proyectos en colaboración con Nokia

Características

Actualización. Los dispositivos memos pueden actualizarse usando un método de

parpadeo simple con una computadora usando USB.

Seguridad. La seguridad se centra en prevenir ataques remotos (red inalámbrica y

Bluetooth). En particular se advierte que se hace uso de una cuenta root,

independientemente de la contraseña de root, provee una forma para bloquear el control

del dispositivo y la pantalla con un código numérico de acceso, lo anterior se realiza para

prevenir el acceso ocasional.

Software. Algunas de las aplicaciones software que contiene son los reproductores

multimedia, office. VoIP, juegos, lector de libros, RDP de acceso remoto, navegación

GPS, visor de tv, sms y llamadas de voz a través de bluetooth, entre otros.

1.6 ANDROID Android es una plataforma de software y sistema operativo para dispositivos móviles,

basados en el Kernel de Linux, desarrollado por Google y después en conjunto con

Open Handset Alliance. Permite a los desarrolladores escribir código que se ejecuta

bajo la gestión de una maquina virtual en el lenguaje Java, controlando el dispositivo

mediante librerías de java desarrollados por Google.

Características

La plataforma se adapta al tipo de pantalla VGA, librerías gráficas 2D y 3D basadas en

especificaciones OpenGL ES 1.0.


Página 125

En lo referente al almacenamiento de datos usa el SQLite, soporta tecnologías de

conectividad tales como: GSM/EDGE, CDMA, EV-DO, UMTS, Bluetooth y WiFi.

Asimismo soporta las formas de envío de mensajes SMS y MMS.

Utiliza la máquina virtual Dalvik que está diseñado para el uso de dispositivos móviles.

Soporta MPEG-4, H.264, MP3, JPEG, PNG, entre otros. Tiene la capacidad de utilizar

cámaras, pantallas táctiles, GPS, acelerómetros y gráficos de aceleración 3D. La figura

B.4 muestra el aspecto del Sistema operativo Android.

Figura B.4 Aspecto del SO Android

2 Tecnologías móviles 2.1 J2ME

Plataforma Java, Micro Edition (Java ME) es una colección de tecnologías y

especificaciones para crear una plataforma que se ajuste a los requisitos para

dispositivos móviles, tales como productos de consumo, dispositivos embebidos, y los

dispositivos móviles avanzados. Es una colección de tecnologías y especificaciones

que pueden ser combinados para crear un completo entorno de ejecución de Java

específicamente para adaptarse a las necesidades de un dispositivo o de mercado.

Entre los componentes principales del J2ME se encuentran los siguientes:

Connected Device Configurations

Connected Limited Device Configurations

Mobile Information Device Profiles

Las tecnologías J2ME contienen un JRE altamente optimizado, especialmente

desarrollado para el mercado de gran consumo. Permite ejecutar programas se

seguridad, conectividad y utilidades en utilidades en tarjetas inteligentes, LBS,

sintonizadores de TV y otros pequeños electrodomésticos.

Configuraciones del J2ME

La configuración de recursos dirigidos a los dispositivos de limitación-como los teléfonos móviles se denomina Conexión Limitada de configuración de dispositivos (CLDC). Está específicamente diseñado para satisfacer las necesidades de una plataforma Java para correr en dispositivos con capacidad de memoria limitada, potencia de procesamiento y


Página 126

capacidades gráficas. Adapta ampliamente la combinación del CLDC con el Mobile Information Perfil de Dispositivo (MIDP) para proporcionar un completo entorno de aplicaciones Java para teléfonos móviles y otros dispositivos con capacidades similares.

Con la configuración y los perfiles de la aplicación difiere del API disponible en el perfil. El entorno de CLDC y MIDP suele ser lo que la mayoría de los dispositivos móviles de hoy se llevan a cabo mediante un MIDlet.

Figura B.5 Configuraciones J2ME

En la actualidad, J2ME define dos configuraciones:

1. Connected Limited Device Configuration (CLDC). Una plataforma típica CLDC es un

teléfono celular o PDA (Personal Digital Assistant) con aproximadamente 512 KB de

memoria disponible. Por esta razón, CLDC se encuentra estrechamente asociada con

Java inalámbrico, el cual se ocupa de permitir a los usuarios de los teléfonos móviles

comprar y descargar aplicaciones Java pequeñas (MIDlets) para sus dispositivos. Un

creciente número de fabricantes de teléfonos celulares han firmado acuerdos con Sun

Microsystems para utilizar esta tecnología, de manera que la cantidad de dispositivos

con la capacidad de programarse en Java sigue aumentando.

2. Connected Device Configuration (CDC). CDC dirige las necesidades de los

dispositivos que se encuentran entre CLDC y la plataforma para escritorio J2SE. Estos

dispositivos tienen más memoria (2MB o mayor) y procesadores más capaces y por lo

tanto soportan un ambiente de software Java más completo. CDC se puede encontrar

en PDAs de última generación y en smartphones, teléfonos con acceso a la Web,

gateways (pasarelas) residenciales y cajas set-top.

Perfiles

Un perfil complementa una configuración agregando clases adicionales que proporcionan

características apropiadas para un tipo particular de dispositivo o para un segmento del

mercado específico. Las configuraciones J2ME tienen asociados uno o más perfiles.

Mobile Information Device Profile (MIDP). Este perfil agrega conexión a redes,

componentes de interfaz de usuario y almacenamiento local en CLDC. Se dirige


Página 127

principalmente a las pantallas y almacenamiento limitados de los dispositivos móviles

y por lo tanto proporciona una interfaz de usuario relativamente simple y conexión

básica a redes basadas en HTTP 1.1.

PDA Profile (PDAP). Este perfil es similar a MIDP, pero se dirige a PDAs que tienen

mejores pantallas y más memoria que los teléfonos celulares.

Foundation Profile. Este perfil define un conjunto de APIs para CDC orientadas a

dispositivos que carecen de interfaz gráfica como por ejemplo decodificadores de

televisión digital. Incluye gran parte de los paquetes de J2SE.

Personal Basis and Personal Profiles. Este perfil agrega funcionalidades básicas a la

interfaz de usuario del perfil Foundation. Su objetivo es el de proporcionar a la

configuración CDC una interfaz gráfica completa, con capacidades Web y soporte de

applets de Java.

RMI Profile. Este perfil proporciona librerías de invocación remota de métodos al perfil

Foundation.

Game Profile. Proporciona una plataforma para escribir software de juegos en

dispositivos CDC.

La figura B.6 muestra una visión general de los componentes de la tecnología Java ME y

cómo se relacionan con las otras tecnologías Java.

Figura B.6 Componentes de la tecnología Java ME.

2.2 ANDROID Android es una plataforma de programación de software para dispositivos móviles que

incluye un sistema operativo, middleware y aplicaciones clave. Google tiene el SDK de


Página 128

Android, que provee de herramientas y APIs necesarios para comenzar a desarrollar

aplicaciones en la plataforma Android, utilizando el lenguaje de programación Java.

Android contiene un núcleo Linux que incluye muchos de los drivers para teléfonos

móviles, no diferencia entre las aplicaciones desarrolladas y las básicas del teléfono,

permite acceder a las funciones principales de los dispositivos móviles mediante

llamadas a API estándar, asimismo combina la información de internet con datos del

teléfono, como contactos o ubicaciones geográficas, también su SDK ejecuta

aplicaciones Android como un emulador de dispositivos y herramientas avanzadas de

depuración. Esta plataforma provee de varios frameworks y en la actualidad está muy

enfocada a trabajar con servicios web.

Características

Las características con las que cuanta el SDK android son las siguientes:

Framework de aplicaciones que permite el rehúso y reemplazo de componentes.

Máquina virtual Dalvik optimizada para dispositivos móviles para requerir poca

memoria y está diseñada para permitir ejecutar varias instancias de la máquina

virtual simultáneamente.

Navegador integrado basado en el motor open source Web Kit, el cual es un

framework para aplicaciones que funciona como base para el navegador web

Safari y Google Chrome, que facilita la inclusión de gran parte de las

funcionalidades de Safari en las aplicaciones.

Gráficos optimizados, con una librería de gráficos 2D; gráficos 3D basado en la

especificación OpenGL ES 1.0 (aceleración de hardware).

SQLite para almacenamiento de datos estructurados.

Soporte para medios con formatos comunes de audio, video e imágenes planas

(MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)

Telefonía GSM (dependiente del hardware)

Bluetooth, EDGE, 3G, y WiFi (dependiente del hardware)

Cámara, GPS, brújula, y acelerómetro (dependiente del hardware)

Ambiente rico de desarrollo incluyendo un emulador de dispositivo, herramientas

para depurar, perfiles de memoria y rendimiento, y un plugin para el IDE Eclipse.

Touch screen

Cualquier aplicación sobre el dispositivo móvil puede ser reemplazado o

extendido.

Las aplicaciones pueden añadirse a la web fácilmente mediante HTML, Javascript

y hojas de estilo.

Pueden tenerse aplicaciones corriendo en paralelo, mientras corren detrás, otra

aplicación puede notificar producir notificaciones.


Página 129

Arquitectura de Android

Figura B.7 Arquitectura de Android

A continuación se describe de forma breve cada componente de la arquitectura del

Android mostrada en la figura B.7.

Aplicaciones Las aplicaciones base incluye un cliente de email, programa de SMS, calendario, mapas, navegador, contactos, y otros. Todas las aplicaciones escritas en el lenguaje de programación Java.

Framework de aplicaciones Los desarrolladores tienen acceso completo a los mismos APIs del framework usados por las aplicaciones base. La arquitectura está diseñada para simplificar el reuso de componentes; cualquier aplicación puede publicar sus capacidades y cualquier otra aplicación puede luego hacer uso de esas capacidades (sujeto a reglas de seguridad del framework). Éste mismo mecanismo permite que los componentes sean reemplazados por el usuario.

Librerías Android incluye un conjunto de librerías C/C++ usadas por varios componentes del sistema Android. Estas capacidades se exponen a los desarrolladores a través del framework de aplicaciones de Android. Algunas son: System C library (implementación librería C standard), librerías de medios, librerías de gráficos, 3d, SQLite, entre otras.


Página 130

Runtime de Android Android incluye un ser de librerías base que proveen la mayor parte de las funcionalidades disponibles en las librerías base del lenguaje de programación Java. Cada aplicación Android corre su propio proceso, con su propia instancia de la máquina virtual Dalvik. Dalkiv ha sido escrito de forma que un dispositivo puede correr múltiples máquinas virtuales de forma eficiente. Dalkiv ejecuta archivos en el formato Dalvik Executable (.dex), el cual está optimizado para memoria mínima. La Máquina Virtual está basada en registros, y corre clases compiladas por el compilador de Java que han sido transformadas al formato .dex por la herramienta incluida “dx”.

Kernel Linux Android depende de un Linux versión 2.6 para los servicios base del sistema como seguridad, gestión de memoria, gestión de procesos, stack de red, y modelo de drivers. El kernel también actúa como una capa de abstracción entre el hardware y el resto del stack de software.

2.3 WINDOWS MOBILE Es un sistema operativo compacto, con una suite de aplicaciones básicas para

dispositivos móviles basados en la API Win32 de Microsoft. Los dispositivos que llevan

Windows Mobile son Pocket PC‟s, Smartphones y Media Center portátil. Ha sido

diseñado para ser similar a las versiones de escritorio de Windows. Se cuenta con tres

versiones:

Windows mobile Standard para Smartphones,

Windows mobile Professional para PDA‟s con la funcionalidad del teléfono y

Windows mobile Classic para PDA‟s sin telefonía IP.

Windows CE está ligado fuertemente a Windows Vista, Windows Live, Microsoft Orrice y

Exchange 2007. Las especificaciones que soporta entre otras son las siguientes:

Basado en Windows CE 5.0 (versión 5.2) Soporta las resoluciones 800x480 y 320x320. Acceso de escritorio remoto mejorado Desarrollo y distribución de aplicaciones más rápido y más fácil. Soporte VoIP con los codec del audio AEC (Acoustic Echo Cancelling) y MSRT La pila Bluetooth de Microsoft ha mejorado notablemente. Cifrado de la tarjeta de almacenamiento - Windows Mobile 6 para Pocket PC y

Smartphone soportan el cifrado de los datos almacenados en tarjetas externas de almacenamiento.

Smartfilter para buscar más rápidamente emails, contactos, canciones, archivos, etc.

Soporte AJAX, JavaScript y XMLDOM en Internet Explorer Mobile. Soporte Generic Access Network (UMA) para los operadores seleccionados

(como BT en el Reino Unido). Server Search para buscar en toda la bandeja de entrada de Exchange. SQL Server Compact Edition en la ROM.

ANEXO C Plan de pruebas

Plan de pruebas de la aplicación SBLAGWMMS

Anexo C. Plan de pruebas

Página 132

1 Identificador del plan de pruebas SBL AGW MMS XX XX Identificador de caso de prueba Identificador del grupo de pruebas Mensaje Multimedia Gateway Servicios basados en localización

1.1 Introducción Este documento define el plan de pruebas que permite la verificación del sistema

SBLAGWMMS (Servicios Basados en Localización a Gateway MMS).

El software desarrollado consta de la integración de diversas tecnologías tales como:

transferencia de información vía HTTP, tecnología de posicionamiento a través de GPS

(Global Positioning System, Sistema de Posicionamiento Global) [Gps, 2009],

peticiones a servidor de mapas Geoserver y el uso de base de datos espaciales.

El documento se encuentra organizado en orden secuencial según las

recomendaciones del estándar IEEE 829-1998 [IEEE829, 2009] y se definen los

apartados de la siguiente manera:

1.3 Descripción del plan de pruebas: en este apartado se indica lo que se va a probar, los elementos necesarios para las pruebas así como la planificación y resolución de posibles incidencias.

1.4 Casos de pruebas: en este apartado se muestran los distintos grupos de pruebas que se van a realizar.

1.5 Procedimiento de pruebas: se describe cada uno de los grupos de prueba y casos de prueba que se han establecido.

1.6 Informe de pruebas: en este punto se recogen los resultados de las pruebas realizadas, observaciones y comentarios que surjan en el desarrollo de la prueba.

1.2 Objetivo Desarrollar un generador de mapas tipo croquis en formato SVG-Tiny identificando el

perfil del dispositivo móvil, utilizando la pasarela Gateway SMS para identificar el tipo

de consulta que será procesado mediante un mensaje SMS.

1.3 Descripción del plan de pruebas 1.3.1 Características a probar

El siguiente plan de pruebas consiste en la descripción de los casos de uso

definidos con el fin de validar y verificar que el software SBLAGWMMS cumple con

los objetivos propuestos para el desarrollo de la tesis sobre aplicaciones de

servicios basados en localización utilizando el servicio de mensajería corta y

multimedia.

1.3.2 Características excluidas de las pruebas Los casos de prueba contemplados y desarrollados para este plan no cubre y por

tanto no incluyen los siguientes aspectos:

Pruebas de estrés o concurrencia.


Página 133

1.3.3 Enfoque El tipo de pruebas y mediciones que se realizan al software SBLAGWMMS son

principalmente factibilidad y funcionabilidad. Las peticiones y respuestas que se

procesan son enfocadas a la tecnología de servicios basados en localización sobre

mensajería SMS y MMS.

Las peticiones provienen de un dispositivo móvil, interactuando con la aplicación

cliente del proyecto que utiliza la API SMS/MMS para el desarrollo de la aplicación

SBL, como envío un mensaje corto y en respuesta un archivo multimedia.

1.3.4 Criterio de éxito y fracaso del caso de prueba La decisión de éxito o fracaso de cada uno de los caso de prueba contenidos en el

análisis y diseño de la aplicación, será basada en la comparación de los resultados

esperados contra los resultados obtenidos.

Los resultados esperados están basados en mediciones tomadas mediante un

software específico para obtener las distancias lineales entre puntos con

coordenadas geográficas específicas.

Se considera que una prueba ha tenido éxito cuando los resultados obtenidos

coincidan con los resultados descritos para cada uno de los casos de prueba.

En caso que los resultados obtenidos y descritos no coincidan, se evaluarán las

posibles causas y se realizarán las modificaciones necesarias para que el caso de

prueba cumpla con éxito la especificación de los resultados descritos.

1.3.5 Criterio de suspensión y requerimientos de reanudación El criterio de pruebas no se suspenderá completamente en ningún momento,

solamente se detendrá el tiempo que defina la persona encargada de las pruebas

en caso de que surja algún error para evaluar y corregir éste en el menos tiempo

posible, haciendo iterativo este proceso hasta que cumpla con los requerimientos

del caso de prueba y no se presente ninguna dificultad con el mismo.

El requerimiento principal para la reanudación del proceso de pruebas es haber

cumplido satisfactoriamente con los requerimientos descritos para el caso de prueba

en curso.

1.3.6 Tareas de las pruebas Las tareas necesarias para preparar, diseñar y aplicar el plan de pruebas se

mencionan en la tabla siguiente:

Tabla C.1 Tareas descritas para las pruebas

No. Tarea Tarea precedente

Habilidades especiales Responsabilidad

1 Preparación del plan de pruebas

Análisis de sistemas de información geográfica

Visión general del estándar IEEE 829-1998

Autor de la tesis

2 Preparación del diseño de pruebas

Tarea 1 Conocimiento de la forma de operación del sistema desarrollado así como de

Autor de la tesis


Página 134

los módulos que lo conforman

3 Preparación de los casos de prueba

Tarea 2 Conocimiento profundo de las características del software desarrollado

Autor de la tesis

4 Aplicación de las pruebas

Tarea 3 Conocimiento del ambiente de desarrollo.

Autor de la tesis

5 Resolver los incidentes de pruebas

Tarea 4 Conocimientos del lenguaje de programación java. Conocimiento del ambiente de desarrollo integrado. Conocimientos de bases de datos relacionales y espaciales Conocimiento de APIs de mensajería SMS/MMS

Autor de la tesis

6 Evaluación de los resultados

Tarea 4 Tarea 5

Conocimiento de las preguntas de investigación estipuladas para la tesis

Autor de la tesis

1.3.7 Liberación de las pruebas El caso de éxito de las pruebas y su posterior liberación se basan en la coincidencia

de dos aspectos: los resultados esperados contra los resultados obtenidos, en este

punto dichos resultados se consideran satisfactorios para alcanzar el objetivo

planteado para el desarrollo de este proyecto y en consecuencia la liberación de las

pruebas.

1.3.8 Requerimientos ambientales A continuación se especifican las herramientas de hardware y software necesarios

para el desarrollo del plan de pruebas.

Tabla C.2 Requisitos ambientales de hardware

Hardware Características mínimas

PC de escritorio ó Laptop Procesador Pentium 4 2.0 GHz 256 MB RAM 80 GB en disco duro Puerto USB o Serial Sistema Operativo XP Tarjeta de red Ethernet o Wireless

Módem GSM

Dispositivo móvil Symbian OS 7.0s ó superior Bluetooth Tecnología Java: CLDC 1.1, MIDP 2.0


Página 135

Tabla C.3 Requisitos ambientales de software

Software Descripción

J2SE versión 1.5 ó posterior Lenguaje de programación

IDE Netbeans 6.5.x ó posterior Entorno de desarrollo de la aplicación

API Java Comunicaciones API para la comunicación serial a través de Java.

API SMS/MMS API para el desarrollo de aplicaciones LBS

DBMS PostgreSQL 8.3.x ó posterior

Sistema manejador de base de datos

PostGIS 1.3.x ó posterior Extensión espacial para el manejador de base de datos PostgreSQL

Conector JDBC Postgres API para la conexión a la base de datos a través de Java

Apache Tomcat Servidor de aplicaciones

Geoserver Servidor de mapas

Geotools Librerías para acceder al servidor de mapas por medio de los estándares WMS, WFS.

1.3.9 Responsabilidades Toda la responsabilidad de las pruebas recae totalmente en el autor de la tesis.

1.3.10 Riesgos y contingencias La falta de tiempo es un factor prescindible para ser considerado a la hora de aplicar

las pruebas y se localice un error, siendo el tiempo que se pueda llevar para

corregirlo. Por consiguiente se comprometen N pruebas que validen la funcionalidad

del software.

Con respecto a las contingencias que se puedan o no presentar durante el

desarrollo de las pruebas, éstas se deben de evaluar y corregir a fin de continuar

con el proceso. Las modificaciones se deben realizar de forma iterativa con el fin de

cumplir los objetivos planteados en cada caso de prueba y los objetivos de la tesis.

1.4 Casos de pruebas 1.4.1 Características a probar

En la tabla se muestran los distintos casos de prueba definen las características a

ser probadas.

Tabla C.4 Características del plan de pruebas

Característica Descripción

Configuraciones y conexiones Define los casos de prueba para verificar la correcta configuración de los parámetros a utilizar por para la conexión a la base de datos y el servidor de mapas.

Recepción e interpretación de la información

Define la información recibida para la interpretación de la información proveniente del dispositivo móvil..

Generación del mapa Define los casos de prueba para la obtención del mapa.


Página 136

Generación de la ruta Define la obtención de la generación de ruta.

Generación de los POR Define la generación y obtención de los puntos de referencia

Envío de la información Define la información enviada.

1.4.2 Realización de pruebas La realización de las pruebas está compuesta por 4 grupos de pruebas, las cuales

se describen en las tablas C.5 al C.8 mostradas a continuación.

Tabla C.5 Grupo de pruebas SBLAGWMMS-01

Configuraciones y conexiones

PRUEBA DESCRIPCIÓN

SBLAGWMMS-01-01 Configuración y conexión con la base de datos relacional

SBLAGWMMS-01-02 Configuración y conexión con la base de datos espacial


Pruebas SBLAGWMMS-02 Recepción e interpretación de la información

PRUEBA DESCRIPCIÓN

SBLAGWMMS-02-01 Recepción e interpretación de mensajes


Pruebas SBLAGWMMS-03 Generación del mapa

PRUEBA DESCRIPCIÓN

SBLAGWMMS-03-01 Obtención del perfil del dispositivo

SBLAGWMMS-03-02 Obtención del mapa imagen

SBLAGWMMS-03-03 Generación y obtención de la ruta destino

SBLAGWMMS-03-04 Obtención de los POR (Point of Reference)


Pruebas SBLAGWMMS-04 Envío de la información

PRUEBA DESCRIPCIÓN

SBLAGWMMS-04-01 Enviar el archivo SVG-Tiny que contiene el mapa croquis mediante HTTP

1.5 Procedimientos de pruebas

Se describen los correspondientes procedimientos de los casos de prueba que

conforman el software SBLAGWMMS. La organización de los casos de prueba se basa

en cada uno de los grupos definidos. Se tiene como objetivo validar y verificar una


Página 137

funcionalidad específica. Cada grupo describe el propósito, entorno y conjuntos de

pruebas que lo conforman.los casos de prueba describen el propósito, entorno,

procedimiento y los resultados esperados.

1.5.1 SBLAGWMMS-01 Configuraciones y conexiones

1.5.1.1Propósito

Verificar que las clases realizadas para la conexión con el manejador de bases de

datos PostgreSQL y la extensión PostGIS funcionen correctamente.

1.5.1.2 Entorno de prueba

Para los casos de prueba contenidos en este grupo se utilizan los siguientes

elementos:

IDE Netbeans 6.8, Java 2 Enterprise Edition versión 1.5, manejador de base de datos PostgreSQL 8.3, extensión PostGIS para PostgreSQL versión 1.3 y sistema operativo Windows Vista Home Edition

1.5.1.3 SBLAGWMMS-01-01 Configuración y conexión con la base de

datos relacional

1.5.1.3.1 Propósito

Configurar y conectar el software al manejador de base de datos PostgreSQL.

1.5.1.3.2 Entorno de prueba

La prueba se lleva a cabo con el IDE Netbeans 6.8, el manejador de base de

datos PostgreSQL y el conector JDBC PostgreSQL.

1.5.1.3.3 Proceso

1. Establecer los parámetros de conexión a la bases de datos en el archivo confPostgres.

2. Ejecutar la aplicación. 3. Observar los resultados.

1.5.1.3.4 Resultado esperado

Obtener y mantener una conexión a la base de datos y verificar que se cuenta

con el acceso a ella en la aplicación.

1.5.1.4 SBLAGWMMS-01-02 Configuración y conexión con la base de datos

espacial


Configurar y conectar el software a la extensión PostGIS del manejador de

base de datos PostgreSQL para procesar datos geométricos.


La prueba se llevara a cabo con el IDE Netbeans 6.8, el manejador de base de

datos PostgreSQL, el conector JDBC PostgreSQL y la extensión espacial

postGIS.


Página 138

1.5.1.4.3 Proceso

1. Establecer los parámetros de conexión a la base de datos en el archivo de propiedades confPostgres y las librerías que permitirán procesar datos geométricos.

2. Ejecutar la aplicación 3. Observar los resultados


Observar y mantener la conexión a la base de datos y verificar que se cuenta

con el acceso a ella en la aplicación.

1.5.2 SBLAGWMMS-02 Recepción e interpretación de la información

1.5.2.1Propósito

Verificar que la recepción de la información se realice de manera correcta de

acuerdo a los criterios de búsqueda que se reciban de la petición del cliente móvil,

así como la correcta interpretación de la información que proviene del dispositivo.


Para la ejecución de este grupo de pruebas son necesarias las interacciones de

un dispositivo móvil que realiza la petición, el módem GSM que recibirá la

petición y el software SBLAGWMMS.

1.5.2.3 SBLAGWMMS-02-01 Recepción e interpretación de mensajes


Obtener e interpretar la información de los mensajes de texto que son

enviados al servidor mediante el dispositivo móvil para su procesamiento.


Se realizan en la computadora que contiene el servidor de base de datos,

módem GSM y el software SBLAGWMMS.

1.5.2.3.3 Proceso

1. Verificar que el software SBLAGWMMS se esté ejecutando, en caso contrario iniciar su ejecución.

2. Enviar la petición desde el dispositivo móvil hacia el servidor. 3. Se lee el mensaje que se ha recibido y se extraen los datos de la

información recibida. 4. Esperar la llegada de la petición y leer la información recibida.


Comprobar que se ha recibido e interpretado correctamente la información

proveniente del dispositivo móvil.

1.5.3 SBLAGWMMS-03 Generación del mapa

1.5.3.1 Propósito

Verificar que la generación del mapa se realice correctamente con la información

pertinente de la ruta y los puntos de referencia basándose en el perfil del

dispositivo.


Página 139


Esta prueba se realiza en la computadora que contiene el servidor de base de

datos, el servidor de mapas y la aplicación SBLAGWMMS.

1.5.3.3 SBLAGWMMS-03-01 Obtención del perfil del dispositivo


Obtener las características principales del dispositivo móvil para realizar el

proceso de acuerdo a su perfil.


Se realiza en la computadora con el manejador de base de datos relacional y

la aplicación SBLAGWMMS.

1.5.3.3.3 Proceso

1. Ejecutar la aplicación SBLAGWMMS. 2. Abrir la conexión de PostgreSQL. 3. Obtener los datos del dispositivo móvil y extraer las características del

mismo desde la base de datos relacional.


Verificar que el dispositivo móvil cumple con las características esenciales

para brindarle el servicio, el cual debe soportar la configuración CLDC 1.1 y el

perfil MIDP 2.0 así como las especificaciones JSR 179, JSR 205 y el JSR 225.

1.5.3.4 SBLAGWMMS-03-02 Obtención del mapa imagen


Obtener el mapa del servidor de mapas Geoserver de acuerdo a las

coordenadas de origen y destino.


Esta prueba se realiza en la computadora que contiene la base de datos

espacial y la aplicación SBLAGWMMS, el servidor de mapas puede estar

contenido en la misma computadora o en una externa.

1.5.3.4.3 Proceso

1. La aplicación SBLAGWMMS debe estar ejecutándose, en caso contrario iniciar la ejecución.

2. Consultar a la base de datos espacial con las coordenadas origen del dispositivo móvil para localizar y obtener el punto de interés del usuario.

3. Crear el BBOX (Bounding Box-Caja) del mapa de acuerdo a las coordenadas origen y destino.

4. Realizar petición WMS al servidor de mapas de acuerdo al BBOX creado y las características de pantalla del dispositivo móvil. Por último se obtiene el mapa.


Lograr la obtención del mapa de acuerdo a las coordenadas origen-destino y

las características del dispositivo móvil.


Página 140

1.5.3.5 SBLAGWMMS-03-03 Generación y obtención de la ruta destino


Obtener la ruta mediante las capas de nodos y aristas aplicando el algoritmo

de ruta.


Se realiza en la computadora que tenga acceso al servidor de mapas y la

base de datos espacial.

1.5.3.5.3 Proceso

1. Realizar consultas espaciales a las tablas de nodos y aristas delimitado por las coordenadas del BBOX creado, obteniendo la información.

2. Generar el grado de acuerdo a los nodos y aristas obtenidos, ingresando el grafo, el nodo origen y destino como parámetros al algoritmo de ruta.


Obtener la ruta que ubica el punto de interés del usuario.

1.5.3.6 SBLAGWMMS-03-04 Obtención de los POR (Point of Reference)


Obtener los puntos de referencia dependiendo de los nodos que conforman la

ruta que ubica el destino desde la ubicación del dispositivo móvil.


Esta prueba se lleva a cabo en la computadora que contiene la base de datos

espacial y la aplicación SBLAGWMMS.

1.5.3.6.3 Proceso

1. Obtener los nodos de la ruta generada. 2. Consultar los puntos de interés que se encuentren en un radio no mayor

de 100 metros de cada nodo y obtener dicha información. 1.5.3.6.4 Resultado esperado

Obtener la información de los puntos de referencia.

1.5.4 SBLAGWMMS-04 Envío de la información

1.5.4.1 Propósito

Verificar que el archivo SVG-Tiny del mapa contenga los datos pertinentes a la

petición del usuario, mismo que será enviado al dispositivo móvil cliente mediante

conexión HTTP.


Para este caso de prueba se realiza en el emulador para dispositivos móviles

versión 2.5 para CLDC, servidor de mapas, servidor de aplicaciones y el

dispositivo móvil Nokia N97.

1.5.4.3 SBLAGWMMS-04-01 Crear y enviar el archivo SVG-Tiny que contiene

el mapa croquis SVG-Tiny mediante HTTP



Página 141

Crear el mapa croquis en formato SVG-Tiny incluyendo el mapa recibido del

servidor de mapas, las coordenadas de la ruta y la información de los puntos

de referencia.


A través de la aplicación SBLAGWMMS se añaden los datos al archivo SVG-

Tiny necesarios para el resultado que dará respuesta a la petición realizada.

1.5.4.3.3 Proceso

1. Se ejecuta la aplicación para obtener los datos necesarios que serán añadidos al archivo SVG-Tiny.

2. Se añade la información al archivo SVG-Tiny, los datos de la ruta y los datos de puntos de referencia serán de tipo texto, el mapa se añade como dato tipo imagen.

3. Se envía el archivo al flujo de datos de salida del servlet para dar respuesta a la petición deseada.


Se crea y envía el mapa croquis en formato SVG-Tiny con la información

necesaria para localizar el punto de interés del usuario.

1.6 Resultados de las pruebas realizadas presentadas en categorías A continuación se presentan las pruebas realizadas de las diferentes categorías que se

pueden realizar por medio de la aplicación SketchMap4U desde el dispositivo móvil.

CATEGORÍA: TAXI

Resultado: OK


Página 142

Figura C.1 Resultados de la categoría Taxi.

Observaciones: El archivo SVG-Tiny es creado mediante los datos obtenidos (el mapa, la ruta y los puntos de referencia). La creación y el envío del archivo SVG-Tiny al dispositivo móvil se realizan correctamente.

CATEGORÍA: PASTELERÍA

Resultado: OK


Página 143

Figura C.2 Resultados de la categoría Pastelerías


CATEGORÍA: MINI SÚPER

Resultado: OK

Figura C.3 Resultados de la categoría Mini súper



Página 144

CATEGORÍA: GYM

Resultado: OK

Figura C.4 Resultados de la categoría Gym


CATEGORÍA: ESCUELAS

Resultado: OK


Página 145

Figura C.5 Resultados de la categoría escuela


CATEGORÍA: FARMACIAS

Resultado: OK

Figura C.6 Resultados de la categoría Farmacia



Página 146

CATEGORÍA: HOTELES

Resultado: OK

Figura C.7 Resultados de la categoría Hotel


CATEGORÍA: BANCOS

Resultado: OK


Página 147

Figura C.8 Resultados de la categoría Banco


CATEGORÍA: AUTOBUSES

Resultado: OK


Página 148

Figura C.9 Resultados de la categoría bus


CATEGORÍA: CINE

Resultado: OK

Figura C.10 Resultados de la categoría cine



Página 149

CATEGORÍA: HOSPITAL

Resultado: OK

Figura C.11 Resultados de la categoría Hospital



Página 150

CATEGORÍA: RESTAURANTES

Resultado: OK

Figura C.12 Resultados de la categoría Restaurante



Página 151

CATEGORÍA: SUPERMERCADOS

Resultado: OK

Figura C.13 Resultados de la categoría Súper Mercado


ANEXO D Scalable Vector Graphics (SVG)

Describe ejemplos para añadir puntos de interés y puntos de referencia a una imagen

SVG Tiny versión 1.1.

Anexo D. Scalable Vector Graphics (SVG)

Página 153

SVG significa, Scalable Vector Graphics, una gramática XML para el desarrollo de

gráficos vectoriales, en un espacio de nombre XML. Scalable significa que incrementa o

disminuye uniformemente. Los gráficos SVG pueden ser desplegados en forma

independiente de la resolución de pantalla, también pueden ser magnificados para la

observación de detalles.

Los vectores gráficos contienen objetos geométricos, tales como, líneas y curvas, estos

dan gran flexibilidad, comparados con formatos como PNG o JPG, donde la información

esta almacenada para cada pixel del gráfico.

Las gramáticas XML existentes representan información textual o información cruda de

ámbitos financieros, con capacidades más limitadas que el elemento HTML, IMG. SVG

viene a ocupar ese bache, ofrece gráficos vectoriales, junto con información estructurada,

en un espacio de nombre XML.

SVG se escribe en texto plano, lo que abre posibilidades de generar gráficas en tiempo

real para distintos terminales, incluida, la telefonía celular y una multitud de aplicaciones

que manejan mapas, como las medio ambientales.

Las características del SVG son las siguientes:

Tiene todas las cualidades asociadas a un formato vectorial: es escalable,

compacto, con formas editables mediante curvas Bézier, con contornos

suavizados, transparencias y capaz de incluir mapas de bits.

El tamaño de los ficheros SVG es muy compacto.

El texto es editable, admitiendo las fuentes escalables más comunes, como

TrueType o Type 1. Esto supone una ventaja sobre los formatos gif o jpg: el texto

que contiene un gráfico SVG puede ser editado, seleccionado, usado como

referencia para un enlace indexado por los buscadores, etc.

La calidad de colores es excelente. El color del gráfico se puedecalibrar con los

sistemas estándar de gestión de color.

El fichero SVG no es binario: se trata de un fichero de texto normal y corriente.

Esto significa que se puede editar con cualquier procesador de textos y sus

contenidos se pueden indexar, buscar, etc.

Es compatible con los estándares actuales de la web.

Incluye soporte para hojas de estilo CSS (cascading style sheets). Esto significa

que con las hojas de estilo será posible modificar en cascada no sólo texto, sino

también gráficos en una colección de ficheros.

Puede incluir código para modificar el gráfico dinámicamente.

Es xml, y xml es un formato extensible. Los fabricantes de software empiezan a

adoptarlo como formato nativo para sus aplicaciones. La consecuencia es que

SVG va a ser comprensible por cualquier aplicación que reconozca el formato xml.

Admite efectos de sonido, visuales, eventos asociados al ratón, etiquetas

informativas, etc.


Página 154

Puede generarse dinámicamente en un servidor web como respuesta a

instrucciones de Java, JSP, JavaScript, Perl, Plsql, ASP, Xslt, etcétera. Por

ejemplo, pueden crearse en tiempo real gráficos con las cotizaciones de bolsa.

Un fichero SVG tiene un tamaño menor que sus equivalentes codificados en mapa

de bits como ficheros gif o jpg.

Los gráficos SVG son independientes de la resolución, de modo que su tamaño

puede ser aumentado o reducido mediante el zoom sin que la calidad de la imagen

resulte deteriorada.

Los objetos gráficos, al estar expresados en xml, pueden ser etiquetados

textualmente. Esta circunstancia constituye una gran ventaja a la hora de su

posterior indización y recuperación. De hecho, los documentos SVG pueden ser

indizados por los motores de búsqueda de la web y, por lo tanto, la información

que contienen es directamente recuperable como en cualquier otro documento

xml.

Las limitantes que tiene el SVG son las siguientes:

Código abierto. Algunos creadores de SVG se preocupan de que el código fuente

de sus gráficos esté disponible a los usuarios del sitio, esto puede crear temor.

Uso intensivo de CPU. Un visualizador de SVG hace uso extensivo del CPU

durante los múltiples cálculos requeridos por complejas animaciones SVG.

Herramientas limitadas. Inevitablemente toma tiempo después de que una

tecnología es liberada para que se desarrollen herramientas y se hagan

disponibles sin licencias al público.

SVG tienen su propio DOM (Document Object Model), que está basado en el DOM de

XML y permite la manipulación específica del modelo de objetos de un documento SVG.

El propósito del SVG DOM es permitir el control para manipular la estructura y contenido

de un documento SVG mediante la programación, [Negrete, 2004].

Los perfiles del SVG especifican la definición de tipo de documento XML SVG del archivo.

En la siguiente tabla se describen los diferentes tipos y versiones de SVG que pueden ser

manipulados por un dispositivo móvil.

Versión Descripción

SVG 1.0 SVG 1.1

Adecuados para archivos SVG que se van a ver en un ordenador de sobremesa. SVG 1.1 es la versión completa de la especificación SVG, de la que SVG Tiny 1.1, SVG Tiny 1.1 Plus, SVG Tiny 1.2, y SVG Basic 1.1 son subconjuntos.

SVG Basic 1.1

Adecuado para archivos SVG que se van a ver en dispositivos con necesidades medias de alimentación, como los dispositivos portátiles. Tenga en cuenta que no todos los dispositivos portátiles admiten el perfil SVG Basic. Por lo tanto, seleccionar esta opción no garantiza que el archivo SVG se podrá ver en todos los dispositivos portátiles. SVG Basic no admite recorte no rectangular ni determinados efectos de filtro SVG.

SVG Tiny 1.1 SVG Tiny 1.1+

Adecuados para archivos SVG que se van a ver en dispositivos pequeños como teléfonos móviles. Tenga en cuenta que no todos los teléfonos


Página 155

móviles admiten los perfiles SVG Tiny y SVG Tiny Plus. Por lo tanto, seleccionar alguna de estas opciones no garantiza que el archivo SVG se podrá ver en todos los dispositivos pequeños.

SVG Tiny 1.2

Adecuado para archivos SVG que se van a ver en varios dispositivos, desde PDA y móviles, hasta equipos portátiles y de escritorio.

SVG Tiny no admite degradados, transparencia, recorte, máscaras, símbolos ni efectos

de filtro SVG. SVG Tiny Plus incluye la capacidad para poder ver degradados y

transparencia, pero no admite recorte, máscaras, símbolos ni efectos de filtro SVG.

La estructura de un archivo svg es el siguiente:

1 <?xml version=”1.0” encoding=”ISO-8859-1” standalone=”no”?>

2 <!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1 Tiny//EN”

“http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd”>

3 <svg width=”240” height=”320” viewBox=”0 0 25 15”

xmlns=”http://www.w3.org/2000/svg”

xmlns:xlink=”http://www.w3.org/1999/xlink”

version=”1.1” baseProfile=”tiny”>

4 <-- SVG content goes here -->

5 </svg>

Figura D.1 Estructura de un archivo SVG-Tiny 1.1

La extensión de una imagen SVG, independientemente del perfil del que se trate es svg.

El tipo de MIME de estos gráficos es image/svg+xml.

Perfiles SVG Móviles

SVG Móvil se refiere específicamente a dispositivos móviles pequeños, la gran variedad

de dispositivos móviles permite la generación de diferentes versiones de SVG, ya que

cada dispositivo móvil tiene características diferentes con respecto a otros en cuanto a

velocidad de procesamiento, memoria y soporte de colores.

Para hacer frente a esta gama de familias de dispositivos se definen dos perfiles. El

primero SVG Tiny (SVGT) es adecuado para los dispositivos móviles muy restringidos,

mientras que el segundo perfil SVG Basic (SVGB) está dirigido a dispositivos móviles de

nivel superior.

Debido a la poca memoria, potencia de procesamiento y demostración limitada de los

dispositivos móviles, SVG introduce restricciones en el contenido, los tipos de atributos,

propiedades y el comportamiento del agente de usuario. Esta sección describe estas

limitaciones.

Para garantizar la interoperabilidad entre contenido compatible con los distintos perfiles se

especifica un subconjunto de propiedades de SVGB los tenga también SVGT. En la figura

D.2 se muestran los perfiles SVG.





Página 156

Figura D.2 Perfiles SVG

La relación de poder de computación entre los tres tipos de dispositivos (celulares, {PDA,

SmarthPhone}, computadoras portátiles) se ve muy similar a una pirámide. La parte

superior de la pirámide es el conjunto de las familias de los teléfonos móviles con

características limitadas. Estas características están disponibles en una PDA teniendo

características más avanzadas que son en sí mismos todos los disponibles en una

computadora de escritorio o portátil siendo más avanzados. Así, un teléfono móvil todo lo

que puede hacer es factible por una PDA, y todo lo factible de un PDA es factible por una

computadora. Por lo tanto, se decidió que SVG Tiny sería un subconjunto estricto de SVG

Basic, por sí misma un subconjunto estricto de SVG Full, [XMLcom, 2004]. En la siguiente

tabla se muestran los tipos de datos que soporta el perfil móvil.

Tabla D.1 Tipos de datos del perfil móvil

Tipo de dato SVGBasic SVGTiny

Numérico Si Si

Coordenadas Si Si

Listas Si Si

Angulo Si, con identificadores CSS Si, sin identificadores CSS

Color CSS2 compatible a sRGB y 16 colores originales XHTML, no soportan X11.

CSS2 compatible a sRGB y 16 colores originales XHTML, no soportan X11.

Relleno Si Sólo colores sólidos

Porcentaje Si No

Transformación de Listas Si SI

URI Si Si

Frecuencia No No

Tiempo Si Si

De acuerdo a la especificación [SVG, 2009] se tienen algunas propiedades que son

compatibles en ambos perfiles móviles. A continuación se describen algunas de las

propiedades:

Sistemas de coordenadas y transformaciones

SVGB y SVGT soportan la transformación de atributos. Los siguientes tipos de

transformación son compatibles:

Perfil MOBILE

Perfil FULL


Página 157

Matrix (<a> <b> <c> <d> <e> <f>)

Translate (<tx> [<ty>])

Scale (<sx> [<sy>])

Rotate (<rotate_angle> [<cx> <cy>])

SkewX (<skew_angle>)

SkewY (<skew_angle>)

SVGB y SVGT soportan el atributo viewBox, y las restricciones de los valores del atributo

preserveAspectRadio.

Shapes

SVGB y SVGT soportan el atributo path, excepto las curvas elípticas, también soportan

las formas básicas (rectángulos, círculos, elipses, líneas, poli líneas y polígonos).

Texto

SVGB y SVGT representan texto con los caracteres Unicode, permite seleccionar el texto

y operaciones de portapapeles. SVGT no soporta texto en el path.

Relleno, Relieve y símbolos.

SVGB y SVGT soportan relleno y relieve en elementos path y formas básicas con colores

sólidos.

Gradientes y patrones

SVGB soporta colores sólidos, gradientes, patrones y colores personalizados. SVGT solo

soporta colores sólidos.

Efectos de filtrado

SVGB soporta un subconjunto de efectos de filtros. SVGT no soporta.

Interactividad

SVGB y SVGT soportan eventos con animaciones declaradas.

Enlaces

SVGB y SVGT soportan la activación de hipervinculos de contenidos SVG a otros

recursos Web.

Script

SVGT no soporta los script. SVGB permite los script que incluyen características de SVG

1.1.

Animación

Ambos soportan las animaciones. SVGT sólo admite animación declarativa.


Página 158

Representación de puntos referencia en un mapa SVG es un vocabulario xml por medio del cual se formaliza un conjunto de elementos gráficos como rectángulos, líneas, polígonos, elipses, etcétera. De la combinación de esos elementos surgen los documentos SVG. La característica más destacada de esos documentos es que son a la vez texto e imágenes, se utilizan para representar visualmente diversas áreas de la ciencia y del mundo real, [DelaRosa, 2009]. El formato SVG en el ámbito de los Sistemas de Información Geográfica es un estándar muy popular para visualizar datos geoespaciales. Las herramientas GIS ofrecen interfaces para exportar SVG, sin embargo, tiene muchas limitaciones que hacen difícil la realización de aplicaciones GIS afectando la visualización adecuada de los datos geográficos. En esta sección se describen los elementos SVG que permiten visualizar puntos de referencia de un camino en un mapa SVG, específicamente la versión 1.1 para dispositivos móviles.

Elemento path Los elementos path son útiles para crear vistas profesionales en documentos SVG, siendo

los tag más difíciles de codificar a mano. Se pueden crear cualquier tipo de imágenes que

se pueden visualizar en diferentes aplicaciones. En la tabla D.1 se muestran los atributos

que pueden ser utilizados por el elemento path y en la tabla D.2 se describen los

comandos que pueden ser utilizados, el path se define con el atributo “d” separados con

comandos y coordenadas.

Tabla D.1 Atributos del elemento Path

Atributo Descripción

d

Define el path con un conjunto de comandos

transform Es utilizado por estos funciones: translate(x,y), scale(sx, sy), rótate(angle, cx, cy), skewX(angle), skewY(angle) y matrix(a,b,c,d,e,f)

De presentación Color, FillStroke, Graphics y Markes

Tabla D.2 Comandos utilizados en el path

Comando Parámetros Repite Descripción

M

x,y

Si

moveto: Mueve el objeto a una nueva ubicación. Ninguna línea se dibuja. Todos los datos de ruta deben empezar con un “comando M.

L

x,y

Si

lineto: Dibuja una línea desde el punto actual hasta el

punto (x, y).

H

x

Si

horizontal lineto: Dibuja una línea horizontal desde el punto actual a x.

V

y

Si

vertical lineto: Dibuja una línea vertical desde el punto actual a y.

C

x1 y1 x2 y2 x y

Si

curveto: Dibuja una curva cúbica de Bezier hasta el punto

(x, y), donde los puntos (x1, y1) y (x2, y2) son los puntos de inicio y de control final, respectivamente.

S

x2 y2 x y

Si

shorthand/smooth curveto: Dibuja una curva para el punto (x,

y) en el punto (x2, y2) es el punto de control final y el punto de

control de inicio es el reflejo del punto de control que finaliza.


Página 159

Q

x1 y1 x y

Si

Quadratic Bezier curveto: Dibuja un bezier cuadrático entre el

último punto y el unto (x, y) utilizando el punto(x1, y1) como el

punto de control.

T

x y

Si

Shorthand/smooth quadratic Bezier curveto: Dibuja un Bézier

cuadrático entre el último punto y el punto(x, y) utilizando el

reflejo del punto del control del pasado como el punto de control.

A

**

Si

elliptical arc: Dibuja y arco desde el punto actual a y. x, The actual scale factor and position of the arc needed to bridge the two points is computed by the SVG viewer. El factor de escala real y la posición del arco necesario para colmar los dos puntos es calculada por el visor SVG.

z

-

No

closepath: Cierra el camino. A line is drawn from the last point to the first. Se traza una línea desde el último punto al primero.

Elemento g El elemento g permite la agrupación de las etiquetas, siendo la forma primaria de los

documentos SVG que están estructurados. Las capas en SVG se representan por medio

del elemento “g”, el cual tiene la función de agrupar varios elementos. Elementos fuera y

dentro de un grupo son tratados de manera idéntica y no hay límite a la profundidad de la

agrupación.

Elemento defs El elemento defs se utilizan para definir elementos SVG sin que se muestren en pantalla.

Cosas como los gradientes y patrones en SVG deben ser predeclarados y referenciados

con el fin de utilizar dentro del cuerpo del SVG. Así pues, la etiqueta de defs se utiliza

para contener elementos de referencia en otras partes del documento SVG a través de

URIs.

Elemento use El elemento use utiliza una URI referenciada para la opción “g”, “svg” o de otro tipo

(rectángulo, circulo, texto, etc.) con un atributo id único y replicarlo. Este objeto replicado,

como elemento de “g” utiliza cualquier atributo de presentación aplicado a la etiqueta use

como valores por default. La copia es sólo una referencia a la original por lo que sólo

existe en los elementos contenidos en defs. Cualquier cambio de la copia no afecta a la

original puesto no es parte del documento.

Ejemplos A continuación se presenta un gráfico que representa el logo de OXXO.

1 <?xml version=”1.0” encoding=”utf-8”?> 2 <!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1 Tiny//EN” 3 “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd”> 4 5 <svg width=”240” height=”320” viewBox=”0 0 25 15” 6 xmlns=”http://www.w3.org/2000/svg” 7 xmlns:xlink=”http://www.w3.org/1999/xlink” 8 version=”1.1” baseProfile=”tiny”> 9 <defs id=”genericDefs”> 10 <g id=”oxxo” stroke=”none” stroke-width=”0”> 11 <rect x=”12.963” y=”12.458” fill=”#E42C35” width=”17.007” height=”4.833”/> 12 <path fill=”#F4DB27” d=”M30.25,11.688c0,0.242-0.149,0.438-0.333,0.438H13.296c-0.184,0-0.333-





Página 160

0.195-0.333-0.438l0,0 13 c0-0.241,0.149-0.438,0.333-

0.438h16.622C30.101,11.25,30.25,11.446,30.25,11.688L30.25,11.688z”/> 14 <path fill=”#F4DB27” d=”M29.97,18.062c0,0.242-0.149,0.438-0.333,0.438H13.015c-0.184,0-0.333-

0.195-0.333-0.438l0,0 15 c0-0.241,0.149-0.438,0.333-

0.438h16.622C29.82,17.625,29.97,17.821,29.97,18.062L29.97,18.062z”/> 16 <text transform=”matrix(1 0 0 1 12.5425 17.167)” fill=”#FBFBFB” font-family=”‟OldgateLaneOutline‟”

font-size=”6”>OXXO</text> 17 </g> 18 </defs> 19 <g id=”capa0”> 20 <use xlink:href=”#oxxo” transform=”translate(5 5) rotate(0) translate(-12.96 -12.45)” /> 21 </g> 22 </svg>

Figura D.3 Código SVG que representa el logo de OXXO

En la figura D.3 se muestra el código SVG que representa el logo de OXXO, primero se

definen los elementos en las líneas 9 al 18, posteriormente se agrupan elementos

contenidos en el elemento “g” que tiene oxxo como valor del id, declarando dentro éste los

elementos path y texto para construir el logo. Para que sea utilizado esta declaración se

utiliza el elemento “use” que hace referencia al grupo de elementos llamado “#oxxo”. La

figura D.4 representa la visualización del ejemplo.

Figura D.4 Logo del OXXO

A continuación se muestra en la figura D.5 el código SVG que visualiza una ruta y puntos

de referencia tal y como se puede ver en la figura D.6. La sección seleccionada en gris

muestra las definiciones de los logos de cada punto de referencia, se observa que cada

logo es un conjunto de elementos contenidos en elementos “g”. Las referencias a los

logos se representan mediante el elemento “use” seleccionados en azul. Cabe señalar

que realiza una copia exacta y se puede manipular sin modificar el logo original declarado

en defs.

1 <?xml version=”1.0” encoding=”UTF-8”?> 2 <!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1 Tiny//EN” “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-

tiny.dtd”> 3 4 <svg xmlns=”http://www.w3.org/2000/svg” xmlns:xlink=”http://www.w3.org/1999/xlink” version=”1.1”

baseProfile=”tiny” viewBox=”0 0 240 320”> 5 <defs id=”genericDefs”> 6 <g id=”oxxo” stroke=”none” stroke-width=”0”> 7 …..//Elementos del logo 8 </g>






Página 161

9 <g id=”oro” stroke=”none” stroke-width=”0” > 10 …..//Elementos del logo 11 </g> 12 <g id=”taxi” stroke=”none” stroke-width=”0”> 13 …..//Elementos del logo 14 </g> 15 <g id=”cinemax” stroke=”none” stroke-width=”0”> 16 …..//Elementos del logo 17 </g> 18 19 <path id=”Triangle” d=”M 6,0 L -3,3.7 v-6.7 z” fill=”#084B8A” stroke=”none” /> 20 21 </defs> 22 <g id=”capa0” display=”inline” stroke=”black”> 23 ….. 24 </g> 25 26 <g id=”capa3” display=”inline” stroke=”#0A2A0A” stroke-width=”0.2”> 27 <text x=”10” y=”10” font-size=”10”>Distancia a recorrer: 565.2121023466261</text> 28 <line x1=”124.0” y1=”227.0” x2=”147.0” y2=”225.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 29 <use xlink:href=”#Triangle” transform=”translate(135.5 226.0) rotate(359.2283309922658)” /> 30 <line x1=”147.0” y1=”225.0” x2=”148.0” y2=”198.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 31 <use xlink:href=”#Triangle” transform=”translate(147.5 211.5) rotate(283.6753688645108)” /> 32 <line x1=”148.0” y1=”198.0” x2=”147.0” y2=”192.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 33 <line x1=”147.0” y1=”192.0” x2=”137.0” y2=”192.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 34 <line x1=”137.0” y1=”192.0” x2=”133.0” y2=”191.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 35 <line x1=”133.0” y1=”191.0” x2=”132.0” y2=”190.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 36 <line x1=”132.0” y1=”190.0” x2=”132.0” y2=”188.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 37 <line x1=”132.0” y1=”188.0” x2=”132.0” y2=”187.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 38 <line x1=”132.0” y1=”187.0” x2=”141.0” y2=”158.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 39 <use xlink:href=”#Triangle” transform=”translate(136.5 172.5) rotate(294.4114687460243)” /> 40 <line x1=”141.0” y1=”158.0” x2=”143.0” y2=”148.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 41 <use xlink:href=”#Triangle” transform=”translate(142.0 153.0) rotate(283.5149934205348)” /> 42 <line x1=”143.0” y1=”148.0” x2=”144.0” y2=”141.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 43 <line x1=”144.0” y1=”141.0” x2=”142.0” y2=”112.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 44 <use xlink:href=”#Triangle” transform=”translate(143.0 126.5) rotate(269.50193983749386)” /> 45 <line x1=”142.0” y1=”112.0” x2=”141.0” y2=”93.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 46 <use xlink:href=”#Triangle” transform=”translate(141.5 102.5) rotate(269.51821326518393)” /> 47 <line x1=”141.0” y1=”93.0” x2=”135.0” y2=”43.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 48 <use xlink:href=”#Triangle” transform=”translate(138.0 68.0) rotate(269.4513674007766)” /> 49 <line x1=”135.0” y1=”43.0” x2=”136.0” y2=”43.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> 50 51 <use xlink:href=”#taxi” transform=”translate(158.0 228.0) rotate(0) translate(-14.75 -36.62)” /> 52 <circle cx=”153.0” cy=”230.0” r=”2.0” fill-opacity=”0.5” stroke-width=”0.5” fill=”red” stroke=”black” /> 53 54 <use xlink:href=”#oxxo” transform=”translate(145.0 189.0) rotate(0) translate(-12.96 -12.45)” /> 55 <circle cx=”140.0” cy=”191.0” r=”2.0” fill-opacity=”0.5” stroke-width=”0.5” fill=”red” stroke=”black” /> 56 57 <use xlink:href=”#oro” transform=”translate(145.0 111.0) rotate(0) translate(-14.5 -27.26)” /> 58 <circle cx=”140.0” cy=”113.0” r=”2.0” fill-opacity=”0.5” stroke-width=”0.5” fill=”red” stroke=”black” /> 59 60 <use xlink:href=”#cinemax” transform=”translate(145.0 91.0) rotate(0) translate(-22.86 -53.99)” /> 61 <circle cx=”140.0” cy=”93.0” r=”2.0” fill-opacity=”0.5” stroke-width=”0.5” fill=”red” stroke=”black” /> 62 63 <circle cx=”136.0” cy=”39.0” r=”2.0” fill-opacity=”0.5” stroke-width=”0.5” fill=”red” stroke=”black” /> 64 <text x=”141.0” y=”37.0” font-size=”8” font-family=”Verdana” fill=”#0A2A0A” stroke-width=”0”>Super gym</text> 65 </g> 66 </svg>

Figura D.5 Código SVG que representa puntos de referencia en un mapa


Página 162

Figura D.6 Puntos de referencia representados mediante logos en SVG-Tiny

REFERENCIAS

[Arienza, 2006] ArienzaJorge L.; Sistemas Operativos móviles,

http://jlarienza.blogspot.com/2006/10/sistemas-operativos-moviles.html; última

consulta: Noviembre 2008.

[Brinkhoffi, 2008] Thomas Brinkhoff1, Christof Lindenbeck2, Jürgen Weitkämper3,

1,3Oldenburg/Ostfriesland/Wilhelmshaven (University of Applied Sciences), 2 in

medias res, Gesellschaft für Informationstechnologie mbH, Oldenburgo, 2008,

Interoperable Data Processing by Mobile Geospatial Applications, , última consulta

Diciembre 2008

[Cabral, 2005] Igor Pinheiro de Sales Cabral1,Jorge Henrique Fernandes2, Luiz Marcos Garcia

Gonçalves1, 1Universidade Federal do Rio Grande do Norte, 2Universidade de

Brasília, 2008; gvSIG para dispositivos móviles;

http://marte.dpi.inpe.br/col/ltid.inpe.br/sbsr/2004/11.18.18.17/doc/2067.pdf, 2005,

última consulta: Septiembre 2008

[COFETEL, 2009] COFETEL, Penetración de la telefonía móvil en México 1990-2007,

http://www.cft.gob.mx/wb/Cofetel_2008/Cofe_penetracion_de_la_telefonia_movil_po

r_region_, última consulta: julio 2009

[deeGree, 2009] deeGree, 2009. Sitio oficial de deeGree. [En línea]. http://www.deegree.org/.

Consultado en Enero 2009.

[deviceatlas, 2008] Device Atlas. Mobile Device Intelligence. http://deviceatlas.com/ , 2008, última

consulta: Diciembre 2008

[Devmobi, 2007] SVG & Mobile | dev.mobi. 2007. Dev.mobi Internet Made Mobile. [En línea]

http://dev.mobi/article/svg-mobile. Consultaso en abril de 2008.

[DelaRosa, 2009] De la Rosa Antonio, Senso Jose A.; Universidad de Granada; Dualidad texto-

imagenen SVG: nuevas posibilidades para la descripción de la información gráfica,

diciembre 2009.

[GPSWiki, 2009] Wikipedia, la enciclopedia libre, “Sistema de posicionamiento global”.

http://es.wikipedia.org/wiki/Sistema_de_posicionamiento_global., última consulta:

junio 2009.

[Geoserver, 2009] Geoserver, 2009. Sitio oficial de Geoserver. [En línea].

http://geoserver.org/display/GEOS/Welcome. Consultado en Febrero 2009.

[GSM, 2009] Global System for Mobile communications, http://en.wikipedia.org/wiki/GSM, última

consulta: Agosto 2009

[LBSWiki, 2009] Wikipedia, la enciclopedia libre, “Sistema basado en localización”.

http://es.wikipedia.org/wiki/Lbs , última consulta: junio 2009.

[GvSIG, 2009] gvSIG, 2009. Sitio oficial de gvSIG. [En línea]. http://www.gvsig.gva.es/. Consultado

en Enero 2009.

[Hampe, 2005] Mark Hampe1 and Volker Paelke2; Institute of Cartography and Geoinformatics,

University of Hannover Appelstraße; Adaptive maps for mobile applications,

http://jlarienza.blogspot.com/2006/10/sistemas-operativos-moviles.html

http://marte.dpi.inpe.br/col/ltid.inpe.br/sbsr/2004/11.18.18.17/doc/2067.pdf

http://www.cft.gob.mx/wb/Cofetel_2008/Cofe_penetracion_de_la_telefonia_movil_por_region_

http://www.cft.gob.mx/wb/Cofetel_2008/Cofe_penetracion_de_la_telefonia_movil_por_region_

http://www.deegree.org/

http://deviceatlas.com/

http://dev.mobi/article/svg-mobile

http://es.wikipedia.org/wiki/Sistema_de_posicionamiento_global

http://geoserver.org/display/GEOS/Welcome.%20Consultado%20en%20Febrero%202009

http://en.wikipedia.org/wiki/GSM

http://es.wikipedia.org/wiki/Lbs

http://www.gvsig.gva.es/

Referencias

Página 164

http://www.ikg.uni-

hannover.de/publikationen/publikationen/2005/hampe_mobilemaps2005.pdf, 2005;


[Ichiro,2002] Hashiba Ichiro， Ohba Toshifumi; NAKAI Akifumi, Ntt Data Corporation, 2002;

Development of Route Map Service for Mobile Phone based on G-XML,

http://www.cartesia.org/articulos/g-xml/GISA(English)Final.doc; última consulta:

Septiembre 2008

[IEEE289, 2009] IEEE Standard for Software Test Documentation, Software Engineering Technical

Committee of the IEEE Computer Society, ISBN 0-7381-1444-8

[JIPDC, 2006] Japan Information Processing Development Corporation, Database Promotion

Center, Japan, http://www.dpc.jipdec.or.jp/gxml/contents-e/index.htm, 2006, última

consulta: septiembre 2008

[Kosmo, 2009] Kosmo, 2009. Sitio oficial de kosmo. [En línea]. http://www.opengis.es/. Consultado

en Enero 2009.

[Magon, 2006] Magon Ajay, Shukla Reena, “LBS the ingredients and the alternatives”. Gis

Development. Disponible en:

http://www.gisdevelopment.net/technology/lbs/techlbs006.htm Última consulta: Junio

2009.

[Mapserver, 2009] Mapserver, 2009. Sitio oficial de Mapserver. [En línea]. http://mapserver.org/.

Consultado en Febrero 2009.

[MapWindows, 2009] MapWindows, 2009. Sitio oficial de MapWindows. [En línea].

http://www.mapwindow.org/. Consultado en Febrero 2009.

[Montesinos, 2008] Miguel Montesinos Lajara, Javier Carrasco Marimón; PRODEVELOP, 2008;

Adaptive Visualisation of Geographic Information on Mobile Devices;

http://www.sigte.udg.es/jornadassiglibre/uploads/file/Comunicaciones/4(1).pdf;


[MWM, 2008] Microsoft; Windows Mobile 6.0; http://msdn.microsoft.com/en-

us/library/bb158486.aspx; última consulta: Noviembre 2008

[Negrete, 2004] Negrete López Gustavo A., Rdríguez Ortega Benjamín; Universidad de las Americas

Puebla; Arquitectura híbrida de acceso y visualización de datos. [En línea]

http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/negrete_l_ga/ ; última consulta:

Diciembre 2009

[Netbeans, 2009] NetBeans, http://www.netbeans.org/, última consulta: Agosto 2009

[NokiaMMS, 2007] Nokia Europe-MMS-Technologies. Nokia, 2007.

http://europe.nokia.com/A4172038. última consulta: Junio 2009

[oJUMP, 2009] openJUMP, 2009. Sitio oficial de openJUMP. [En línea].

http://openjump.org/wiki/show/HomePage. Consultado en Enero 2009.

[openLayers, 2009] openLayers, 2009. Sitio oficial de openLayers. [En línea]. http://openlayers.org/.

Última consulta: Febrero 2009.

http://www.ikg.uni-hannover.de/publikationen/publikationen/2005/hampe_mobilemaps2005.pdf

http://www.ikg.uni-hannover.de/publikationen/publikationen/2005/hampe_mobilemaps2005.pdf

http://www.cartesia.org/articulos/g-xml/GISA(English)Final.doc

http://www.dpc.jipdec.or.jp/gxml/contents-e/index.htm

http://www.opengis.es/

http://www.gisdevelopment.net/technology/lbs/techlbs006.htm

http://mapserver.org/

http://www.mapwindow.org/

http://www.sigte.udg.es/jornadassiglibre/uploads/file/Comunicaciones/4(1).pdf

http://msdn.microsoft.com/en-us/library/bb158486.aspx

http://msdn.microsoft.com/en-us/library/bb158486.aspx

http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/negrete_l_ga/

http://www.netbeans.org/

http://europe.nokia.com/A4172038

http://openjump.org/wiki/show/HomePage.%20Consultado%20en%20Enero%202009

http://openlayers.org/

Referencias

Página 165

[XMLcom, 2004] XML.com: Going Mobile with SVG: Standards. O‟Reilly Media, Inc. [En línea]. http://www.xml.com/pub/a/2004/06/16/mobilesvg.html, Última consulta: Diciembre

2009

[Ortiz, 2001] Ortiz Gabriel. Tipos de SIG y modelos de datos. Un artículo introductorio para

entender las bases de los SIG. http://recursos.gabrielortiz.com/index.asp?Info=012.

Última consulta: Junio 2009

[Postgis, 2009] PostGIS, http://postgis.refractions.net/, última consulta: 2009

[Postgres, 2009] PostgreSQL, http://www.postgresql.org/ última consulta: Agosto 2009

[QGIS, 2009] Quantum GIS, 2009. Sitio Oficial de Quantum GIS. [En línea]. http://www.qgis.org/.

Consultado en Enero 2009.

[Quiñonez, 2007] Quiñonez Bernardino Pedro,Gateway SMS/MMS Pull Para Consultas

Dependientes/Independientes de la Ubicación con una Arquitectura de Servicios Web, cenidet 2007

[Reichembacher, 2004] Tumasch Reichenbacher; Instituto de Fotogrametría y Cartografía, 2004; Adaptive

Visualisation of Geographic Information on Mobile Devices; http://tumb1.biblio.tu-

muenchen.de/publ/diss/bv/2004/reichenbacher.pdf; última consulta: Septiembre

2008

[Roldán, 2005] Roldán David. Comunicaciones inalámbricas. México: Editorial Alfaomega, 2005

[Sabine, 2004] Sabine Geldof y Robert Dale; IMPROVING ROUTE DIRECTIONS ON MOBILE

DEVICES; Centre for Language Technology Macquarie University, Australia, 2004;

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.6150; última consulta:

Septiembre 2008

[SBL, 2009] Wikipedia, la enciclopedia libre, “Sistema basado en localización”.

http://es.wikipedia.org/wiki/Lbs , última consulta: junio 2009.

[Scherp, 2004] * Ansgar Scherp, Susanne Boll; OFFIS, Oldenburg, University of Oldenburg;

mobileMM4U – framework support for dynamic personalized multimedia content on

mobile systems, 2004; http://medien.informatik.uni-

oldenburg.de/pubs/SB_mobileMM4U_TAMoCO_2004.pdf; última consulta:

Septiembre 2008

[SEXTANTE, 2009] SEXTANTE, 2009. Sitio oficial de SEXTANTE. [En línea].

http://forge.osor.eu/plugins/wiki/index.php?id=13&type=g. Consultado en Enero

2009.

[SFS, 2009] Open Geospatial Consortium. Simple Feature Specification.

http://portal.opengeospatial.org/files/?artifact_id=829, última consulta: Septiembre

2009.

[SG, 2005] Rodríguez Ramés “Estructura de paquetes” Revista Software Guru. Marzo-Abril

2005.

[SIG, 2009] Wikipedia, la enciclopedia libre, “Sistema de posicionamiento global”.

http://es.wikipedia.org/wiki/Sistema_de_posicionamiento_global., última consulta:

junio 2009.

http://www.xml.com/pub/a/2004/06/16/mobilesvg.html

http://recursos.gabrielortiz.com/index.asp?Info=012

http://postgis.refractions.net/

http://www.postgresql.org/

http://www.qgis.org/

http://tumb1.biblio.tu-muenchen.de/publ/diss/bv/2004/reichenbacher.pdf

http://tumb1.biblio.tu-muenchen.de/publ/diss/bv/2004/reichenbacher.pdf

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.6150

http://es.wikipedia.org/wiki/Lbs

http://medien.informatik.uni-oldenburg.de/pubs/SB_mobileMM4U_TAMoCO_2004.pdf

http://medien.informatik.uni-oldenburg.de/pubs/SB_mobileMM4U_TAMoCO_2004.pdf

http://forge.osor.eu/plugins/wiki/index.php?id=13&type=g

http://portal.opengeospatial.org/files/?artifact_id=829

http://es.wikipedia.org/wiki/Sistema_de_posicionamiento_global

Referencias

Página 166

[Steiniger, 2006] Steiniger Stefan, Neun Moritz, Alistair Edwardes “Foundations of Location Based

Services”, Departamento de Geografía, Universidad de Zurich, Suiza. 2006

[SVG, 2009] Moblie SVG Profiles: SVG Tiny, http://www.w3.org/TR/SVGMobile/, última consulta:

junio 2009

[Symbian, 2008] Symbian, http://www.symbian.com última consulta: noviembre 2008

[Tomcat,2009] Apache Tomcat, http://tomcat.apache.org/, última consulta: Agosto 2009 [Turner, 2003] Turner Alasdair, Penn Alan y Hillier Bill, An algorithmic definition of the axial map,

Noviembre, 2003. [uDIG, 2009] uDIG 2008. Sitio oficial de uDIG. [en línea]. http://udig.refractions.net/. Consultado

en Enero 2009.

[Victoria, 2008] Victoria Rincon Claudia, API para la gestión de mapas de navegación en

dispositivos móviles mediante el GPS y mensajería SMS/MMS, cenidet 2008

[Wikiversidad,2008] Wikiversidad; Sistemas Operativos,

http://es.wikiversity.org/wiki/Sistemas_operativos; última consulta: Noviembre 2008

[Wdsglobal, 2008] WDSGlobal “Device Management”

http://www.wdsglobal.com/downloads/infosheets/DeviceMine.pdf , 2007, última

consulta Diciembre 2008

[WMS, 2009] Web Map Service, http://www.opengeospatial.org/standards/wms , última consulta:

Agosto 2009

[WorldWind, 2009] WorldWind, 2009. Sitio oficial de WorldWind. [En línea].

http://worldwind.arc.nasa.gov/. Consultado en Febrero 2009.

[Wurfl, 2008] WURFL. La comunidad móvil más exitante del planeta, http://wurfl.sourceforge.net/ ,

2008, última consulta: Diciembre 2008

http://www.w3.org/TR/SVGMobile/

http://www.symbian.com/

http://tomcat.apache.org/

http://udig.refractions.net/

http://es.wikiversity.org/wiki/Sistemas_operativos

http://www.wdsglobal.com/downloads/infosheets/DeviceMine.pdf

http://www.opengeospatial.org/standards/wms

http://worldwind.arc.nasa.gov/

http://wurfl.sourceforge.net/

Generador de mapas croquis en formato SVG-Tiny para dispositivos móviles aplicando perfiles

Technology

Transcript of Generador de mapas croquis en formato SVG-Tiny para dispositivos móviles aplicando perfiles