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 SVGTiny 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. 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 1.5.2 1.6 Alcances _____________________________________________________________ 7 Limitaciones __________________________________________________________ 7 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 2.2.2 2.2.3 2.3 2.3.1 2.3.2 Componentes de los LBS _______________________________________________ 23 Funcionamiento ______________________________________________________ 24 Clasificación _________________________________________________________ 24 Sistema de información geográfica_________________________________26 GIS Vectoriales _______________________________________________________ 27 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 i 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 3.3.1 3.3.2 3.3.3 Base de datos MobileDevice ______________________________________74 DeviceMine v3.0 ______________________________________________________ 74 DeviceAtlas __________________________________________________________ 74 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 4.3.2 4.3.3 4.4 Obtener el perfil del dispositivo móvil ______________________________________ 81 Obtener puntos de interés ______________________________________________ 82 Obtener puntos de referencia ____________________________________________ 83 Generar mapa SVGTiny __________________________________________84 ii 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 iii 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 iv 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 v 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 vi 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 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 2 Capítulo I Introducción 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 API 2 , 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 3 Capítulo I Introducción 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 1991 1992 1993 63.9 160.9 312.6 386.1 1994 1995 1996 1997 1998 1999 2000 2001 571.8 688.5 1,021.9 1,740.8 3,349.5 7,731.6 14,077.9 21,757.6 2002 2003 2004 2005 25,928.3 30,097.7 38,451.1 47,141.0 2006 2007 2008 p/ 55,395.5 66,559.5 75,303.5 ago-09 78,257.3 70.3 72.3 62.6 52.6 45.1 36.3 25.4 29.1 21.6 14.2 8.0 jun-09 2008 p/ 2007 2006 2005 2004 2003 2002 2001 2000 1999 1998 1997 1996 1995 1994 1993 1992 1991 1990 0.1 0.2 0.4 0.4 0.6 0.8 3.5 1.1 1.8 Figura 1-1 Usuarios de dispositivos móviles por cada 100 habitantes 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 Página 4 Capítulo I Introducción 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 SMS MMS GPRS Movistar $ 0.98 $2.00 $0.14 x Kb Telcel $ 0.85 $ 2.00 $0.04 x Kb Iusacell $1.00 $5.00 $0.12 x Kb Nextel $0.86 $3.45 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 5 Capítulo I Introducción 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 Bluetooth 3 ; 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 6 Capítulo I Introducción 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 7 Capítulo I Introducción 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 8 Capítulo I Introducción 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. Búsqueda de ruta Datos de la ruta Obtener nodo y enlazarlo con una ruta S-GXML Datos espaciales ID Nodo, ID Enlace Obtener nodo relativo con una ruta Renderizando (Sentencia, lista puntos de interés, mapa simple) 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. Página 9 Capítulo I Introducción 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 10 Capítulo I Introducción 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 11 Capítulo I Introducción 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 12 Capítulo I Introducción 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. Cliente móvil Servidor PDA usando PoketSMIL WinCE HHC usando SVGBasic Player Celular móvil SVGTiny Internet Aplicación multimedia personaliza da con 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 Página 13 Capítulo I Introducción 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 14 Capítulo I Introducción 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 15 Capítulo I Introducción 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 (SDI 4 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 16 Capítulo I Introducción 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 17 Capítulo I Introducción 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 Página 18 Capítulo I Introducción 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 LENGUAJE DE DESARROLLO GENERA RUTA SOPORTE DE MENSAJERIA MEDIO DE TRANSPORTE FORMATOS HTTP SVG-Tiny HTTP SVG-Tiny GPRS | HTTP XSLT HTTP SMIL, SVG-Tiny GPRS | UMTS, HTTP SVGB MMS [Sabine, 2004] [Scherp, 2004] [Reichembacher, 2004] Windows Mobile / RPML, XSLT Windows Mobile / WFS, WMS, WMC J2ME / GML [Montesinos, 2008] J2ME/ WMS, WFS HTTP-WMS ECW, JPEG, PNG, GIF /SHP [Cabral, 2005] DELPHI 6 / XML HTTP SVG [Brinkhoffi, 2008] VC++ NET GPRS | HTTPWMS SVG J2ME GPRS | HTTP WMS SVG-Tiny [Hampe, 2005] Proyecto de tesis http://www.w3c.es/Prensa/2006/nota060810_SVGTiny S-GXML No especifica SMS [ichiro,2002] 5 ORIENTADO A LBS Capítulo I Introducción 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. Página 20 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 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. B A 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 Página 22 Capítulo II Marco teórico 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 23 Capítulo II Marco teórico 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. Posicionamiento Servidor Internet GPS BD Envío de SMS Dispositivos móviles Red de comunicaciones 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]. Página 24 Capítulo II Marco teórico 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…? Identificación y reconocimiento de personas u objetos. ¿Qué es? Posicionamiento, geocodificación, cálculo de distancia y área, búsqueda de relaciones. 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 25 Capítulo II Marco teórico 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. ii. iii. Puntos. Representan entidades únicas como: individuos, árboles, carros, ciudades y/o cualquier entidad que pueda representarse mediante un punto. Líneas. Representan entidades como carreteras, calles, ríos etc. 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 26 Capítulo II Marco teórico 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 27 Capítulo II Marco teórico 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]. Código de las celdas: 1 = Bosque 2 = Carretera 3 = Casa 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 Página 28 Capítulo II Marco teórico 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 29 Capítulo II Marco teórico 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. Perfil MOBILE Perfil FULL 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). CABECERA DATOS 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). Figura 2-10 Estructura de un mensaje SMS. Página 30 Capítulo II Marco teórico 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 31 Capítulo II Marco teórico 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]. Página 32 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 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 34 Capítulo III Análisis y diseño 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 35 Capítulo III Análisis y diseño (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 GEOMETRY_COLUMNS PK SRID SRID AUTH_NAME AUTH_SRID SRTEXT PROJ4TEXT 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 36 Capítulo III Análisis y diseño 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 37 Capítulo III Análisis y diseño 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. ii. iii. iv. Obtener puntos de interés mediante consulta a la base de datos espacial. 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. 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. 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 38 Capítulo III Análisis y diseño 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 N=número de nodos //se crea un arreglo grafo[N][N] mientras i < grafoTamaño hacer mientras j < grafo[i]Tamaño hacer grafo[i,j]=infinito fin_mientras fin_mientras double[] Ruta (grafo) //se crean dos arreglos del tamaño del grafo, nodoProcesado y caminoMinino mientras i < nodoProcesadoTamaño hacer nodoProcesado[i] = verdadero fin_mientras //se crean las distancias de los nodos, tomando como origen el nodo 0 mientras i < caminoMinimoTamaño hacer caminoMinimo[i]=grafo[0][i] fin_mientras //Se busca el nodo que no se haya calculado mientras i < nodoProcesadoTamaño -2 hacer mientras ¡nodoProcesado[k] hacer k=k+1 Página 39 Capítulo III Análisis y diseño 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 fin_mientras //Se comprueba que el vértice elegido es el de menor distancia al origen l=k mientras k < nodoProcesadoTamaño hacer si nodoProcesado[k] y caminoMinimo[l] > caminoMinimo[k] entonces l=k fin_si fin_mientras nodoProcesado[l]=falso k=1 //Se actualizan las distancias mientras k < nodoProcesadoTamaño hacer si nodoProcesado[k] y caminoMinimo[k] > caminoMinimo[l]+grafo[l][k] entonces caminoMinimo[k]=caminoMinimo[l]+grafo[l][k] fin_si fin_mientras 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. a b Figura 3-5 Representación del área de interés 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 Página 40 Capítulo III Análisis y diseño 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. a b c Figura 3-6 Aristas y nodos del área de interés 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. Figura 3-7 Grafo con los nodos inferidos iv. v. 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. 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. Página 41 Capítulo III Análisis y diseño Origen Destino Figura 3-8 Ruta obtenida del algoritmo de Dijkstra 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. Página 42 Capítulo III Análisis y diseño uc SketchM... Configurar RMS Construir petición HTTP Dispositiv o Móv il Env iar petición HTTP 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. Página 43 Capítulo III Análisis y diseño Tabla 3-1 Descripción del caso de uso: CU1 Configurar RMS ID: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito 1 Escenario de éxito 2 Escenario de fracaso 1: Escenario de fracaso 2: Incluye: Suposiciones: CU1 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-12. Configurar RMS Dispositivo móvil. Permite configurar una base de datos simple mediante RMS 1. Los datos de configuración default deben ser leídos y guardados en memoria volátil. La aplicación tendrá la configuración de acceso al servidor. 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. 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. 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. 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. CU1.1 Crear RMS, CU1.2 Leer RMS, CU1.3 Actualizar RMS 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 44 Capítulo III Análisis y diseño Tabla 3-2 Descripción del caso de uso: CU1.1 Crear RMS ID: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito Escenario de fracaso Incluye: Suposiciones: CU1.1 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-13. Crear RMS Dispositivo móvil. Permite crear una base de datos simple mediante RMS en el dispositivo móvil. 1. Los datos de configuración default deben ser leídos y guardados en memoria volátil. Se crea una base de datos en el dispositivo móvil para acceder al servidor. 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. 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. Se supone que se ha creado la base de datos RMS en memoria del dispositivo móvil. act CrearRMS Inicio Crear registro de almacenamiento (RecordStore) No Excepción RecordStore correct o Si Instanciar detector de registro (RecordListener) Agregar registro Añadir mas registros Si No Cerrar almacenamiento de registro (closeRecordListener) Fin Figura 3-13 Diagrama de actividad del caso de uso: CU1.1 Crear RMS Página 45 Capítulo III Análisis y diseño Tabla 3-3 Descripción del caso de uso: CU1.2 Leer RMS ID: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito Escenario de fracaso Incluye: Suposiciones: CU1.2 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-14. Leer RMS Dispositivo móvil. Permite leer los datos de la base de datos RMS contenido en el dispositivo móvil. 1. Se han de haber guardado los datos en la base de datos RMS. Se leen los datos de la base de datos en el dispositivo móvil para acceder al servidor. 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. 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. Se supone que se obtienen los datos de configuración que contiene el RMS. act LeerRMS Inicio Abrir registro de alamacenamiento (RecordStore) Instanciar detector de registros (RecordListener) Leer registro por indices getRecord(index) Si No Excepción Si Leido correctamente Leer otro registro No Cerrar el registro de almacenamiento Fin Figura 3-14 Diagrama de actividad del caso de uso: CU1.2 Leer RMS Página 46 Capítulo III Análisis y diseño Tabla 3-4 Descripción del caso de uso: CU1.3 Actualizar RMS ID: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito Escenario de fracaso Incluye: Suposiciones: CU1.3 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-15. Actualizar RMS Dispositivo móvil. Permite actualizar la base de datos RMS contenido en el dispositivo móvil. 1. Se leen los datos contenidos en la base de datos RMS. Se actualizan los datos de la base de datos en el dispositivo móvil para acceder al servidor. 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. 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. Se supone que se obtienen los datos de configuración que contiene el RMS. act ActualizarRMS Inicio Abrir Registro de almacenamiento (openRecordStore) Instanciar detector de registros (RecordListener) Actualizar registro por índice (setRecord(index, dato)) Excepción Agregado correctamente Si Actualizar más registros No Cerrar almacenamiento de registro Si (closeRecordStore) Fin Figura 3-15 Diagrama de actividad del caso de uso: CU1.3 Actualizar RMS Página 47 Capítulo III Análisis y diseño 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. uc ConstruirPeticionHTTP Construir petición HTTP Dispositiv o Móv il Figura 3-16 Diagrama de caso de uso: CU2 Construir petición HTTP act ConstruirPeticionHTTP Inicio Crear dato No Excepción Dato compatible Si Si Agregar dato Exist en otros dat os No Crear petición Fin 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 ID: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito CU2 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-17. Construir trama Dispositivo móvil. Permite construir la trama de la petición HTTP. 1. Tener la configuración realizada correctamente. Se construye la trama que servirá para realizar la petición HTTP. 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. Página 48 Capítulo III Análisis y diseño Escenario de fracaso Incluye: Suposiciones: 1. 2. 3. 4. Se crea dato. Dato no válido Se lanza excepción Se termina el proceso. 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. uc Env iarTrama Env iarTrama Dispositiv o móv il Figura 3-18 Diagrama de caso de uso: CU3 Enviar trama act Env iarTrama Inicio Establecer conexión con el serv idor No Excepción Conexión establecida Env iar trama Trama enviada Terminar proceso No Fin 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 ID: Nombre: Actores: Descripción: Precondiciones: CU3 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-19. Enviar trama Dispositivo móvil. Envía una petición HTTP al servidor. 1. Tener creado la trama de envío. Página 49 Capítulo III Análisis y diseño Poscondiciones: Escenario de éxito Escenario de fracaso Escenario de fracaso La trama es enviada al servidor. 1. Se establece conexión con el servidor 2. Se envía la trama por HTTP. 3. Terminar proceso. 1. Se establece conexión con el servidor. 2. No se establece la conexión. 3. Se lanza excepción 4. Terminar proceso. 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. uc GeneralSketchMapSer... Recibir petición HTTP Interpretar petición HTTP Serv idor Generar mapa SV GT Env iar mapa SV GT Figura 3-20 Diagrama general de casos de uso de la aplicación SketchMapServer Página 50 Capítulo III Análisis y diseño 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. uc RecibirPeticionHTTP Recibir petición HTTP Serv idor Figura 3-21 Diagrama de caso de uso: CU4 Recibir petición HTTP act RecibirPeticionHTTP Inicio Ej ecutar aplicación Web SketchMapServ er No Servidor Web ejecutandose Si Esperar peticiones HTTP Excepción Recibir petición HTTP No Petición correcta Si Fin 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 ID: Nombre: Actores: Descripción: Precondiciones: CU4 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-22. Recibir petición HTTP Servidor. Recibe una petición HTTP. 1. Servidor de aplicaciones ejecutándose. Página 51 Capítulo III Análisis y diseño Poscondiciones: Escenario de éxito Escenario de fracaso Escenario de fracaso 1. 2. 3. 4. 1. 2. 3. 4. 1. 2. 3. 4. 5. 6. Se ejecuta la aplicación web SketchMapServer. Se esperan peticiones HTTP. Se reciben las peticiones HTTP Terminar proceso. Se ejecuta la aplicación web SketchMapServer. Error al ejecutar la aplicación. Se lanza excepción. Terminar proceso. Se ejecuta la aplicación web SketchMapServer. Se esperan peticiones HTTP Se reciben las peticiones HTTP. Error en la recepción de la petición. Se lanza excepción. 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. uc InterpretarPeticionHTTP Interpretar petición HTTP Serv idor 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 ID: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito Escenario de fracaso Escenario de fracaso CU5 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-24. Interpretar petición HTTP Servidor. Interpreta una petición HTTP. 1. Petición HTTP recibida 1. 2. 3. 4. 1. 2. 3. 4. 1. 2. 3. 4. Se obtiene la petición HTTP Se lee la petición HTTP. Se obtienen los datos. Terminar proceso. Se obtiene la petición HTTP Error al obtener la petición. Se lanza excepción. Terminar proceso. Se obtiene la petición HTTP Se lee la petición HTTP. La petición no es válida. Se lanza excepción. Página 52 Capítulo III Análisis y diseño 5. Terminar proceso. Suposiciones: act InterpretarPeticionHTTP Inicio Obtener petición HTTP No Excepción Petición correct a Si No Trama válida Leer petición Si Obtener datos Fin 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 ID: Nombre: CU6.1 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-26. Obtener perfil del dispositivo móvil. Página 53 Capítulo III Análisis y diseño Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito Escenario de fracaso Escenario de fracaso Servidor. Obtener perfil del dispositivo móvil. 1. Petición HTTP interpretada 1. 2. 3. 4. 5. 1. 2. 3. 4. 1. 2. 3. 4. 5. Se abre conexión a postgres. Se consulta compatibilidad del dispositivo móvil. Se obtiene el perfil del dispositivo móvil. Se cierra la conexión a postgres. Terminar proceso. Se abre conexión a postgres. Error: conexión a postgres cerrada. Se lanza excepción. Terminar proceso. Se abre conexión a postgres. Se consulta compatibilidad del dispositivo móvil. No existe compatibilidad con la aplicación. Se lanza excepción. Terminar proceso. Incluye: Suposiciones: act ObtenerPerfilDispositi... Inicio Abrir conexión postgres No Conexión abierta Si Excepción Consultar dispositiv o móv il Si No Encontrado Obtener perfil del dispositiv o móv il Cerrar conexión postgres Fin 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. Página 54 Capítulo III Análisis y diseño 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: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito 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. Obtener mapa SVG. Servidor. Obtener el mapa imagen SVG del servidor de mapas. 1. Tener el tamaño del mapa de acuerdo al perfil del dispositivo móvil. 1. 2. 3. Escenario de fracaso Escenario de fracaso 4. 5. 1. 2. 3. 5. 1. 2. 3. 4. 5. Se abre conexión a postgis. Se obtiene el BBOX mediante consultas a Postgis coordenadas georeferenciales origen. Se realiza una petición WMS al servidor de mapas con los dispositivo móvil y el BBOX. Se obtiene el mapa SVG del servidor de mapas. Terminar proceso. Se abre conexión a Postgis. Error: conexión a Postgis cerrada. Se lanza excepción. Terminar proceso. Se abre conexión a Postgis. Se obtiene el BBOX mediante consultas a Postgis coordenadas georeferenciales origen. Se realiza una petición WMS al servidor de mapas con los dispositivo móvil y el BBOX. El servidor de mapas no está ejecutándose. Se lanza excepción mediante las parámetros del mediante las parámetros del Página 55 Capítulo III Análisis y diseño 6. Terminar proceso. Incluye: Suposiciones: act ObtenerMapaSVG Inicio Abrir conexión postgis No Conexión correct a Si Obtener BBOX consultado a la BDE mediante las coordenadas georeferenciales Excepción Realizar petición WMS al serv idor de mapas con los parámetros del dispositiv o móv il y el BBOX No Servidor de Mapas activo No Obtener Mapa SVG Fin 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 ID: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito CU6.2.2 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-29. Convertir SVG a SVGTiny. Servidor. Se realiza la conversión de la imagen SVG a SVGTiny. 1. Tener el archivo imagen SVG. 1. 2. 3. 4. 5. Se obtiene la imagen SVG. Se crea un objeto SAX para lectura. Se obtiene el elemento root y la lista de sus propiedades. Se crea el elemento root del SVGTiny y el namespace 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: Página 56 Capítulo III Análisis y diseño act Conv ertirSVGaSVGT Inicio Crear obj eto SAX de lectura Obtener imagen SVG Obtener el elemento root y la lista de sus propiedades El Namespace es http://www.w3.org/2000/svg. Namespace de referencias es http://www.w3.org/1999/xlink Crear elemento root del SVGT y su Namespace Leer atributo del elemento root SVG 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 Agregar atributo leído del SVG al elemento root SVGT Agregar atributos v ersion, No baseProfile y v iew Box a la imagen SVGT Si Existe otro atributo Obtener los elemetos hij os del elemento root del SVG Si Leer elemento hij o del SVG y agregarlo al elemento hij o del SVGT Existen elementos hijos SVG No Crear documento y su DocType Agregar docType y el elemento rootSVGT al documento Agregar elemento hij o SVGT al elemento root SVGT Fin 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 ID: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito CU6.2.3 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-30. Generar ruta. Servidor. Generar ruta a partir de una red de calles contenida en la base de datos espacial. 1. Tener los puntos georeferenciales origen y destino. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Ingresar grafo G, nodo origen y el nodo destino. Construir arreglo de tamaño del total de nodos contenidos en G. Iniciar valores del arreglo, D[nodo_inicial] =0, el resto -1. Posicionarse en el primer vértice asumiendo a Di como ruta mínima. Existe al menos un nodo adyacente Di > (Da + distancia (a, vi)). Di = Da + distancia (a, vi). Repetir desde el punto 5 hasta encontrar la ruta hacia el nodo final. Guardar ruta generada. Terminar proceso. Página 57 Capítulo III Análisis y diseño Escenario de fracaso 1. 2. 3. 4. 5. 6. 7. 8. Ingresar grafo G, nodo origen y el nodo destino. Construir arreglo de tamaño del total de nodos contenidos en G. Iniciar valores del arreglo, D[nodo_inicial] =0, el resto -1. Posicionarse en el primer vértice asumiendo a Di como ruta mínima. Existe al menos un nodo adyacente No existe nodo adyacente. Lanzar excepción Terminar proceso. Incluye: Suposiciones: act GenerarRuta Inicio Construir arreglo del número total de elementos del grafo Ingresar grafo G, nodo origen y destino Se asume Di al v ertice 1 como ruta mínima No Excepción Exist e nodo adyacente Vi Si Si Di >(Da+distancia(a, vi)) Di = Da + distancia(a, v i) No Da es nodo final No Si Obtener ruta generada Fin 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 ID: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito CU6.2.4 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-31. Obtener puntos de referencia. Servidor. Generar los puntos de referencia de cada nodo que se obtiene de la ruta generada. 1. Tener una ruta generada. 1. 2. 3. 4. Abrir conexión Postgis. Consultar a la BDE areas radiales en base a las coordenadas georeferenciales de cada nodo de la ruta generada Obtener datos del punto de referencia. Obtener puntos de referencia. Página 58 Capítulo III Análisis y diseño Escenario de fracaso Escenario de fracaso 5. 1. 2. 3. 4. 1. 2. 3. 4. 5. Terminar proceso Abrir conexión Postgis. La conexión no se establece correctamente. Lanzar excepción. Terminar proceso. Abrir conexión Postgis. Consultar a la BDE areas radiales en base a las coordenadas georeferenciales de cada nodo de la ruta generada No existe Punto de interés. Lanzar excepción. Terminar proceso. Incluye: Suposiciones: act ObtenerPuntosReferencia Inicio Abrir conexión postgis No Conexión correcta Excepción Si Consultar a la BDE areas radiales en base a las coordenadas georeferenciales de cada nodo de la ruta generada Exist en Puntos de interés Si Obtener datos del punto de referencia No Existe otro punt o de referencia Si No Obtener los puntos de referencia Fin 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 ID: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito CU6.2.5 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-32. Agregar datos al SVGTiny Servidor. Agregar datos a las capas del archivo SVGTiny 1. Conversión del SVG a SVGTiny. 2. Ruta generada. 3. Puntos de referencia obtenidos. Mapa croquis generado 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. Página 59 Capítulo III Análisis y diseño 5. 6. 7. 8. 9. 10. 11. 12. Validar ruta. Leer puntos de la ruta. Agregar los elementos línea al SVGTiny. Leer punto de referencia Validar punto de referencia Obtener puntos de referencia. Agregar elemento punto y texto al SVGTiny 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 60 Capítulo III Análisis y diseño 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. uc Env iarSVGT Env iar mapa SV GT Serv idor Figura 3-33 Diagrama de caso de uso: CU7 Enviar mapa SVGTiny act Env iarMapaSVGT Inicio Crear fluj o de salida de datos No Excepción Flujo de salida abierto Env iar mapa SVGT No SVGT enviado Fin 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 ID: Nombre: Actores: Descripción: Precondiciones: Poscondiciones: Escenario de éxito Escenario de fracaso Escenario de fracaso CU7 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 3-34. Enviar mapa SVGTiny. Servidor. Envía el mapa SVGTiny en respuesta a la petición HTTP realizada. 1. Mapa SVGTiny generado 1. 2. 3. 1. 2. 3. 4. 1. 2. 3. 4. Crear flujo de salida de datos. Enviar mapa SVGTiny. Terminar proceso Crear flujo de salida de datos. Error al crear el flujo de salida de datos. Se lanza excepción. Terminar proceso Crear flujo de salida de datos. Enviar mapa SVGTiny. SVGTiny no enviado. Se lanza excepción. Página 61 Capítulo III Análisis y diseño 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 62 Capítulo III Análisis y diseño 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 63 Capítulo III Análisis y diseño 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 64 Capítulo III Análisis y diseño pkg maps DataPointOfInteres t DataWebMapServ ice MapPOR + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + DataPointOfInterest() + DataWebMapService() + calculateDistance(ArrayList<String>) : void getCode() : ArrayList<String> + getQueryString() : String + createPORLayer(DataMapRoute, PoiGeoreferenciado, DataPointOfInterest) : boolean getCode(int) : String + getRequest() : String + getDistance() : double getDescription() : ArrayList<String> + setArchivo() : void + getPOR() : String getDescription(int) : String + setBBox(String) : void + MapPOR() getDistance() : ArrayList<String> + setBGColor(String) : void -mpDAO getDistance(int) : String + setFormat(String) : void getEstado() : String + setHeight(String) : void MapPORDAO getIdestado() : int + setLayers(String) : void getIdmunicipio() : int + setRequest(String) : void getMunicipio() : String + iniVarPOIs(int) : void + setStyles(String) : void getNameService() : ArrayList<String> + MapPORDAO() + setTransparent(String) : void getNameService(int) : String + numeroPOIs(Connection, String) : int + setUrl(String) : void getNumber() : ArrayList<String> + obtenerPOIs(PoiGeoreferenciado, DataPointOfInterest, ArrayList<String>) : void + setVersion(String) : void getNumber(int) : String + setWidth(String) : void getNumReg() : int «property get» PointOfInterestDAO getStreet() : ArrayList<String> + getBBOX() : String getStreet(int) : String + getBGCOLOR() : String getXPoint() : ArrayList<String> + getFORMAT() : String + getDataPointOfInterest() : DataPointOfInterest getXPoint(int) : double -dpoi + getHEIGHT() : int + PointOfInterestDAO() getYPoint() : ArrayList<String> + getLAYERS() : String + printData() : void getYPoint(int) : double -dwms + getREQUEST() : String + SearchPointOfInterest(String, String, PoiGeoreferenciado) : void resetVar() : void + getSRS() : String setCode(int, String) : void + getSTYLES() : String setCode(String) : void + getTRANSPARENT() : boolean MapRouteDAO setDescription(int, String) : void + getURL() : String setDescription(String) : void + getVERSION() : String setDistance(int, String) : void + getWIDTH() : int + addNode(int, double, double) : void setDistance(String) : void + datosGrafo(int, String) : void «property set» setEstado(String) : void + extraerPuntos(String) : String + setSRS(String) : void setIdestado(int) : void + findStreetNear(double, double) : int setIdmunicipio(int) : void + generatingGraph() : void setMunicipio(String) : void + getDistanceE2Points(String, String, String) : double[] setNameService(int, String) : void MapImage + getGeomEdge(int) : String setNameService(String) : void + getGeomInverseEdge(int) : String setNumber(int, String) : void + getGrafo() : double[] + generateMap(DataMobileDevice, String) : void setNumber(String) : void + getNaristas() : int + getDirImgSVG() : String setNumReg(int) : void + getNodo(int) : Point + getExtensionFile(String) : String setStreet(int, String) : void + getNumberNodes() : int + getFileInputStreamMap() : InputStream setStreet(String) : void + getPDestino() : int + getImageName() : String setXPoint(int, String) : void + getPfX(int) : double + getWMS() : DataWebMapService setXPoint(String) : void + getPfY(int) : double + imageName() : String setYPoint(int, String) : void + getPiX(int) : double + MapImage() setYPoint(String) : void + getPiY(int) : double «property get» + getPointInitial_Final(String) : String[] DataMapRoute + getPoint() : ArrayList<String> + getPOrigen() : int + getPoint(int) : String «property set» + setPoint(int, String) : void + setPoint(String) : void 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 + + + + + + + + + + + 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 + + + + + + + + + + + + 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 MapRoute + + + + -dmr createRouteLayer(PoiGeoreferenciado, DataMobileDevice, double, double, String) : void getDataMapRoute() : DataMapRoute getRouteGeospatial() : String MapRoute() Figura 3-38 Diagrama de clases del paquete mx.edu.cenidet.gateway.maps Las clases que conforman el paquete son las siguientes: 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. Página 65 Capítulo III Análisis y diseño 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 66 Capítulo III Análisis y diseño 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 67 Capítulo III Análisis y diseño pkg Coordinates CoordenadasUTM + + + + + + + CoordenadasUTM() getCoordenadaX() : double + getCoordenadaY() : double + getZona() : double + -cUTM 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 CoordenadasGeoreferenciale s + + + -cg + + + + 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 Figura 3-41 Diagrama de clases del paquete mx.edu.cenidet.gateway.maps.coordinates Las clases que conforman el paquete son las siguientes: 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). Página 68 Capítulo III Análisis y diseño 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 Las clases que conforman el paquete son las siguientes: 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 69 Capítulo III Análisis y diseño 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. 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 -dmd + + + + + + + getDataMobileDevice() : DataMobileDevice main(String[]) : void MobileDeviceDAO() MobileDevices() : ArrayList<DataMobileDevice> printData() : void printDataMobileDevice(ArrayList<DataMobileDevice>, int) : void SearchMobileDevice(String, String) : boolean Figura 3-45 Diagrama de clases del paquete mx.edu.cenidet.edu.gateway.mobiledevice Las clases que conforman el paquete son las siguientes: 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. Página 70 Capítulo III Análisis y diseño 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 71 Capítulo III Análisis y diseño 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 72 Capítulo III Análisis y diseño pkg s... SV GToSV GT + + + + + + + convertSVGtoSVGT() : void createFileSVGT(Document, String) : void getDocumentResult() : Document printScreen(Document) : void setFile(FileInputStream) : void setFile(InputStream) : void SVGToSVGT() 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) : Vect or printScreen(Document) : void Arrow Direction + + + + + ArrowDirection() calculaAngulo() : double calculaDistancia(float, float, float, float) : double calculaPuntoMedio() : double[] setLinea(float, float, float, float) : void 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 Página 73 Capítulo III Análisis y diseño 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 74 Capítulo III Análisis y diseño 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 DeviceMine v3.0 DeviceAtlas Wurl Características del dispositivo móvil Sí Sí Sí Licencia Sí 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 75 Capítulo III Análisis y diseño 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. product_info FK_MOBILE_D_REFERENCE_PRODUCT_ id character varying(50) is_transcoder boolean mobile_browser character varying(200) has_pointing_device boolean device_os character varying(200) FK_MOBILE_D_REFERENCE_J2ME nokia_series double precision has_qwerty_keyboard boolean pointing_method character varying(150) mobile_browser_version character varying(150) nokia_edition double precision uaprof character varying(200) can_skip_aligned_link_row boolean mobile_device device_claims_web_support boolean id SERIAL <pk> ununiqueness_handler character varying(150) phone_number character varying(10) model_name character varying(200) product_info brand character varying(150) FK_MOBILE_D_REFERENCE_PRODUCT_ device_os_version character varying(150) model character varying(150) id character varying(50) uaprof2 character varying(200) id_device character varying(50) is_transcoder boolean is_wireless_device boolean mobile_browser character varying(200) uaprof3 character varying(200) FK_MOBILE_D_REFERENCE_SMS has_pointing_device boolean brand_name character varying(150) device_os character model_extra_info character varying(200) varying(150) FK_MOBILE_D_REFERENCE_J2ME nokia_series double precision marketing_name character varying(150) FK_MOBILE_D_REFERENCE_IMAGE_FO has_qwerty_keyboard boolean release_date character varying(150) pointing_method character unique boolean varying(150) mobile_browser_version character varying(150) nokia_edition double precision display uaprof character varying(200) id can_skip_aligned_link_row character varying(50) boolean mobile_device FK_MOBILE_D_REFERENCE_DISPLAY columns double boolean precision device_claims_web_support id SERIAL <pk> rows precision varying(150) ununiqueness_handlerdouble character phone_number character varying(10) max_image_width double precision model_name character varying(200) brand character varying(150) resolution_height double character precision varying(150) device_os_version image_format model character varying(150) resolution_width double character precision varying(200) uaprof2 character varying(50) max_image_height double boolean precision id id_device character varying(50) is_wireless_device physical_screen_height double character precision varying(200) greyscale boolean uaprof3 FK_MOBILE_D_REFERENCE_SMS physical_screen_width double precision jpg boolean brand_name character varying(150) gif boolean model_extra_info character varying(150) transparent_png_index boolean marketing_name character varying(150) mms epoc_bmp boolean FK_MOBILE_D_REFERENCE_IMAGE_FO release_date character varying(150) bmp boolean id unique character boolean varying(50) wbmp boolean mms_3gpp boolean gif_animated boolean mms_wbxml boolean colors integer mms_symbian_installdisplay boolean svgt_1_1_plus boolean mms_png boolean id character varying(50) svgt_1_1 boolean mms_max_size double precision FK_MOBILE_D_REFERENCE_DISPLAY columns double precision transparent_png_alpha boolean mms_rmf boolean rows double precision png boolean mms_nokia_operatorlogo boolean max_image_width double precision tiff boolean mms_max_width double precision resolution_height double precision mms_max_frame_rate double precision image_format resolution_width double precision FK_MOBILE_D_REFERENCE_MMS mms_wml boolean max_image_height double precision id character varying(50) mms_evrc boolean physical_screen_height doubleboolean precision greyscale boolean mms_spmidi physical_screen_width doubleboolean precision jpg boolean mms_gif_static gif boolean mms_max_height double precision sms transparent_png_index boolean sender boolean mms epoc_bmp boolean id character varying(50) mms_video boolean bmp boolean ems boolean mms_vcard boolean id character varying(50) text_imelody boolean wbmp boolean mms_nokia_3dscreensaver boolean mms_3gpp boolean nokiaring boolean gif_animated boolean mms_qcelp boolean mms_wbxml boolean siemens_logo_height double precision mms_midi_polyphonic boolean colors integer mms_symbian_install boolean ems_variablesizedpictures boolean mms_wav boolean svgt_1_1_plus boolean mms_png boolean sckl_groupgraphic boolean mms_jpeg_progressive booleanprecision svgt_1_1 boolean mms_max_size double siemens_ota boolean mms_jad boolean transparent_png_alpha boolean mms_rmf boolean sagem_v1 boolean mms_nokia_ringingtone boolean png boolean mms_nokia_operatorlogo boolean largeoperatorlogo boolean built_in_recorder booleanprecision tiff boolean mms_max_width double sagem_v2 boolean mms_midi_monophonic boolean mms_max_frame_rate double precision ems_version double precision mms_3gpp2 boolean FK_MOBILE_D_REFERENCE_MMS mms_wml boolean ems_odi boolean mms_wmlc boolean mms_evrc boolean nokiavcal boolean mms_nokia_wallpaper boolean mms_spmidi boolean operatorlogo boolean mms_bmp boolean mms_gif_static boolean siemens_logo_width double precision mms_vcalendar boolean mms_max_height double precision ems_imelody mms_jar boolean sms boolean sender boolean sckl_vcard boolean mms_ota_bitmap boolean id character varying(50) mms_video boolean siemens_screensaver_width double precision mms_mp3 boolean ems boolean mms_vcard boolean sckl_operatorlogo boolean mms_mmf boolean text_imelody boolean mms_nokia_3dscreensaver boolean panasonic boolean mms_amr boolean nokiaring boolean mms_qcelp boolean ems_upi boolean mms_wbmp boolean siemens_logo_height double mms_midi_polyphonic boolean nokiavcard booleanprecision built_in_camera boolean ems_variablesizedpictures boolean mms_wav boolean callericon receiver sckl_groupgraphic boolean mms_jpeg_progressive boolean gprtf mms_mp4 siemens_ota siemens_screensaver_height boolean double precision mms_jad boolean mms_xmf sagem_v1 boolean sckl_ringtone mms_nokia_ringingtone boolean mms_jpeg_baseline picturemessage largeoperatorlogo boolean mms_midi_polyphonic_voices boolean double precision built_in_recorder sckl_vcalendar sagem_v2 boolean mms_gif_animated mms_midi_monophonic boolean ems_version double precision mms_3gpp2 boolean ems_odi boolean mms_wmlc boolean nokiavcal boolean mms_nokia_wallpaper boolean operatorlogo boolean mms_bmp boolean siemens_logo_width double precision mms_vcalendar boolean ems_imelody boolean mms_jar boolean sckl_vcard boolean mms_ota_bitmap boolean siemens_screensaver_width double precision mms_mp3 boolean sckl_operatorlogo boolean mms_mmf boolean panasonic boolean mms_amr boolean ems_upi boolean mms_wbmp boolean nokiavcard boolean built_in_camera boolean callericon boolean receiver boolean gprtf boolean mms_mp4 boolean siemens_screensaver_height double precision mms_xmf boolean sckl_ringtone boolean mms_jpeg_baseline boolean picturemessage boolean mms_midi_polyphonic_voices double precision sckl_vcalendar boolean mms_gif_animated 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 j2me_jpg id j2me_return_key_code doja_1_5 j2me_real8 j2me_datefield_broken j2me_max_record_store_size j2me_clear_key_code j2me_realmedia j2me_right_softkey_code j2me_midp_1_0 j2me_heap_size j2me_bmp3 j2me_canvas_width j2me_midi j2me_btapi j2me_loctapi j2me_siemens_extension j2me_motorola_lwt j2me_h263 doja_3_5 j2me_audio_capture_enabled j2me_wbmp j2me_midp_2_0 j2me_rmf j2me_datefield_no_accepts_null_date j2me_wma j2me_aac j2me_left_softkey_code j2me_capture_image_formats j2me_jtwi j2me_select_key_code j2me_jpg j2me_xmf j2me_return_key_code j2me_photo_capture_enabled j2me_real8 j2me_realaudio j2me_max_record_store_size j2me_realvideo j2me_realmedia j2me_mp3 j2me_midp_1_0 j2me_png j2me_bmp3 j2me_au j2me_midi j2me_screen_width j2me_btapi j2me_mp4 j2me_siemens_extension j2me_mmapi_1_0 j2me_h263 j2me_http j2me_audio_capture_enabled j2me_imelody j2me_midp_2_0 j2me_socket j2me_datefield_no_accepts_null_date j2me_3dapi j2me_aac j2me_bits_per_pixel j2me_capture_image_formats j2me_mmapi_1_1 j2me_select_key_code j2me_udp j2me_xmf j2me_wav j2me_middle_softkey_code j2me_photo_capture_enabled j2me_svgt j2me_realaudio j2me_gif j2me_realvideo j2me_siemens_color_game j2me_mp3 j2me_max_jar_size j2me_png j2me_wmapi_1_0 j2me_au j2me_nokia_ui j2me_screen_width j2me_screen_height j2me_mp4 j2me_wmapi_1_1 j2me_mmapi_1_0 j2me_wmapi_2_0 j2me_http doja_1_0 j2me_imelody j2me_serial j2me_socket doja_2_0 j2me_3dapi j2me_bmp j2me_bits_per_pixel j2me_amr j2me_mmapi_1_1 j2me_gif89a j2me_udp j2me_cldc_1_0 j2me_wav doja_2_1 j2me_middle_softkey_code doja_3_0 j2me_svgt j2me_cldc_1_1 j2me_gif doja_2_2 j2me_siemens_color_game doja_4_0 j2me_max_jar_size j2me_3gpp j2me_wmapi_1_0 j2me_video_capture_enabled j2me_nokia_ui j2me_canvas_height j2me_screen_height j2me_https j2me_mpeg4 j2me_wmapi_1_1 j2me_storage_size 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 Figura 3-51 Diagrama relacional de la base de datos MobileDevice character varying(50) boolean boolean double precision double precision double precision double precision boolean boolean boolean boolean boolean boolean double precision boolean boolean character varying(50) double precision boolean boolean boolean double precision double booleanprecision double booleanprecision double booleanprecision double booleanprecision boolean boolean boolean boolean boolean boolean boolean boolean booleanprecision double character varying(50) boolean double precision boolean boolean double precision boolean boolean boolean double precision boolean boolean boolean boolean boolean boolean boolean boolean double precision boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean double precision character boolean varying(50) double booleanprecision boolean double precision boolean boolean boolean boolean boolean double precision boolean boolean boolean booleanprecision double double precision boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean double precision boolean boolean boolean boolean boolean boolean boolean double booleanprecision boolean boolean boolean boolean boolean boolean double booleanprecision boolean boolean double precision double booleanprecision boolean double precision boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean boolean double precision boolean boolean double precision Página 76 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 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 package mx.edu.cenidet.gateway.servlets; public class servletSketchMap extends HttpServlet { String categoria, mapa,distancia, longitud, latitud,trama; String user, password; RegistroUsuarioDAO regUser; PrintWriter out; protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType(“text/html;charset=UTF-8”); out = response.getWriter(); Document doc = new Document(); Main croquis = new Main(); try { trama = request.getParameter(“trama”); user = request.getParameter(“user”); password = request.getParameter(“password”); regUser = new RegistroUsuarioDAO(); if(regUser.BuscarUsuario(user, password)){ croquis.generateSketchMap(trama); if(croquis.getDataPointOfInterest().getNumReg()>0){ doc = croquis.getMap(); }else{ //Error } } }catch(Exception e){ e.printStackTrace(); }finally { Página 78 Capítulo IV Implementación 33 34 35 36 37 38 39 40 41 error(croquis); out.close(); } } protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { processRequest(request, response); } } 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 public class Main { public Main(){} public void generateSketchMap(String trama){ message = new Mensaje(); try { //Recibir e interpretar Mensaje message.RecibeTrama(trama); poi = new PoiGeoreferenciado(); poi = message.LeeGeoSiguiente(); printMessage(trama); md = new MobileDeviceDAO(); if (md.SearchMobileDevice(“Nokia”, “N96”)==true){ //Empieza el proceso de generación del mapa SVGTiny } … } catch (MensajeExcepcion ex) { System.out.println(“La trama no es la correcta!”); } } 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 79 Capítulo IV Implementación { 2 public Connection getConexionPostgres() 3 { 4 if(conPostgres != null) 5 return conPostgres; 6 url = “jdbc:postgresql://” + servidor + “:” + puerto + “/” + bdMobile; 7 try{ 8 Class.forName(“org.postgresql.Driver”); 9 conPostgres = DriverManager.getConnection(url, usuario, password); 10 return conPostgres; 11 } 12 catch(Exception exception){ 13 System.out.println(“Error al conectarse: “ + exception.toString()); 14 } 15 return null; 16 } 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 import java.io.PrintStream; import java.sql.*; public class Postgis { public Connection getConexionPostGIS() { if(conPostGIS != null) return conPostGIS; url = “jdbc:postgresql://” + servidor + “:” + puerto + “/” + baseDatos; try{ Class.forName(“org.postgresql.Driver”); conPostGIS = DriverManager.getConnection (url, usuario, password); ((org.postgresql.PGConnection)conPostGIS).addDataType(“geometry”, “org.postgis.PGgeometry”); ((org.postgresql.PGConnection)conPostGIS).addDataType(“box3d”,”org.postgis.PGbox3d”); return conPostGIS; } catch(Exception exception){ System.out.println(“Error al conectarse: “ + exception.toString()); } return null; } } 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 80 Capítulo IV Implementación 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 import java.io.InputStream; import java.sql.Connection; … public class generarMapaCroquis { … public datosPuntoFinal buscandoDestinos() { //Se realiza la conexion a Postgis Postgis pg = new Postgis(); pg.Inicializar(); Connection cn = pg.getConexionPostGIS(); //Se crea el objeto para realizar consultas a la base de datos cbd = new consultaBaseDatos(); //Se crea el objeto que contendrá los puntos destinos dpf = new datosPuntoFinal(); //Se identifica la ciudad y el estado a ubicar el punto destino if (cbd.buscarIdCiudad(cn, estado, municipio)){ dpf = cbd.buscarPuntoFinal(cn, dpf, dm); } return dpf; } … } 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 public class MobileDeviceDAO { public boolean SearchMobileDevice(String brand, String model){ dmd = new DataMobileDevice(); postgres conexion = new postgres(); …. if(cn != null){ try{ Statement s = cn.createStatement(); 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 FROM = “FROM display as d, product_info as pi, j2me as j, mms as m”; WHERE = “WHERE pi.model_name=‟” + model + “‟ “ + “AND pi.brand_name=‟” + brand + “‟ “ + “AND pi.id=d.id “+ Página 81 Capítulo IV Implementación 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 “AND m.id=pi.id “+ “AND j.id=pi.id “+ “AND m.receiver=‟t‟ “+ “AND j.j2me_midp_2_0=‟t‟ “+ “AND j.j2me_cldc_1_1=‟t‟”; strSQL = SELECT + “ “ + FROM + “ “ + WHERE; ResultSet rs = s.executeQuery(strSQL); rs.next(); dmd.setIdDevice(rs.getString(1)); dmd.setBrand(rs.getString(2)); dmd.setModel(rs.getString(3)); dmd.setWidth(rs.getInt(4)); dmd.setHeight(rs.getInt(5)); dmd.setHeightResolution(rs.getString(6)); dmd.setWidthResolution(rs.getString(7)); dmd.setWidthDisplay(rs.getString(8)); dmd.setHeightDisplay(rs.getString(9)); dmd.setTypeBrowser(rs.getString(10)); dmd.setVersionTypeBrowser(rs.getString(11)); dmd.setSystem(rs.getString(12)); dmd.setRelease(rs.getString(13)); dmd.setReceiveMMS(rs.getString(14)); dmd.setSendMMS(rs.getString(15)); dmd.setSizeMaxMMS(rs.getString(16)); dmd.setMIDP_2_0(rs.getString(17)); dmd.setCLDC_1_1(rs.getString(18)); if (dmd.getIdDevice().length()>0){ found=true; }else found = false; } catch (SQLException sqlexception){ found=false; } } return found; } 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 2 3 4 5 public void SearchPointOfInterest(String state, String city, PoiGeoreferenciado poi){ //Se realiza la conexion a Postgis postgis pg = new postgis(); if(foundCity==true){ Página 82 Capítulo IV Implementación try{ 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”; FROM = “FROM servicios As s, categoria As c, colonia As col”; 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”; strSQL = SELECT + “ “ + FROM + “ “ + WHERE; ResultSet rs1 = s.executeQuery(strSQL); 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 for (int i=0; i<dpoi.getNumReg();i++){ rs1.next(); dpoi.setPoint(rs1.getString(1)); dpoi.setXPoint(rs1.getString(2)); dpoi.setYPoint(rs1.getString(3)); dpoi.setDistance(rs1.getString(4)); dpoi.setNameService(rs1.getString(5)); dpoi.setDescription(rs1.getString(6)); dpoi.setStreet(rs1.getString(7)); dpoi.setNumber(rs1.getString(8)); dpoi.setCode(rs1.getString(9)); } dpoi.setEstado(state); dpoi.setMunicipio(city); } }catch(SQLException sqlexception){} } } 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 2 3 4 5 6 7 8 public void obtenerPOIs(PoiGeoreferenciado poi, DataPointOfInterest dpoi,ArrayList<String> pois){ try { Postgis pg = new Postgis(); Connection c = pg.getConexionPostGIS(); … for(int i=0;i<cont;i++){ Página 83 Capítulo IV Implementación String p[] = pois.get(i).split(“ “); 9 10 11 12 13 14 15 16 double longitudPOI = Double.parseDouble(p[0]); double latitudPOI = Double.parseDouble(p[1]); //Obteniendo los puntos de referencia Statement stRPG = c.createStatement(); 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 “; FROM =”FROM servicios as s, colonia as c “; 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”; strSQL = SELECT + “ “ + FROM + “ “ + WHERE; ResultSet rsRPG = stRPG.executeQuery(strSQL); 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 boolean ban=false; while(rsRPG.next()){ if(numPReferencia>0){ String aux=””; aux=rsRPG.getString(6); //Eliminando puntos de referencias existentes for(int m=0;m<numPReferencia;m++){ if(aux.equals(points[m] )){ ban=true; } } } if(ban==false){ servicio[numPReferencia] = rsRPG.getString(1); calle[numPReferencia] = rsRPG.getString(2); numero[numPReferencia] = rsRPG.getString(3); descripcion[numPReferencia] = rsRPG.getString(4); distancia[numPReferencia] = rsRPG.getString(5); points[numPReferencia] = rsRPG.getString(6); idcategoria[numPReferencia] = rsRPG.getString(7); numPReferencia++; } } } } catch (SQLException ex) {} } 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 84 Capítulo IV Implementación 2. 3. 4. 5. 6. Conversión del archivo SVG a SVGTiny Obtención de la ruta Obtención de los puntos de referencia Convertir las coordenadas georeferenciales a pixeles 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 package mx.edu.cenidet.gateway.mmsserver; public class Main { public Main(){} public void generateSketchMap(String trama){ message = new Mensaje(); try { …. if(dpoi.getNumReg()>0){ // Generar el área de búsqueda BBOX …. dmi.setGeoPOI(poi.LeeDistancia()); dmi.printBBOX(); // 1. Obtener el mapa imagen svg mi = new MapImage(); mi.generateMap(md.getDataMobileDevice(),dmi.getBBOX()); dwms = mi.getWMS(); // 2. Conversion de svg a svgt svgt = convertSVGT(mi.getFileInputStreamMap()); for(int i=0; i< dpoi.getNumReg();i++){ // 3. Obtener ruta de los puntos de interes mr = new MapRoute(); DataPointOfInterest DatoPOI = poiDAO.getDataPointOfInterest(); mr.createRouteLayer(poi,md.getDataMobileDevice(), DatoPOI.getXPoint(i), DatoPOI.getYPoint(i), dmi.getBOX3D()); dmr = mr.getDataMapRoute(); route = mr.getRouteGeospatial(); // 4. Obtener Puntos de Referencia mPOR = new MapPOR(); //Existen punntos de referenca? if(mPOR.createPORLayer(mr.getDataMapRoute(),poi,poiDAO.getDataPointOfInterest())){ numLayer = numLayer+1; POR = mPOR.getPOR(); dmr.setPORGeoespatial(POR); dmr.PORGeoespatial(dmd, dmi.getBOX3D()); // 5. Convertir las coordenadas georefenciales a pixeles dmr.setRouteGeoespatial(getRouteGeospatial()); String ruta = dmr.convertGeoRefToPixel(dmd, dmi.getBOX3D()); dmr.setPORGeoespatial(getPOR()); Página 85 Capítulo IV Implementación 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 String por = dmr.PORGeoespatial(dmd, dmi.getBOX3D()); // 6. Anadir los datos al svgt if(numLayer==1){ addOrigenToMap(svgt,Double.parseDouble(poi.LeeLongitudG()), Double.parseDouble(poi.LeeLatitudG()), “Origen”); } addDestinityToMap(svgt, DatoPOI.getXPoint(i), DatoPOI.getYPoint(i), DatoPOI.getNameService(i),numLayer); addLayer(svgt,ruta, por,numLayer, mPOR.getDistance()); }else{ //No existen puntos de referencia para esta capa } ….. } catch (MensajeExcepcion ex) { System.out.println(“La trama no es la correcta!”); } } 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 public class DataMapImage { public DataMapImage(){} public void setGeoPOI(DataPointOfInterest dpoi){ ArrayList<Double> x = new ArrayList<Double>(); ArrayList<Double> y = new ArrayList<Double>(); ….. for(int i=0; i < dpoi.getNumReg(); i++){ x.add(dpoi.getXPoint(i)); y.add(dpoi.getYPoint(i)); } for(int i=0; i < x.size()-1; i++){ if(x.get(i) < x.get(i+1) && x.get(i)<xMin){ xMin = x.get(i); }else if(x.get(i+1)<xMin){ 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 86 Capítulo IV Implementación 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 } if(x.get(i) > x.get(i+1) && x.get(i)>xMax){ xMax = x.get(i); }else if(x.get(i+1)>xMax){ xMax = x.get(i+1); } if(y.get(i) < y.get(i+1) && y.get(i)<yMin){ yMin = y.get(i); }else if(y.get(i+1)<yMin){ yMin = y.get(i+1); } if(y.get(i) > y.get(i+1) && y.get(i)>yMax){ yMax = y.get(i); }else if(y.get(i+1)>yMax){ yMax = y.get(i+1); } } xMin=xMin – 0.0010; xMax=xMax + 0.0010; yMin=yMin – 0.0010; yMax=yMax + 0.0010; } public String getBBOX(){ return xMin+”,”+yMin+”,”+xMax+”,”+yMax; } } 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 public class MapImage { public MapImage(){} public void generateMap(DataMobileDevice dmd, String BBOX){ try { URL wmsURL = new URL(dwms.getURL()); wms = new WebMapServer(wmsURL); GetMapRequest gmrq = wms.createGetMapRequest(); gmrq.setFormat(dwms.getFORMAT()); gmrq.setDimensions(dwms.getWIDTH(),dwms.getHEIGHT()); gmrq.setTransparent(dwms.getTRANSPARENT()); gmrq.setSRS(dwms.getSRS()); gmrq.setBBox(dwms.getBBOX()); gmrq.addLayer(dwms.getLAYERS(), dwms.getSTYLES()); Página 87 Capítulo IV Implementación 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 GetMapResponse gmrp = (GetMapResponse) wms.issueRequest(gmrq); Path path = new Path(); String Dir =path.getImagePATH() + NameImage + “.svg”; if (dwms.getFORMAT().equals(“svg”) || dwms.getFORMAT().equals(“svg+xml”) || dwms.getFORMAT().equals(“image/svg+xml”)) { InputStream iss = gmrp.getInputStream(); is=iss; File ff = new File(Dir); FileOutputStream fo = new FileOutputStream(ff); int c = -1; while ((c = iss.read()) != -1) { fo.write©; } fo.close(); } } catch (IOException ex) { System.out.println(“Error: Can‟t proccess the image.”); } catch (ServiceException ex) { System.out.println(“Error: Web Server is down.”); } } 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 2 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 public class SVGToSVGT { public SVGToSVGT(){} public void convertSVGtoSVGT(){ //get element root of SVG file and attributes Element root = documentRead.getRootElement(); List rootAtributes = root.getAttributes(); //Create root SVGT and set the attributes Namespace name = Namespace.getNamespace(“http://www.w3.org/2000/svg”); Element rootSVGT = new Element(“svg”); rootSVGT.setNamespace(name); String width=””, height=””; ….. rootSVGT.setAttribute(“version”, “1.1”); rootSVGT.setAttribute(“baseProfile”, “tiny”); rootSVGT.setAttribute(“viewBox”, “0 0 “+ width +” “+height); Namespace namespace = Namespace.getNamespace(“xlink”,”http://www.w3.org/1999/xlink”); rootSVGT.addNamespaceDeclaration(namespace); //List Children of the root Página 88 Capítulo IV Implementación 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 List rootChildren = root.getChildren(); //Creating children of SVG Element layerMapSVGT = new Element(“g”,name); Element defs = new Element(“defs”,name); …. for(int i=0; i< rootChildren.size();i++){ Element elementChild = (Element) rootChildren.get(i); String rootNameElementChildren = elementChild.getName(); if(rootNameElementChildren.equals(“g”)){ layerMapSVGT.setAttribute(“id”, “capa0”); layerMapSVGT.setAttribute(“display”, “inline”); layerMapSVGT.setAttribute(“stroke”, “black”); List rootElementChildren2 = elementChild.getChildren(); for(int j=0;j<rootElementChildren2.size();j++){ …. List rootElementChildren3 = elementChild2.getChildren(); for(int l =0;l<rootElementChildren3.size();l++){ for(int m=0; m < childAttributes.size();m++){ Attribute attr = (Attribute) childAttributes.get(m); childLayerMap.setAttribute(attr.getName(), attr.getValue()); } childrenLayerMap.addContent(childLayerMap); } layerMapSVGT.addContent(childrenLayerMap); } } } rootSVGT.addContent(defs); rootSVGT.addContent(layerMapSVGT); DocType doctype= new DocType(“svg”,”-//W3C//DTD “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd”); doc=new Document(rootSVGT,doctype); } SVG 1.1 Tiny//EN”, 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 2 3 4 5 6 7 public class MapRoute { public MapRoute(){} public void createRouteLayer(PoiGeoreferenciado poi,DataMobileDevice dmd, double Longitud, double Latitud, String BOX3D){ MapRouteDAO mrDAO = new MapRouteDAO(); //Se obtienes las aristas mrDAO.obtainDBStreet(poi, Longitud, Latitud, BOX3D); Página 89 Capítulo IV Implementación 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 //Se obtienen los nodos mrDAO.obtainDBNodes(poi, Longitud, Latitud, BOX3D); //Detectando nodos finales y generando grafo mrDAO.identifyingFinalNodes(); mrDAO.generatingGraph(); //Ejecutando algoritmo de ruta con el grafo generado AlgoritmoRuta ar = new AlgoritmoRuta(); int n = mrDAO.getNumberNodes(); for(int i = 0; i <= n; i++) { ar.addNodo(new Nodo(“” + i)); } double [][] grafo = mrDAO.getGrafo(); for(int i=0;i<=n;i++) for(int j=0;j<=n;j++){ if(grafo[i][j]!=9999999){ ar.addArista(new Arista(ar.getNodo(i),ar.getNodo(j),grafo[i][j])); } } ArrayList al=ar.obtenerRutaCorta(ar.getNodo(getPOrigen()),ar.getNodo(getPDestino())); layerRuta=”MULTILINESTRING((“; layerRuta=layerRuta+mrDAO.getPuntoI(0)+” “+mrDAO.getPuntoI(1); … layerRuta=layerRuta+”))”; } 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 public class Convert { public void setCoordGeo(double nuevaXMin, double nuevaYMin, double nuevaXMax, nuevaYMax){ // Se rechazan valores iguales de máximo y mínimo. if (nuevaXMin == nuevaXMax) return; if (nuevaYMin == nuevaYMax) return; double // Si los valores de x minimo y máximo están al revés, se guardan dándoles la vuelta. if (nuevaXMin > nuevaXMax){ xMin = nuevaXMax; xMax = nuevaXMin; }else{ xMin = nuevaXMin; xMax = nuevaXMax; } // Si los valores de y minimo y máximo están al revés, se guardan dándoles la vuelta. if (nuevaYMin > nuevaYMax){ Página 90 Capítulo IV Implementación yMin = nuevaYMax; yMax = nuevaYMin; }else{ yMin = nuevaYMin; yMax = nuevaYMax; } 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 } public void setMapa(int nuevoAncho, int nuevoAlto){ // Se rechazan valores de 0 o negativos if (nuevoAncho < 1) return; if (nuevoAlto < 1) return; ancho = nuevoAncho; alto = nuevoAlto; } public int getX (double x){ int xPixel; xPixel = (int)((x - xMin)/(xMax - xMin)*ancho); return xPixel; } public int getY (double y){ int yPixel; yPixel = (int)(alto - (y - yMin)/(yMax - yMin)*alto); return yPixel; } } 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 2 3 4 5 public static void main(String args[]){ Convert c = new Convert(); c.setCoordGeo(-99.22550000000001,18.9042,-99.22269,18.9077); c.setMapa(280, 232); Página 91 Capítulo IV Implementación System.out.println(c.getX(-99.2237)); System.out.println(c.getY(18.90667)); 6 7 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: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 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. public class ElementSVGT { ….. public void dibujarLinea(Document doc,Element element, float x1, float y1, float x2, float y2) { this.doc = doc; Document documento = doc.getDocument(); Element root = (Element) documento.getDocument().getRootElement(); String namespace = root.getNamespaceURI(); try { Element elemento = new Element(“line”,namespace); elemento.setAttribute(“x1”, x1+””); elemento.setAttribute(“y1”, y1+””); elemento.setAttribute(“x2”, x2+””); elemento.setAttribute(“y2”, y2+””); elemento.setAttribute(“stroke-width”, 2.5f+””); elemento.setAttribute(“fill-opacity”, 0.5f+””); elemento.setAttribute(“stroke”, “#0174DF”); element.addContent(elemento); ArrowDirection ad = new ArrowDirection(); ad.setLinea(x1, y1, x2, y2); double distance = ad.calculaDistancia(x1, y1, x2, y2); if(distance>10){ double[] pm = ad.calculaPuntoMedio(); double angulo = ad.calculaAngulo(); Namespace nsXlink = Namespace.getNamespace(“xlink”, “http://www.w3.org/1999/xlink”); Element arrow = new Element(“use”,namespace); arrow.setAttribute(“href”, “#Triangle”,nsXlink); arrow.setAttribute(“transform”,”translate(“+pm[0]+” “+pm[1]+”) rotate(“+angulo+”)”); element.addContent(arrow); } } Página 92 Capítulo IV Implementación 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 52 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 catch(Exception e){ e.printStackTrace(); System.out.println(“Error en dibujarLinea(): “ + e.getMessage()); } } …. public void dibujarPunto(Document doc, Element element, float x, float y, String idPunto, String etiqueta, String idTexto){ this.doc = doc; Element elemento1 = null, elemento2 = null; Document documento = doc.getDocument(); Element root = (Element) documento.getDocument().getRootElement(); String namespace = root.getNamespaceURI(); try { elemento1 = new Element(“circle”, namespace); if(etiqueta != null && !etiqueta.equals(“”)) elemento2 = new Element(“text”,namespace); } catch(Exception e){ e.printStackTrace(); System.out.println(“Error en dibujarPunto(): “ + e.getMessage()); } elemento1.setAttribute(“cx”, x+””); elemento1.setAttribute(“cy”, y+””); elemento1.setAttribute(“r”, 2.0f+””); elemento1.setAttribute(“fill-opacity”, 0.5f+””); elemento1.setAttribute(“stroke-width”, 0.5f+””); elemento1.setAttribute(“fill”, “red”); elemento1.setAttribute(“stroke”, “black”); element.addContent(elemento1); if(etiqueta != null && !etiqueta.equals(“”)) { elemento2.addContent(etiqueta); elemento2.setAttribute(“x”, x+5+””); elemento2.setAttribute(“y”, (y-2)+””); elemento2.setAttribute(“font-size”, 5+””); elemento2.setAttribute(“font-family”, “Verdana”); elemento2.setAttribute(“fill”,”#0A2A0A”); elemento2.setAttribute(“stroke-width”,”0.4”); element.addContent(elemento2); } } ….. } 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 2 3 4 5 6 public void agregarCapa(Document doc, String route, String pois, int numLayer, double distance){ this.doc = doc; Document documento = doc.getDocument(); Element root = (Element) documento.getDocument().getRootElement(); String namespace = root.getNamespaceURI(); cont = cont + 1; Página 93 Capítulo IV Implementación 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 Element element = new Element(“g”,namespace); element.setAttribute(“id”, “capa”+numLayer); …. puntosxy = obtenerPuntos(route); …. try { if(puntosxy.size()%2 == 0) { for(i=0; i<points-1; i++) { … x1 = Float.parseFloat(strX1); y1 = Float.parseFloat(strY1); x2 = Float.parseFloat(strX2); y2 = Float.parseFloat(strY2); dibujarLinea(doc, element, x1, y1, x2, y2); } } puntitos.removeAllElements(); interpretaTrama(pois); int size = puntitos.size()/3; String strEtiq, idPunto, idTexto; indice1 = -1; for(int j =0; j<size; j++) { … idPunto = “Punto” + contador; idTexto = “Texto” + contador; dibujarPunto(doc,element, x1, y1, idPunto, strEtiq, idTexto); contador++; } root.addContent(element); } catch(Exception e){ System.out.println(“Error en agregarCapa(): “ + e.getMessage()); } } 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 SVGTiny 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 2 3 4 5 6 7 8 9 try{ PrintWriter out; Document doc = new Document(); XMLOutputter outXML=new XMLOutputter(Format.getPrettyFormat()); outXML.output(doc,out); System.out.println(“Enviado con éxito!!!”); }catch(Exception e){ e.printStackTrace(); } Figura 4-18 Enviar el mapa SVGT al dispositivo móvil Página 94 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 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 96 Capítulo V Pruebas y resultados 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. Responsable de la prueba: Omar Ríos González Cargo: Autor 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 97 Capítulo V Pruebas y resultados mensaje recibo. En la Figura 5-3 se muestra el mensaje interpretado. Responsable de la prueba: Omar Ríos González Cargo: Autor 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. Responsable de la prueba: Omar Ríos González Cargo: Autor 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 Página 98 Capítulo V Pruebas y resultados 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. Responsable de la prueba: Omar Ríos González Cargo: Autor 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 99 Capítulo V Pruebas y resultados 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. Responsable de la prueba: Omar Ríos González Cargo: Autor 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. Responsable de la prueba: Omar Ríos González Cargo: Autor Página 100 Capítulo V Pruebas y resultados Caso de prueba: SBLAGWMMS-04-01 Crear y enviar el archivo SVGTiny que contiene el mapa croquis SVGTiny mediante HTTP Resultado: OK a b d e c f g 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, Página 101 Capítulo V Pruebas y resultados 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. Responsable de la prueba: Omar Ríos González Cargo: Autor 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 SBLAGWMMS-01 SBLAGWMMS-02 Descripción Resultado Pruebas de Exitoso configuración y conexión Pruebas de recepción Exitoso e interpretación de la información SBLAGWMMS-03 Pruebas de Exitoso generación del mapa SBLAGWMMS-04 Pruebas de envío de Exitoso la información Conclusión La conexión a la base de datos relacional y espacial se realizó de manera correcta. La recepción e interpretación de la información del mensaje son resueltas de manera correcta. Las diferentes capas para generar el mapa se obtuvieron correctamente. El envío y recepción del archivo SVG-Tiny se realiza correctamente mediante conexiones HTTP. Página 102 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 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 104 Capítulo VI Conclusiones 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 105 Capítulo VI Conclusiones 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 SVGTiny, 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 SVGTiny: Página 106 Capítulo VI Conclusiones 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 107 Capítulo VI Conclusiones 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”. Página 108 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 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 111 Anexo A. Análisis para representar puntos de interés 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 112 Anexo A. Análisis para representar puntos de interés 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 113 Anexo A. Análisis para representar puntos de interés Á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 DESCRIPCIÓN C I D T DE DESCRIPCIÓN Comienzo de la ruta Doblar a la izquierda Doblar a la derecha 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 114 Anexo A. Análisis para representar puntos de interés 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 115 Anexo A. Análisis para representar puntos de interés 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 116 Anexo A. Análisis para representar puntos de interés 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). 6. La unión de las rutas en línea indicadoras (sentido de las calles) y la representación de los puntos de interés mediante símbolos, pueden tener la unión en ambos entornos propuestos (mapas planos ó mapas 3D). 7. La unión de las rutas en línea indicadoras (sentido de las calles) 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). 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). 9. La unión de las rutas mediante un árbol y la representación de los puntos de interés mediante símbolos, pueden tener la unión en ambos entornos propuestos (mapas planos ó mapas 3D). 10. La unión de las rutas mediante un árbol 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). 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 117 Anexo A. Análisis para representar puntos de interés 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. Página 118 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 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 120 Anexo B. Estudio de plataformas móviles 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 121 Anexo B. Estudio de plataformas móviles 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 122 Anexo B. Estudio de plataformas móviles 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 123 Anexo B. Estudio de plataformas móviles 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 124 Anexo B. Estudio de plataformas móviles 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 125 Anexo B. Estudio de plataformas móviles 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 126 Anexo B. Estudio de plataformas móviles 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 127 Anexo B. Estudio de plataformas móviles 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 128 Anexo B. Estudio de plataformas móviles 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 129 Anexo B. Estudio de plataformas móviles 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. Página 130 ANEXO C Plan de pruebas Plan de pruebas de la aplicación SBLAGWMMS Anexo C. Plan de pruebas 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 132 Anexo C. Plan de pruebas 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 1 2 Tarea Habilidades especiales Responsabilidad precedente Preparación del Análisis de Autor de la tesis plan de sistemas de Visión general del estándar pruebas información IEEE 829-1998 geográfica Preparación del Tarea 1 Conocimiento de la forma Autor de la tesis diseño de de operación del sistema pruebas desarrollado así como de Página 133 Anexo C. Plan de pruebas 3 4 5 6 Preparación los casos prueba Aplicación las pruebas Resolver incidentes pruebas los módulos que lo conforman Conocimiento profundo de las características del software desarrollado Conocimiento del ambiente de desarrollo. 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 Conocimiento de las preguntas de investigación estipuladas para la tesis de Tarea 2 de de Tarea 3 los Tarea 4 de Evaluación de Tarea 4 los resultados Tarea 5 Autor de la tesis Autor de la tesis Autor de 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 PC de escritorio ó Laptop Módem GSM Dispositivo móvil Características mínimas 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 Symbian OS 7.0s ó superior Bluetooth Tecnología Java: CLDC 1.1, MIDP 2.0 Página 134 Anexo C. Plan de pruebas Tabla C.3 Requisitos ambientales de software Software J2SE versión 1.5 ó posterior IDE Netbeans 6.5.x ó posterior API Java Comunicaciones API SMS/MMS DBMS PostgreSQL 8.3.x ó posterior PostGIS 1.3.x ó posterior Conector JDBC Postgres Apache Tomcat Geoserver Geotools Descripción Lenguaje de programación Entorno de desarrollo de la aplicación API para la comunicación serial a través de Java. API para el desarrollo de aplicaciones LBS Sistema manejador de base de datos Extensión espacial para el manejador de base de datos PostgreSQL API para la conexión a la base de datos a través de Java Servidor de aplicaciones Servidor de mapas 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 Configuraciones y conexiones Descripción 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 Define la información recibida para la interpretación informació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 135 Anexo C. Plan de pruebas Generación de la ruta Generación de los POR Envío de la información Define la obtención de la generación de ruta. Define la generación y obtención de los puntos de referencia 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 PRUEBA SBLAGWMMS-01-01 SBLAGWMMS-01-02 Configuraciones y conexiones DESCRIPCIÓN Configuración y conexión con la base de datos relacional Configuración y conexión con la base de datos espacial Tabla C.6 Grupo de pruebas SBLAGWMMS-02 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 Tabla C.7 Grupo de pruebas SBLAGWMMS-03 PRUEBA SBLAGWMMS-03-01 SBLAGWMMS-03-02 SBLAGWMMS-03-03 SBLAGWMMS-03-04 Pruebas SBLAGWMMS-03 Generación del mapa DESCRIPCIÓN Obtención del perfil del dispositivo Obtención del mapa imagen Generación y obtención de la ruta destino Obtención de los POR (Point of Reference) Tabla C.8 Grupo de pruebas SBLAGWMMS-04 PRUEBA SBLAGWMMS-04-01 Pruebas SBLAGWMMS-04 Envío de la información DESCRIPCIÓN 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 136 Anexo C. Plan de pruebas 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 1.5.1.4.1 Propósito Configurar y conectar el software a la extensión PostGIS del manejador de base de datos PostgreSQL para procesar datos geométricos. 1.5.1.4.2 Entorno de prueba 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 137 Anexo C. Plan de pruebas 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 1.5.1.4.4 Resultado esperado 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. 1.5.2.2 Entorno de prueba 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 1.5.2.3.1 Propósito Obtener e interpretar la información de los mensajes de texto que son enviados al servidor mediante el dispositivo móvil para su procesamiento. 1.5.2.3.2 Entorno de prueba 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. 1.5.2.3.4 Resultado esperado 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 138 Anexo C. Plan de pruebas 1.5.3.2 Entorno de prueba 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 1.5.3.3.1 Propósito Obtener las características principales del dispositivo móvil para realizar el proceso de acuerdo a su perfil. 1.5.3.3.2 Entorno de prueba 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. 1.5.3.3.4 Resultado esperado 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 1.5.3.4.1 Propósito Obtener el mapa del servidor de mapas Geoserver de acuerdo a las coordenadas de origen y destino. 1.5.3.4.2 Entorno de prueba 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. 1.5.3.4.4 Resultado esperado Lograr la obtención del mapa de acuerdo a las coordenadas origen-destino y las características del dispositivo móvil. Página 139 Anexo C. Plan de pruebas 1.5.3.5 SBLAGWMMS-03-03 Generación y obtención de la ruta destino 1.5.3.5.1 Propósito Obtener la ruta mediante las capas de nodos y aristas aplicando el algoritmo de ruta. 1.5.3.5.2 Entorno de prueba 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. 1.5.3.5.4 Resultado esperado 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) 1.5.3.6.1 Propósito 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. 1.5.3.6.2 Entorno de prueba 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. 1.5.4.2 Entorno de prueba 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 1.5.4.3.1 Propósito Página 140 Anexo C. Plan de pruebas 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. 1.5.4.3.2 Entorno de prueba A través de la aplicación SBLAGWMMS se añaden los datos al archivo SVGTiny 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. 1.5.4.3.4 Resultado esperado 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 141 Anexo C. Plan de pruebas 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 142 Anexo C. Plan de pruebas Figura C.2 Resultados de la categoría Pastelerías 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: MINI SÚPER Resultado: OK Figura C.3 Resultados de la categoría Mini súper 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. Página 143 Anexo C. Plan de pruebas CATEGORÍA: GYM Resultado: OK Figura C.4 Resultados de la categoría Gym 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: ESCUELAS Resultado: OK Página 144 Anexo C. Plan de pruebas Figura C.5 Resultados de la categoría escuela 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: FARMACIAS Resultado: OK Figura C.6 Resultados de la categoría Farmacia 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. Página 145 Anexo C. Plan de pruebas CATEGORÍA: HOTELES Resultado: OK Figura C.7 Resultados de la categoría Hotel 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: BANCOS Resultado: OK Página 146 Anexo C. Plan de pruebas Figura C.8 Resultados de la categoría Banco 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: AUTOBUSES Resultado: OK Página 147 Anexo C. Plan de pruebas Figura C.9 Resultados de la categoría bus 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: CINE Resultado: OK Figura C.10 Resultados de la categoría cine 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. Página 148 Anexo C. Plan de pruebas CATEGORÍA: HOSPITAL Resultado: OK Figura C.11 Resultados de la categoría Hospital 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. Página 149 Anexo C. Plan de pruebas CATEGORÍA: RESTAURANTES Resultado: OK Figura C.12 Resultados de la categoría Restaurante 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. Página 150 Anexo C. Plan de pruebas CATEGORÍA: SUPERMERCADOS Resultado: OK Figura C.13 Resultados de la categoría Súper Mercado 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. Página 151 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) 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 153 Anexo D. Scalable Vector Graphics (SVG) 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 SVG 1.0 SVG 1.1 SVG Basic 1.1 SVG Tiny 1.1 SVG Tiny 1.1+ Descripción 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. 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. 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 154 Anexo D. Scalable Vector Graphics (SVG) SVG Tiny 1.2 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. 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 2 3 4 5 <?xml version=”1.0” encoding=”ISO-8859-1” standalone=”no”?> <!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1 Tiny//EN” “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd”> <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”> <-- SVG content goes here --> </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 155 Anexo D. Scalable Vector Graphics (SVG) Perfil MOBILE Perfil FULL 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 Numérico Coordenadas Listas Angulo Color Relleno Porcentaje Transformación de Listas URI Frecuencia Tiempo SVGBasic Si Si Si Si, con identificadores CSS CSS2 compatible a sRGB y 16 colores originales XHTML, no soportan X11. Si Si Si Si No Si SVGTiny Si Si Si Si, sin identificadores CSS CSS2 compatible a sRGB y 16 colores originales XHTML, no soportan X11. Sólo colores sólidos No SI Si No 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: Página 156 Anexo D. Scalable Vector Graphics (SVG) 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 157 Anexo D. Scalable Vector Graphics (SVG) 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 d Descripción 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) Color, FillStroke, Graphics y Markes De presentación Tabla D.2 Comandos utilizados en el path Comando M Parámetros x,y Repite Si L x,y Si H x Si V y Si C x1 y1 x2 y2 x y Si S x2 y2 x y Si Descripción 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. lineto: Dibuja una línea desde el punto actual hasta el punto (x, y). horizontal lineto: Dibuja una línea horizontal desde el punto actual a x. vertical lineto: Dibuja una línea vertical desde el punto actual a y. 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. 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 158 Anexo D. Scalable Vector Graphics (SVG) Q x1 y1 x y Si T xy Si A ** Si z - No 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. 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. 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. 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 2 3 4 5 6 7 8 9 10 11 12 <?xml version=”1.0” encoding=”utf-8”?> <!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1 Tiny//EN” “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd”> <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”> <defs id=”genericDefs”> <g id=”oxxo” stroke=”none” stroke-width=”0”> <rect x=”12.963” y=”12.458” fill=”#E42C35” width=”17.007” height=”4.833”/> <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 159 Anexo D. Scalable Vector Graphics (SVG) 0.195-0.333-0.438l0,0 c0-0.241,0.149-0.438,0.3330.438h16.622C30.101,11.25,30.25,11.446,30.25,11.688L30.25,11.688z”/> <path fill=”#F4DB27” d=”M29.97,18.062c0,0.242-0.149,0.438-0.333,0.438H13.015c-0.184,0-0.3330.195-0.333-0.438l0,0 c0-0.241,0.149-0.438,0.3330.438h16.622C29.82,17.625,29.97,17.821,29.97,18.062L29.97,18.062z”/> <text transform=”matrix(1 0 0 1 12.5425 17.167)” fill=”#FBFBFB” font-family=”‟OldgateLaneOutline‟” font-size=”6”>OXXO</text> </g> </defs> <g id=”capa0”> <use xlink:href=”#oxxo” transform=”translate(5 5) rotate(0) translate(-12.96 -12.45)” /> </g> </svg> 13 14 15 16 17 18 19 20 21 22 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 2 3 4 5 6 7 8 <?xml version=”1.0” encoding=”UTF-8”?> <!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1 Tiny//EN” “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11tiny.dtd”> <svg xmlns=”http://www.w3.org/2000/svg” baseProfile=”tiny” viewBox=”0 0 240 320”> <defs id=”genericDefs”> <g id=”oxxo” stroke=”none” stroke-width=”0”> …..//Elementos del logo </g> xmlns:xlink=”http://www.w3.org/1999/xlink” version=”1.1” Página 160 Anexo D. Scalable Vector Graphics (SVG) 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 <g id=”oro” stroke=”none” stroke-width=”0” > …..//Elementos del logo </g> <g id=”taxi” stroke=”none” stroke-width=”0”> …..//Elementos del logo </g> <g id=”cinemax” stroke=”none” stroke-width=”0”> …..//Elementos del logo </g> <path id=”Triangle” d=”M 6,0 L -3,3.7 v-6.7 z” fill=”#084B8A” stroke=”none” /> </defs> <g id=”capa0” display=”inline” stroke=”black”> ….. </g> <g id=”capa3” display=”inline” stroke=”#0A2A0A” stroke-width=”0.2”> <text x=”10” y=”10” font-size=”10”>Distancia a recorrer: 565.2121023466261</text> <line x1=”124.0” y1=”227.0” x2=”147.0” y2=”225.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <use xlink:href=”#Triangle” transform=”translate(135.5 226.0) rotate(359.2283309922658)” /> <line x1=”147.0” y1=”225.0” x2=”148.0” y2=”198.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <use xlink:href=”#Triangle” transform=”translate(147.5 211.5) rotate(283.6753688645108)” /> <line x1=”148.0” y1=”198.0” x2=”147.0” y2=”192.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <line x1=”147.0” y1=”192.0” x2=”137.0” y2=”192.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <line x1=”137.0” y1=”192.0” x2=”133.0” y2=”191.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <line x1=”133.0” y1=”191.0” x2=”132.0” y2=”190.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <line x1=”132.0” y1=”190.0” x2=”132.0” y2=”188.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <line x1=”132.0” y1=”188.0” x2=”132.0” y2=”187.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <line x1=”132.0” y1=”187.0” x2=”141.0” y2=”158.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <use xlink:href=”#Triangle” transform=”translate(136.5 172.5) rotate(294.4114687460243)” /> <line x1=”141.0” y1=”158.0” x2=”143.0” y2=”148.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <use xlink:href=”#Triangle” transform=”translate(142.0 153.0) rotate(283.5149934205348)” /> <line x1=”143.0” y1=”148.0” x2=”144.0” y2=”141.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <line x1=”144.0” y1=”141.0” x2=”142.0” y2=”112.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <use xlink:href=”#Triangle” transform=”translate(143.0 126.5) rotate(269.50193983749386)” /> <line x1=”142.0” y1=”112.0” x2=”141.0” y2=”93.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <use xlink:href=”#Triangle” transform=”translate(141.5 102.5) rotate(269.51821326518393)” /> <line x1=”141.0” y1=”93.0” x2=”135.0” y2=”43.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <use xlink:href=”#Triangle” transform=”translate(138.0 68.0) rotate(269.4513674007766)” /> <line x1=”135.0” y1=”43.0” x2=”136.0” y2=”43.0” stroke-width=”2.5” fill-opacity=”0.5” stroke=”#0174DF” /> <use xlink:href=”#taxi” transform=”translate(158.0 228.0) rotate(0) translate(-14.75 -36.62)” /> <circle cx=”153.0” cy=”230.0” r=”2.0” fill-opacity=”0.5” stroke-width=”0.5” fill=”red” stroke=”black” /> <use xlink:href=”#oxxo” transform=”translate(145.0 189.0) rotate(0) translate(-12.96 -12.45)” /> <circle cx=”140.0” cy=”191.0” r=”2.0” fill-opacity=”0.5” stroke-width=”0.5” fill=”red” stroke=”black” /> <use xlink:href=”#oro” transform=”translate(145.0 111.0) rotate(0) translate(-14.5 -27.26)” /> <circle cx=”140.0” cy=”113.0” r=”2.0” fill-opacity=”0.5” stroke-width=”0.5” fill=”red” stroke=”black” /> <use xlink:href=”#cinemax” transform=”translate(145.0 91.0) rotate(0) translate(-22.86 -53.99)” /> <circle cx=”140.0” cy=”93.0” r=”2.0” fill-opacity=”0.5” stroke-width=”0.5” fill=”red” stroke=”black” /> <circle cx=”136.0” cy=”39.0” r=”2.0” fill-opacity=”0.5” stroke-width=”0.5” fill=”red” stroke=”black” /> <text x=”141.0” y=”37.0” font-size=”8” font-family=”Verdana” fill=”#0A2A0A” stroke-width=”0”>Super gym</text> </g> </svg> Figura D.5 Código SVG que representa puntos de referencia en un mapa Página 161 Anexo D. Scalable Vector Graphics (SVG) Figura D.6 Puntos de referencia representados mediante logos en SVG-Tiny Página 162 REFERENCIAS [Arienza, 2006] ArienzaJorge L.; Sistemas Operativos http://jlarienza.blogspot.com/2006/10/sistemas-operativos-moviles.html; 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 textoimagenen 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 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 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, en móviles, última línea]. localización”. Referencias http://www.ikg.unihannover.de/publikationen/publikationen/2005/hampe_mobilemaps2005.pdf, última consulta: Septiembre 2008 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. 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; última consulta: Septiembre 2008 [MWM, 2008] Microsoft; Windows Mobile 6.0; http://msdn.microsoft.com/enus/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, http://europe.nokia.com/A4172038. última consulta: Junio 2009 2007. [oJUMP, 2009] openJUMP, 2009. Sitio oficial de openJUMP. [En http://openjump.org/wiki/show/HomePage. Consultado en Enero 2009. línea]. [openLayers, 2009] openLayers, 2009. Sitio oficial de openLayers. [En línea]. http://openlayers.org/. Última consulta: Febrero 2009. [En línea]. Página 164 Referencias [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] [Reichembacher, 2004] Quiñonez Bernardino Pedro,Gateway SMS/MMS Pull Para Consultas Dependientes/Independientes de la Ubicación con una Arquitectura de Servicios Web, cenidet 2007 Tumasch Reichenbacher; Instituto de Fotogrametría y Cartografía, 2004; Adaptive Visualisation of Geographic Information on Mobile Devices; http://tumb1.biblio.tumuenchen.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 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.unioldenburg.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. en localización”. Página 165 Referencias [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] [Turner, 2003] Apache Tomcat, http://tomcat.apache.org/, última consulta: Agosto 2009 Turner Alasdair, Penn Alan y Hillier Bill, An algorithmic definition of the axial map, Noviembre, 2003. uDIG 2008. Sitio oficial de uDIG. [en línea]. http://udig.refractions.net/. Consultado en Enero 2009. [uDIG, 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 http://www.wdsglobal.com/downloads/infosheets/DeviceMine.pdf consulta Diciembre 2008 , Management” 2007, última [WMS, 2009] Web Map Service, http://www.opengeospatial.org/standards/wms , última consulta: Agosto 2009 [WorldWind, 2009] WorldWind, 2009. Sitio oficial de WorldWind. 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 [En línea]. Página 166