Marco Teórico

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