PROYECTO FIN DE CARRERA
DESARROLLO DE UN SISTEMA INTELIGENTE GPS-RASTER PARA
UNA PDA
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA
Resumen
Este proyecto consiste en el desarrollo de una aplicación que sea capaz de tomando un archivo de imagen cualquiera de un mapa de carreteras, independientemente del formato de imagen de archivo y del modo en el que estén representadas las vías de circulación en él, proporcionar servicios de calculo de rutas e interacción con un dispositivo GPS al mismo nivel que daría un mapa comercial especialmente desarrollado con este propósito. De este modo, será una herramienta que podrá proveer a usuarios que quieran hacer uso de sus sistemas de navegación en zonas que o bien no disponen de mapas adecuados para sus necesidades o bien que directamente aún no han sido mapeadas por las compañías que desarrollan este tipo de mapas.
Esta aplicación va a desarrollarse íntegramente sobre una plataforma PDA, pues es en este tipo de plataforma donde se hace uso de los sistemas de navegación GPS y donde la posibilidad de trazar una ruta sobre mapas de carreteras puede ser realmente útil. La idea es permitir que el usuario solo tenga que descargar la imagen a su PDA desde cualquier fuente, y tras un pequeño proceso de análisis y pretratado sea capaz de emplear el mapa como si hubiese sido especialmente desarrollado con ese propósito.
Para conseguir esto, es necesario que la aplicación sea capaz de ver las vías de circulación contra el fondo, diferenciarlas de otros elementos similares como ríos o líneas de coordenadas, analizar sus características para obtener
su trazado, su longitud e identificar el tipo de vía al que pertenece, para así poder calcular tanto rutas mínimas como rutas óptimas de acuerdo con un formato definido por el usuario.
Para poder analizar la imagen a nivel que eso requiere, a su vez, es necesario que esta se encuentre en un formato vectorial que además sea fácilmente legible por la aplicación. Por tanto, antes del análisis será necesario realizar una transformación de la imagen a un formato vectorial que además deberá ser abierto para poder acceder de modo directo a los datos del mapa de carreteras
Como resultado del análisis realizado sobre la imagen vectorial, la aplicación habrá reconocido los distintos tipos de carreteras presentes en el mapa y tendrá todos los datos necesarios para calcular rutas sobre el mapa.
Para realizar el cálculo de rutas en sí, se creará un Grafo de Rutas que recogerá todos los datos relativos al mapa de carreteras, sobre el que se implantará un algoritmo de búsqueda heurística. Mediante estas dos herramientas, la aplicación podrá calcular la ruta de mínimo recorrido entre dos puntos cualesquiera que el usuario indique sobre mapa de carreteras.
simple como indicar las coordenadas geográficas reales de tres puntos sobre la superficie del mapa, definir completamente la colocación del mapa sobre la superficie de la Tierra. La aplicación calculará desde esos tres puntos la localización, orientación y escala del mapa.
Todos los datos relativos tanto al Grafo de Rutas como al posicionamiento del mapa permanecerán guardados de modo que el mismo mapa pueda ser empleado de nuevo sin necesidad de repetir el proceso de generación del grafo y de posicionamiento del mapa.
Abstract
The purpose of this project is the development of an application capable of taking an image file of a roadmap, independently of its file format and the way the roads are represented within it, provide with route calculation and interaction with a GPS device at the same level a commercial map especially prepared for this purpose. This way, it will become a tool capable of providing users who wish to make use of their navigation systems on areas that either do not have maps adequated for their necessities or simply have not been maped yet by the companies who make this kind of maps.
This application will be entirely developed on a PDA platform, as this kind of platform is where the use of GPS navigation systems and the possibility of determining over a roadmap may be truly useful. The idea is allow for the user to only have to download the image on his PDA from any source, and after a short process of analysis be capable of employing the map as if it had been specially developed with this purpose.
In order to achieve this, is necessary for the application to distinguish the
be in a vectorial format that is also easily readable by the application. As such, before the analysis it will be needed to realize a conversion of the image into a vectorial format that is also open in order to access directly to the roadmap data.
As a result of the analysis conducted on the application will had recognized the different kinds of roads present on the map and will have all the data required to calculate routes on the map.
To realize the route calculation itself, a Route Graph containing all the data relative to the roadmap will be created. On this graph an heuristic search algorithm will be implemented. Using these two tools, it will be possible to calculate the minimum longitude route between whichever two points indicated by the user on the roadmap.
During the realization of its functionalities, the application will be capable of interacting with the GPS device integrated on the PDA. This way, it will be possible to define the starting and ending point as the current location of the GPS device, and of course also indicate to the user its current location on the roadmap.
In order to interact with the GPS, the user will be able to, with a gesture as simple as indicating the geographic coordinates of three points on the map surface, completely define the location of the map on Earth’s surface. The
application will calculate form this three points the location, orientation and scale of the map.
All data related to both the Route Graph and the location of the map will be stored so the same map may be used again without having to repeat the graph generation and map location processes.
La elaboración de este proyecto no habría sido posible sin la inestimable ayuda de José Ángel Olivas Varela y Miguel Ángel Sanz Bobi.
Muchas gracias familia, profesores y amigos por vuestro apoyo.
A todos vosotros os lo dedico.
Índice
Capitulo 1 - Introducción y Planteamiento 1
1.1. Necesidad del Proyecto 3
Capitulo 2. Objetivos 5
Capitulo 3 - Requisitos de la aplicación 8
Capitulo 4 - Estado del Arte 10
4.1. GPS (Global Positioning System) 11
4.2. Modelo Geográfico 15
4.2.1. La Tierra 15
4.2.2. Meridianos y Paralelos 15
4.3. Proyección Mercator 18
4.4. Búsqueda Heurística 20
4.4.1. Algoritmo A* 22
4.4.2. Funcionamiento de A* 25
4.5. Tecnologías 34
4.5.1. PDA (Personal Digital Assistant) 34
4.5.2. SVG (Scalable Vector Graphics) 36
4.5.3. AutoTrace 38
4.5.4. BMP 40
4.5.5. XML (Extensible Markup Language) 41
4.5.6. Microsoft Visual Studio .NET 43
4.5.7. C# 44
Capitulo 5 - Desarrollo del Sistema GPS 45
5.1. Decisiones de Diseño 46
5.2. Diseño de la Aplicación 49
5.2.1. División en módulos 50
5.2.2. DFD Módulo Vectorizador 51
5.2.3. DFD Módulo Enrutador 52
5.2.4. DS Proceso de Vectorización 53
5.3. Grafo de Rutas 54
5. 4. Módulo Vectorizador 57
5.4.1. Tratamiento de la imagen 59
5.4.1.1. Identificación de carreteras 59
5.4.1.2. Tratamiento en fases de la imagen 60
Aproximación de nodos 69
Conexión de nodos 71
Eliminación de Elementos Redundantes 73
Parámetros de Refinado 75
5.4.2. Editor de Grafo 78
5.4.3. Generación del documento XML 83
5.5. Módulo Enrutador 84
5.5.1. Lectura del fichero XML 84
5.5.2. Calculo de Rutas Mínimas 85
Representación de la ruta calculada 86
5.5.3. Posicionamiento 88
5.5.3.1. Localización 89
5.5.3.2. Orientación 90
5.5.3.3. Escala 92
5.5.3.4 Empleo de un Modelo de Tierra Plana 93
5.5.3.4.1. Dos puntos frente a tres puntos 94
5.5.3.4.2. Parámetros de conversión 95
Grado de Longitud 95
Ratio de Kilómetros a Píxeles 97
Matriz de Conversión de Coordenadas 97
5.5.4. Conversión de coordenadas 99
5.5.4.1. Aplanamiento de la Tierra 99
5.5.4.2. Cambio de Escala 101
5.5.4.3. Cambio de Ejes Coordenados 101
5.5.5. Fallo a Mayor escala 103
Imprecisión propia del mapa 109
5.6. Limitaciones de la aplicación 111
5.6.1. Generación del Grafo de Rutas 111
5.6.1.1. Influencia del formato 111
5.6.1.2. Abstracción al grafo 113
Elementos que no son carreteras 113
Perdida de carreteras 114
Cúmulos de Nodos 115
Capitulo 6 - Evaluación del proyecto 128
6.1. Generación del Grafo de Rutas 129
6.2. Calcular Ruta de Mínimo Recorrido 132
6.3. Posicionamiento y Conversión de Coordenadas 134
Capitulo 7 - Conclusiones 136
7. 1. Cumplimiento de los Objetivos 141
7.2. Cumplimiento de los Requisitos 146
Capitulo 8 - Planificación y Presupuesto 149
8.1. Planificación del Proyecto 150
8.2. Presupuesto del Proyecto 152
Capitulo 9 - Bibliografía 154
Apéndice - Uso de la aplicación 156
A.1. Módulo de Vectorización 157
A1.2. Módulo Enrutador 171
Capitulo 1 - Introducción y Planteamiento
El propósito de este proyecto es el desarrollo de un sistema, orientado a su implantación en un formato PDA, que, tomando un mapa en un formato de imagen simple, como un mapa de bits, se capaz de convertirlo en un mapa que pueda ser directamente empleado por un dispositivo GPS. Con este mapa, se podrán determinar rutas, distancias y tiempos entre puntos mediante técnicas de búsqueda heurística. Para realizar el proceso de conversión del mapa, el sistema lo convertirá a un formato vectorial para poder tratar sus características directamente y determinará su escala y su posición global mediante la definición de varios puntos de referencia.
1.1. Necesidad del Proyecto
Los sistemas de navegación GPS actuales requieren para su funcionamiento el uso de mapas especialmente desarrollados para este propósito, que además sean compatibles con el sistema de ubicación geográfica del propio del GPS. Este hecho conlleva múltiples limitaciones en el uso de estos dispositivos. Estos mapas frecuentemente pueden no cubrir las necesidades de un usuario en un momento determinado, ya sea porque no abarcan con suficiente precisión el área que interesa al usuario, porque no están adecuadamente actualizados o sencillamente porque no existe ningún mapa de esa área. En ocasiones el usuario ni siquiera tendrá la posibilidad de adquirir el mapa que necesita al no tener acceso al sistema de distribución que la compañía desarrolladora emplee.
Sin embargo, es prácticamente seguro que el usuario podrá tener a su alcance un mapa normal (es decir, no preparado para su uso por un dispositivo GPS) que satisfaga sus necesidades en un mayor grado, pero se verá obligado adquirir un mapa especialmente desarrollado para su uso por su sistema GPS, que además de sufrir los problemas anteriormente mencionados será
mapa disponga de una inteligencia adicional. Esta inteligencia está contenida en una base de datos adjunta al mapa que reúne todos los datos necesarios para que el mapa conozca donde se encuentran las vías de circulación, y conozca sus características físicas como su trazado, las conexiones que tenga con otras carreteras y su longitud.
Tradicionalmente crear estos mapas preparados para GPS requiere trazar manualmente las vías sobre el mapa para que sus características sean comprendidas por el sistema. Este por lo general es un proceso considerablemente lento y caro, e implica que ninguna de las compañías dedicadas a esta tarea va a trazar mapas a los que no crea vaya a dar salida.
El resultado es que la mayor parte del mundo no dispone de mapas preparado para el uso de sistemas de autorouting que represente sus vías con suficiente precisión, completitud y actualidad.
Resolver este problema es el principal propósito de este proyecto. El usuario debe ser capaz de poder aprovechar su dispositivo GPS con cualquier mapa que ya posea, a pesar de que no haya sido especialmente desarrollado para ello, y además de poder añadir un nuevo mapa a su navegador en cualquier momento según aparezca la necesidad, y de poder utilizar estos mapas como si hubieran sido preparados para la navegación GPS.
Capitulo 2. Objetivos
La aplicación podrá tomar un archivo de imagen en cualquier formato y será capaz de crear un Grafo de Rutas a partir únicamente de la imagen, de modo que en él se detallen las distancias, trazado de la vía y rutas entre los puntos significativos del mapa, y las coordenadas geográficas de esos puntos.
El proceso de vectorización de la imagen deberá ser capaz de diferenciar los tipos de vía presentes en el mapa. Así mismo, deberá diferenciar estas de otros elementos del mapa que puedan causar confusión, como ríos y otros elementos geográficos.
El usuario podrá posicionar el mapa en el sistema de coordenadas de latitud y longitud utilizado por el GPS simplemente definiendo las coordenadas de varios puntos en el mapa. A partir de esto, el dispositivo calculará todos los parámetros que pueda necesitar para realizar un cambio de coordenadas entre los sistemas empleados por la aplicación, y a partir de esos datos, calcular la localización del mapa, su orientación y su escala. Conociendo esto, podrá calcular la longitud de los tramos de vías de circulación, de las rutas calculadas por el sistema y las coordenadas actuales del usuario sobre el mapa. Este proceso solo necesitará ser realizado una vez, y el mapa recordara los resultados para futuras ejecuciones.
El sistema podrá asignar pesos a los tipos de vía presentes en el mapa identificados durante el análisis del mapa, de modo que favorezca algunos, como las autopistas, sobre otros al calcular el recorrido óptimo. El usuario
podrá definir estos pesos a voluntad, o utilizar algún esquema de pesos predeterminado.
Partiendo de estos datos, el sistema podrá calcular la ruta de mínima distancia entre dos puntos cualesquiera del mapa, no solo los definidos como puntos significativos durante el proceso de análisis, y a continuación podrá mostrar esta ruta directamente sobre el mapa, e indicara al usuario su longitud total.
Capitulo 3 - Requisitos de la aplicación
El sistema deberá estar implantado completamente sobre una plataforma Pocket PC, y ser capaz de interactuar con el receptor GPS de ésta durante la realización de sus funcionalidades. Esto se requiere para así poder dar al usuario la capacidad de trabajar de modo inmediato con cualquier mapa de carretera que se introduzca a la aplicación.
La herramienta deberá estar orientada a un usuario al que no se le supone ningún conocimiento sobre informática, funcionamiento de dispositivos GPS, sistemas de navegación o tratamiento de imagen. Por ello, su interfaz deberá ser intuitiva, sencilla y autoexplicativa, y el uso de la aplicación deberá ser extremadamente sencillo, manteniendo todos los procesos de tratamiento de la imagen y de interacción con el dispositivo GPS transparentes al usuario.
Capitulo 4 - Estado del Arte
4.1. GPS (Global Positioning System)
El Sistema de Posicionamiento Global, más conocido como GPS (Global Positioning System) es el único sistema de navegación por satélite que actualmente proporciona una cobertura completa a nivel global. Dispone de una constelación en la que siempre hay al menos 24 satélites activos, que transmiten señales de radio precisamente temporizadas que permiten a los receptores GPS calcular con exactitud su latitud, longitud y altitud. Mediante estos datos los dispositivos receptores actuales también son capaces de calcular su velocidad y orientación. En todo momento, en cualquier punto de la superficie de la Tierra, sea de día o de noche y bajo cualquier clima, un dispositivo GPS es capaz de ver al menos los cuatro satélites que necesita para hacer ese cálculo y conocer tanto la distancia que los separa de ellos como su posición orbital actual. De este modo, obtiene el radio (la distancia al satélite) y el centro (la posición orbital del satélite) de cuatro esferas cuyo punto de intersección es precisamente la localización actual, definida por su latitud, longitud y altitud del punto actual.
Puede parecer lógico que se requiriera únicamente tres satélites, puesto
climáticas y por la altura de los satélites sobre el horizonte. El cuarto satélite permite determinar el retardo de las señales recibidas por cada satélite de forma lo suficientemente exacta como para permitir que el dispositivo pueda calcular su posición de modo fiable.
La medición exacta del tiempo es una característica fundamental en el funcionamiento de los satélites GPS, puesto que las distancias a los satélites que se utilizan se calculan como el tiempo que ha tardado en recorrerlas una onda de radio, que viaja a la velocidad de la luz. Eso significa que un reloj que calculara el tiempo con precisión de milésimas de segundo, fallaría en su estimación por 300 km. Por ello, los satélites utilizan relojes atómicos de extrema precisión. Es interesante notar que debido a que los relojes de los satélites están sometidos tanto a la relatividad general como a la espacial, el tiempo avanza ligeramente más rápido en ellos que en la Tierra.
Concretamente, los relojes de los satélites van aproximadamente 38 microsegundos al día más rápido que los relojes en la Tierra. Pero si los dispositivos de recepción tuvieran relojes de ese nivel, costarían millones de euros y nadie podría acceder a ellos. Para reparar la imprecisión producida por el más limitado reloj del receptor es para lo que existe la señal del cuarto satélite.
Recientemente, los campos en los que se aplican los dispositivos GPS han dejado de estar limitados a su uso por parte de fuerzas militares, tareas de
salvamento y navegación profesional. Tras su introducción en dispositivos portátiles de navegación disponibles al público general, aparecieron programas de creación de itinerarios que eran capaces de generar rutas mínimas sobre un PC que podían a continuación ser importadas a un dispositivo GPS. Debido al éxito de este planteamiento, poco después empezaron a aparecer coches equipados de serie con sistemas de navegación GPS integrados, y programas de cálculo de rutas que funcionaban en tiempo real directamente sobre los dispositivos de navegación GPS, el denominado autorouting.
El empleo de autorouting por parte de los dispositivos GPS requiere de una completa base de datos de las vías de circulación de la zona recorrida aparte del mapa de carreteras en sí. Esta base de datos debe incluir el trazado de las carreteras, su longitud, sus conexiones con otras carreteras, etcétera.
Debido a estos requisitos, que hacen del proceso de creación de mapas de preparados para autorouting un proceso lento y costoso, y del hecho de que la tecnología es aún considerablemente nueva, las áreas del mundo que disponen actualmente de mapas de carreteras con estas características, con una base de datos como la descrita adjunta y con un mínimo de fidelidad a la realidad y de exactitud se limitan a Estados Unidos, Canadá, Europa
por estas comunidades sea bastante limitada.
4.2. Modelo Geográfico.
4.2.1. La Tierra
La Tierra como planeta no es una esfera perfecta, sino un esferoide ligeramente achatado en los polos. Así, su radio mayor, en el ecuador es 6378.137 km, y en los polos de 6356,752 km. Para este proyecto se ha considerado, no obstante, a la tierra como una esfera perfecta de radio constante 6372 km puesto que la deformación producida por esta aproximación es despreciable.
4.2.2. Meridianos y Paralelos
Las coordenadas geográficas que tradicionalmente se utilizan en la navegación para determinar puntos sobre la superficie terrestre, y que también son las utilizadas por los dispositivos GPS se denominan Latitud y Longitud.
La latitud es el ángulo que la recta que une el punto observado y el centro de la tierra mantiene con el plano ecuatorial. Tradicionalmente se le da a la latitud de los puntos situados en el Hemisferio Norte un valor positivo y a los
considerablemente el funcionamiento matemático de la aplicación.
La longitud es el ángulo que la recta perpendicular al eje de rotación de la Tierra que pasa por el punto observado mantiene con el semiplano definido por el eje de rotación de la Tierra y por la localización del antiguo observatorio astronómico ubicado en Greenwich, uno de los barrios de Londres. De modo similar a la latitud, existe un convenio que define la longitud en puntos situados al Este de este punto, también denominados conjuntamente como Hemisferio Este, como positiva, mientras que los puntos situados al Oeste del semiplano, o Hemisferio Oeste, como negativos. Siguiendo este convenio, la longitud varía desde -180º, para los puntos situados en el semiplano opuesto a Greenwich, 0º en el propio semiplano y +180º en el mismo punto en el que se empezó. Este convenio también se ha adoptado en el proyecto, por razones análogas a las del caso de la latitud.
Un paralelo es una línea ficticia trazada sobre la superficie de la Tierra por la intersección de un plano perpendicular al eje de rotación con la Tierra.
En un paralelo, la latitud se mantiene constante, y sobre él se mide la longitud.
La longitud de la circunferencia definida por un paralelo varía desde 40075 km en el Ecuador hasta 0 km en los polos. Por esto, la longitud de los grados de longitud varía conforme la latitud del punto observado.
Un meridiano es una línea ficticia trazada sobre la superficie de la Tierra por la intersección de un semiplano que parta del eje de rotación de la Tierra y
la superficie de la Tierra. Como tal, es una semicircunferencia. En un meridiano, la longitud se mantiene constante y sobre él se puede medir la latitud. Un antimeridiano es el meridiano situado en el punto opuesto del planeta y que cierra la circunferencia definida por un meridiano. Puesto que la longitud de la semicircunferencia definida por un meridiano es constante independientemente de la longitud, la longitud de los grados de latitud es constante. No obstante, no hay que olvidar que esto es solo porque se está trabajando sobre una representación teórica de la Tierra como una esfera perfecta. En realidad, al ser un esferoide, la longitud de los grados de latitud varía según la latitud desde 110,57 en el Ecuador hasta 111,70 a la altura de los polos. Es interesante notar que aún tomando la Tierra como un esferoide, la longitud de los grados de latitud sigue siendo independiente de la longitud a la que se encuentre el punto observado.
4.3. Proyección Mercator
Debido al hecho de que la Tierra es una esfera, es imposible representar su superficie sobre un plano de forma fidedigna. A lo largo de la historia han surgido múltiples sistemas de proyección para representar tratar de representar la Tierra sobre un plano de un modo útil. La proyección Mercator es un sistema de proyección cartográfico ideado en 1569 por el cartógrafo holandés Gerardus Mercator.
En este sistema de proyección se emplea como superficie de proyección un cilindro cuyo eje central es coincidente con el eje de rotación de la Tierra.
Los sistemas de proyección cilíndrica inevitablemente introducen una deformación en dirección Este-Oeste alejándose del Ecuador en un ratio cuyo valor es la secante de la latitud con respecto a la escala en el Ecuador. La característica que diferencia a la proyección Mercator de otros sistemas de proyección cilíndrica como el de Miller o el de plate careé es la introducción de una deformación en la misma proporción en sentido Norte-Sur. El resultado que hacer esto conlleva es que las distancias que separan los paralelos y los meridianos se mantienen constantes en el mapa. Además, los ángulos representados sobre el mapa son iguales que los presentes en la superficie de la Tierra. Como resultado de esto, las líneas de orientación constante, es decir, las líneas que avanzan sin cambiar de rumbo moviéndose por la superficie de la Tierra son igualmente rectas sobre el mapa, independientemente de la
longitud o latitud a la que se encuentre el punto observado. Este es el motivo por el cuál pese a que proyección Mercator, con más de 400 años de antigüedad, y que exagera de modo descomunal las áreas de las regiones situadas a elevadas latitudes sigue siendo una de las proyecciones más empleadas hoy en día.
No obstante, la proyección Mercator no ha sido seleccionada como proyección para la representación del modelo de Tierra desarrollado en el proyecto por estos motivos sino por su extrema simplicidad de cálculo. Puesto que se espera que a la escala a la que se vaya a emplear el mapa la curvatura de la Tierra sea poco apreciable, la deformación que las diferentes proyecciones introducen pasa a un segundo plano, siendo el principal motivo para la selección de un sistema de proyección su sencillez desde un punto de vista matemático. Por esto es por lo que se ha seleccionado la proyección Mercator para realizar las conversiones de coordenadas.
4.4. Búsqueda Heurística
El razonamiento puede entenderse como la búsqueda de una solución en una base de conocimientos. Según esta filosofía existen varios algoritmos de inteligencia artificial cuyo funcionamiento se basa en la búsqueda de la solución óptima a través de una estructura como un grafo o un árbol generados a partir de la base de conocimiento. Estos algoritmos se denominan algoritmos de búsqueda heurística.
La búsqueda de soluciones óptimas a través de grafos no se limita al campo de la inteligencia artificial, sino que es un problema clásico para el que se han desarrollado multitud de algoritmos de búsqueda, muchos de los cuales no tienen ningún tipo de inteligencia. Los algoritmos de búsqueda heurística se diferencian de estos en el empleo de una cierta cantidad de conocimiento durante el proceso de búsqueda. Este conocimiento ayuda al algoritmo a escoger un camino hacia la solución, aunque puede que el camino no lleve a la solución óptima. Al emplear un algoritmo de búsqueda heurística se está sacrificando la exahustividad propia de un algoritmo de búsqueda por fuerza bruta a cambio de obtener una solución para un problema de forma más eficiente que con los algoritmos tradicionales.
En el caso de este problema, se ha recurrido al uso de un algoritmo de búsqueda heurística debido a que la base de conocimiento sobre la que se está trabajando, que no es otra que el propio mapa de carreteras que se está
analizando, ya tiene una estructura propia de un grafo; Es decir, se compone de una serie de puntos significativos, como cruces, ciudades, etcétera, que están conectados entre sí por una serie de caminos, las vías de circulación, definidos por unos ciertos pesos, sus longitudes en kilómetros.
El problema a resolver también es de los clásicos que se suele resolver mediante algoritmos de búsqueda, tanto en el caso de los normales como en el de los algoritmos de búsqueda heurística: La búsqueda del camino de mínimo peso entre dos puntos definidos de un grafo, desde el punto donde se inicia la búsqueda hasta un punto meta donde concluye la búsqueda. En el caso de un grafo generado a partir de un mapa de carreteras, encontrar el camino de mínimo peso supone encontrar la ruta de mínimo recorrido a través del mapa de carreteras representado por el grafo.
4.4.1. Algoritmo A*
De entre los diferentes algoritmos de búsqueda heurística existentes, se ha seleccionado para el cálculo de la ruta de mínimo recorrido el algoritmo de búsqueda heurística A* para el cálculo de la ruta de mínimo recorrido sobre el grafo generado a partir del mapa de carreteras.
Entre los diferentes algoritmos de búsqueda existen dos métodos básicos para encontrar la solución óptima. La búsqueda en profundidad explora una rama del árbol de soluciones, o un posible camino desde el punto de vista del grafo, hasta que encuentra la solución o llega al final. Emplear un algoritmo basados en profundidad aseguraría llegar hasta el destino, pero no el que se hiciera por el camino más corto. La búsqueda en anchura expande todos los nodos desde el origen, hasta que de estos resulta en el nodo solución. La búsqueda en anchura asegura encontrar el camino con menos saltos hasta el destino, pero este no tiene porque ser el óptimo. Además, su complejidad y tiempo de ejecución son exponenciales respecto al número de nodos del grafo.
Con la complejidad que se espera tenga el grafo generado por encontrar la solución óptima, este método se vuelve del todo inaplicable.
Para el cálculo de las rutas mínimas, el programa no va a hacer uso de ninguno de estos dos métodos elementales. El algoritmo que se empleará es un método de búsqueda del primer mejor. Éste tipo de algoritmos combina las ventajas de los algoritmos basados en profundidad y en anchura siguiendo un
único camino, pero cambiando de ruta en cualquier momento, cuando aparezca una ruta alternativa que resulte más prometedora que la actual. Para decidir si se va a cambiar de ruta, estos algoritmos hacen uso de un cierto conocimiento, con lo que añaden una inteligencia al proceso de búsqueda, lo que los hace algoritmos de búsqueda heurística.
Más exactamente, se va a emplear uno de los algoritmos denominados Branch-and-Bound, un perfeccionamiento de los algoritmos de Búsqueda del Primer Mejor que añaden a los cálculos para la decisión del camino hacia el destino el coste acumulado de lo recorrido hasta el momento. Como resultado, no sólo localizan la solución, sino que además lo hacen a través del camino óptimo hacia ella. Puesto que el propósito para el que se están usando estos algoritmos es precisamente el de localizar el camino de mínimo peso, es decir, recorrido, hasta el nodo destino, este tipo de algoritmos resulta perfecto para la tarea.
El algoritmo A* es uno de los algoritmos de Branch-and-Bound. Este algoritmo mejora el modelo básico Brach-and-Bound incorporando una función de mérito que se calcula como la combinación del coste incurrido hasta el nodo actual más una función de estimación heurística que predice cual es el coste
cantidad de inteligencia y conocimiento en el propio algoritmo de selección de caminos. El nivel en el que la solución calculada por el algoritmo será óptima y el tiempo que se tardará en alcanzarla dependen directamente de la calidad de la función heurística, por tanto su selección es un punto fundamental en el desarrollo del algoritmo.
En este proyecto se ha implementado como función de estimación heurística la distancia en línea recta que separa el nodo que esta siendo evaluado para expandir la ruta en su dirección y el nodo destino. En lo que esto resulta es que el algoritmo considera que, en una situación en la que los caminos hacia los nodos sean equivalentes, el sistema va a optar por el nodo vecino más cercano al destino. En otras palabras, el algoritmo actúa llevado por el conocimiento de que avanzando en la dirección en la que se encuentra el destino es como más probablemente vaya a encontrar la ruta de longitud mínima. Esto no debe llevar a pensar que en caso de que alcanzar el destino requiera en algún momento alejarse de él o en él que el camino más directo no sea el más corto el algoritmo se va a ver visto en problemas. Sin duda tardará más al tener que probar antes los caminos que van hacia el destino, pero seguirá obteniendo la ruta óptima. En la mayoría de los casos, no obstante, especialmente en los que pueden presentarse en el trazado de rutas sobre mapas concerniente a este sistema, seguirá siendo más rápido que cualquiera de los otros algoritmos de búsqueda heurística. Por esta superioridad en la aplicación a este campo, y puesto que la función de búsqueda que se ha
empleado es directamente deducible, y fácil de implementar y calcular, es por lo que se ha decidido emplear este algoritmo para el cálculo de las rutas mínimas.
4.4.2. Funcionamiento de A*
Tomando como ejemplo de Grafo de Rutas este mapa de Rumania:
En el que la distancia en línea recta desde cada una de las ciudades (nodos) representadas en el mapa hasta Bucarest (nodo destino) es:
Arad 366 Mehadia 241
Bucarest 0 Neamt 234
Craiovra 160 Oradea 380
Dobreta 242 Pitesti 100
Efoire 161 Rimnicu Vilcea 193
Fagaras 176 Sibiu 253
Giurgiu 77 Timisoara 329
Hirsova 151 Urziceni 80
Iasi 226 Vaslui 199
Lugoj 244 Zerind 374
Se va a emplear el algoritmo A* con la misma implantación que se emplea en el cálculo de rutas mínimas en la aplicación, empleando la misma función heurística, para calcular la ruta de mínimo recorrido entre Arad y Bucarest
En Arad, la función de evaluación, calculada como suma entre el peso de la ruta acumulada hasta este momento y el valor de la función de evaluación en ese punto tiene el valor de:
Arad: 366 = 366+0
Tras la expansión de Arad, los valores de las funciones de evaluación pasan de cada uno de sus vecinos hacia los que se expande son:
mínimo valor en su función de evaluación. Por tanto, se expande la ruta en esa dirección.
Ahora se expande el nodo de Sibiu, y se calculan las funciones de evaluación respectivas. Las rutas que se pueden expandir desde Sibiu no solo se comparan entre sí, sino también con las que antes se calcularon desde Arad
Timisoara: 447 = 118+329
Zerind: 449 = 75+374
Arad: 646 = 280+366
Fagaras: 415 = 239+176
Oradea: 671 = 291+380
Rimnicu Vilcea: 413 = 220+193
Esta vez, la dirección de expansión seleccionada es Rimnicu Vilcea
Timisoara: 447 = 118+329
Zerind: 449 = 75+374
Arad: 646 = 280+366
Fagaras: 415 = 239+176
Oradea: 671 = 291+380
Craiova: 526 = 366+160
Pitesti: 417=317+100
Sibiu: 553 = 300+253
En este caso, la ruta no se expande en ninguna de las direcciones que han surgido de expandir Rimnicu Vilcea, sino que el algoritmo da “un paso atrás” y selecciona la ruta que llevaba a Fagaras para su expansión
Expandiendo Fagaras:
Timisoara: 447 = 118+329
Zerind: 449 = 75+374
Arad: 646 = 280+366
Oradea: 671 = 291+380
Craiova: 526 = 366+160
Pitesti: 417=317+100
Sibiu: 553 = 300+253
Bucarest: 450 = 450+0
Sibiu: 591 = 338+253
En esta tanda de expansión de rutas, se producen dos eventos destacables. Primero, Sibiu aparece otra vez. Esta segunda aparición se debe a en este momento se han descubierto dos rutas distintas, y ambas llevan a Sibiu desde Arad, siguiendo diferentes caminos de diferentes longitudes. El segundo evento es que Bucarest, el destino, aparece entre los posibles destinos de la expansión. No obstante, el valor que lleva hasta ella no es el mínimo, y por tanto no se expande la ruta en esa dirección. En su lugar la ruta se expande hacia Pitesti. Existe la posibilidad de que a través de Pitesti se
Tras la expansión de Pitesti:
Timisoara: 447 = 118+329
Zerind: 449 = 75+374
Arad: 646 = 280+366
Fagaras: 415 = 239+176
Oradea: 671 = 291+380
Craiova: 526 = 366+160
Sibiu: 553 = 300+253
Bucarest: 450 = 450+0
Sibiu: 591 = 338+253
Bucarest: 418 = 418+0
Craiova: 615 = 455+160
Rimnicu Vilcea: 607 = 414+193
Nuevamente aparece una ruta hacia Bucarest entre las posibles. Su función de evaluación es en efecto menor que la que se había calculado antes, de hecho es la menor de todas las que se habían calculado. Eso significa que la ruta se expande en esa dirección y que se ha llegado al destino. Por tanto, el algoritmo se detiene y la ruta mínima queda como:
4.5. Tecnologías
4.5.1. PDA (Personal Digital Assistant)
Las PDA (Personal Digital Assistant) han evolucionado desde su origen como simples organizadores electrónicos a dispositivos extremadamente completos, que pueden perfectamente describirse como ordenadores de bolsillo. Actualmente, el rango de funciones que es habitual encontrar en una PDA engloba una agenda, organizador, calculadora, acceso a Internet mediante wireless, sincronización con una base de datos, grabación de sonido, y envió de mensajes a móviles. Es así mismo cada vez más frecuente la inclusión de dispositivos receptores GPS, lo cual les ha otorgado todo un nuevo rango de funcionalidades, incluyendo localización global, navegación GPS y uso de sistemas de autorouting.
Como ya se ha mencionado, el propósito del proyecto desarrollar una aplicación que sea capaz de funcionar sobre una plataforma PDA típica con capacidades GPS. Entre las diferentes arquitecturas de PDA existentes en el mercado se ha seleccionado para este desarrollo la plataforma de Microsoft Pocket PC. Esto es debido a que es posiblemente la plataforma PDA actualmente más extendida, gracias especialmente al uso de Windows Mobile como su sistema operativo. Windows Mobile fue desarrollado por Microsoft a partir de Windows CE, el sistema operativo Windows para microordenadores y sistemas integrados. Windows CE no es una versión recortada del Windows de
escritorio sino que emplea un kernel propio. El emplear Windows Mobile provee al Pocket PC de múltiples funciones de interacción con los sistemas Windows de escritorio y con otras herramientas de Microsoft como Outlook y el paquete Office.
Entre las diferentes versiones de Pocket PC se ha empleado para el desarrollo de la aplicación Pocket PC 2002, aunque esto es únicamente a su compatibilidad con las herramientas de desarrollo que se han utilizado en el proyecto. La aplicación a desarrollar es compatible con cualquier versión de la plataforma Pocket PC, y puede ser portada a cualquiera de las otras versiones de la plataforma de modo inmediato.
4.5.2. SVG (Scalable Vector Graphics)
Para poder ejecutar un análisis y tratamiento de imagen al nivel que el sistema desarrollado requiere para la realización de sus funciones, es necesario estar trabajando con una representación vectorial de la imagen analizada.
Las imágenes representadas en un formato digital pueden estar en dos formatos básicos, de los cuales derivan todos los demás formatos existentes.
Los formatos ráster, guardan la imagen como una superficie de píxeles, almacenando el color y la posición de cada píxel de la imagen. Esto produce una fidelidad perfecta con la imagen original, pero resulta en archivos de gran tamaño. Además, debido a la falta de “inteligencia” del archivo, es imposible extraer datos de los que representa por programas de análisis de imagen sin emplear un gran número de cálculos.
El formato vectorial, por otra parte, guarda datos que describen lo que la imagen representa. Es decir, almacena las coordenadas, ángulos, dimensiones y colores de los elementos representados en la imagen. Esto puede lleva a una perdida de características particularmente complejas de la imagen, pero resulta mucho más manejable desde un punto de vista computacional. Así, los gráficos vectoriales se emplean para convertir diseños gráficos a programas de CAD, o reconocimiento de texto en imágenes. El sistema que se está desarrollando
también se ve beneficiado por las posibilidades de análisis directo de la imagen que proporciona el formato vectorial.
De entre el gran rango de formatos vectoriales existentes se ha seleccionado para el desarrollo del proyecto el estándar SVG (Scalable Vector Graphics). SVG es un estándar desarrollado por el World Wide Web Consortium, responsable de algunos de los más importantes estándares del mundo de la informática, incluyendo HTML y XML.
El principal motivo de la selección de SVG como formato de imagen vectorial del proyecto es el hecho de que, internamente, es en realidad un documento XML con un cierto formato. Esto permite al sistema acceder directamente a los datos de la imagen a través de simples funciones de interacción con XML.
En un principio pensaba emplearse la implementación SVGBasic, una versión del formato especialmente pensada para su uso en sistemas empotrados y dispositivos portables, como es el caso de la plataforma PDA. No obstante, debido a la división del sistema desarrollado en dos módulos, los archivos SVG nunca llegan ser empleados sobre la plataforma PDA.
4.5.3. AutoTrace
Para poder trabajar sobre una imagen de un mapa de carreteras es que esa imagen se trate de imagen vectorial, y en formato SVG, que es el formato que el sistema esta desarrollado para reconocer. Pero el propósito del proyecto es permitir al usuario emplear como mapa de carreteras base cualquier imagen, no sólo una que ya se encuentre en el formato adecuado, lo cual no ocurrirá frecuentemente. De hecho, es lógico esperar que el usuario dispondrá de la imagen del mapa en un formato ráster. Es por ello necesario convertir la imagen del mapa de carreteras que se está analizando al formato empleado por el sistema antes de empezar el propio análisis.
Para ello es necesario un elemento, comúnmente denominado como motor de vectorización, que realice esta conversión. Se ha considerado que el desarrollo de un motor de vectorización propio queda fuera del alcance del proyecto, de hecho un desarrollo de este calibre podría ser considerado en sí mismo como un proyecto de fin de carrera entero. Por ello, se ha optado por adoptar en el proyecto un motor de vectorización ya desarrollado. Para esta tarea se ha seleccionado el proyecto AutoTrace.
AutoTrace es un el resultado de un proyecto desarrollado con el propósito de crear un motor de vectorización libremente disponible con capacidades similares a las de aplicaciones comerciales como CorelTrace y Adobe Streamline. De hecho, es ya superior en múltiples aspectos. Autotrace
es además, gratuito, tiene código abierto y es multiplataforma. Se distribuye bajo la licencia GNU GPL. Autotrace fue seleccionado al ser un programa gratuito, con un funcionamiento lo suficientemente eficaz y eficiente para los requisitos del proyecto y que tenía soporte para la generación de ficheros SVG como salida directa.
4.5.4. BMP
Windows Bitmap es sin duda el formato de imagen ráster más popular y simple que existe. Su nombre no debe llevar a la confusión de que este formato es empleado únicamente sobre sistemas Windows. Es por esto por lo que se ha decido unificar los formatos de entrada del programa como BMP, siendo esta la entrada que se le proporciona al Módulo Enrutador como archivo a analizar y la que se pasa al motor de vectorización AutoTrace, agilizando así el análisis del mapa sin necesidad de conversiones de tipo previas a un formato interno único.
No cabe duda de que el usuario va a poder convertir a este formato cualquier mapa que pueda poseer en cualquier otro formato de imagen, pues básicamente todos los programas de tratamiento de imagen, incluyendo los gratuitos como Gimp y Paint, que se encuentra en todo ordenador con un sistema operativo Windows, permiten esta simple conversión. Además, BMP es el principal formato producido por los equipos de escaneo de imágenes, método que se espera sea uno de los principales para la generación de imágenes de mapa que vayan a ser empleadas por el sistema.
4.5.5. XML (Extensible Markup Language)
XML (Extensible Markup Language) es uno de los más importantes estándares del mundo informático. Fue desarrollado por el World Wide Web Consortium, al igual que el formato de imagen vectorial que fue seleccionado para ser empleado por el proyecto, SVG. El propósito con el cual fue desarrollado el XML era el ser un lenguaje de etiquetas generalista que se empleara para desarrollar lenguajes de etiquetas especializados. Seguir este estándar facilitaría la interacción entre programas originalmente incompatibles, y el compartimiento de información, especialmente a través de Internet.
Siguiendo esta filosofía, el sistema desarrollado hace un uso extensivo de XML, recurriendo a él cada vez que tiene que manejar o escribir datos a o desde fuentes externas.
Debido a que SVG es internamente un documento XML como ya se ha descrito, toda la interacción de la aplicación con la imagen una vez vectorizada se hace a través de XML. También se ha empleado XML para codificar los datos del Grafo de Rutas en el documento que el Módulo Vectorizador prepara para transmitir al Módulo Enrutador. Este último también codifica los datos
guardan en un archivo de configuración que también esta codificado en XML.
4.5.6. Microsoft Visual Studio .NET
La plataforma de desarrollo central para la programación del proyecto que se ha seleccionado es Microsoft Visual Studio .NET 2003. Se ha decidido emplear este entorno en particular debido a que fue utilizado para la realización de diversas prácticas durante la carrera. Aprender a utilizar un nuevo entorno de programación hubiera robado tiempo al desarrollo principal del proyecto y hubiese sido considerablemente costoso puesto que el entorno .NET 2003 ya se poseía antes del inicio del desarrollo de proyecto. Por último, el propio .NET proporciona un entorno de desarrollo para microordenadores y para la plataforma Pocket PC 2002 y el sistema operativo Windows CE en particular.
Desde un punto de vista de la programación del sistema, el proyecto no requiere de ningún requisito especial que fuerce el empleo de un entorno alternativo. Por estos mismos motivos es por los que tampoco se ha empleado la recientemente publicada última versión del entorno, Microsoft Visual Studio 2005.
4.5.7. C#
C# es un lenguaje orientado a objetos desarrollado por Microsoft a partir de C++ como parte de su iniciativa .NET. Adopta conceptos de otros lenguajes, principalmente Delphi, Visual Basic y Java, buscando principalmente crear un lenguaje cuyo funcionamiento y requisitos fuesen simples.
C# se ha seleccionado como lenguaje de programación para el proyecto, al igual que la plataforma de desarrollo .NET, por el hecho de la practica que con él se ha obtenido durante la carrera, tanto directamente como de forma sinérgica a través del trabajo con Java, lenguaje con el que comparte un elevado número de similitudes. C# es así mismo posiblemente el lenguaje más fiable, directo y estable de los presentados por el entorno .NET.
Capitulo 5 - Desarrollo del Sistema GPS
5.1. Decisiones de Diseño
Aunque el planteamiento inicial de la aplicación era que funcionara enteramente sobre una plataforma Pocket PC, se ha decidido realizar el proceso de tratamiento de imagen del mapa de forma independiente sobre plataforma PC. Esto es principalmente debido a que el proceso de vectorización es muy pesado y tiene elevados requisitos de memoria y una gran cantidad de cálculos matemáticos considerablemente complejos con lo que ejecutarlo sobre una plataforma tan limitada como un Pocket PC resulta del todo imposible. Por este hecho precisamente es por lo que además ha sido imposible obtener un motor de vectorización preparado para su funcionamiento sobre Pocket PC.
Puesto que este proceso idealmente solo necesitará realizarse una vez por cada mapa que vaya a emplear el usuario y no requiere de interacción con el dispositivo GPS del Pocket PC, se ha decidido desarrollar un módulo para plataforma PC que realizará el proceso de tratamiento de imagen y generación del grafo y generará un documento XML del que el módulo enrutador extraerá la información necesaria para trabajar. Puesto que el proceso de localización del mapa en unas coordenadas geográficas determinadas requieren del uso del dispositivo GPS, este proceso en particular sea realizado por el Pocket PC, y sus datos serán insertados en el documento XML.
De este modo, la división en dos módulos de funcionamiento queda como sigue. El módulo desarrollado para PC, denominado Módulo Vectorizador engloba todas las tareas relacionadas con el tratamiento de la imagen. Eso significa que será el único interactuará con el motor de vectorización AutoTrace y con la versión vectorial del mapa, el archivo SVG. El Módulo Vectorizador está enteramente orientado al desarrollo de un grafo de rutas correcto y fiable que represente el mapa de carreteras, y esta diseñado para comprimir el resultado de todo su trabajo en un único documento XML que es leído por el otro módulo.
El segundo módulo, desarrollado para una plataforma Pocket PC se denomina Módulo Enrutador. La única relación que tiene el Módulo Vectorizador es el documento XML del que lee los datos relativos al Grafo de Rutas. De este, el módulo debe extraer de ese archivo, y de la imagen original, que también se introduce para que el usuario indique los puntos entre los que requiere que se calculen las rutas mínimas, todos los datos necesarios para su completo y correcto funcionamiento. El principal propósito del Módulo Enrutador es el cálculo de las rutas que el usuario requiera. El Módulo Enrutador, al estar incorporado en la PDA es así mismo el que interactúa con el
hacer sobre el documento.
5.2. Diseño de la Aplicación
Desde el punto de vista puramente de la arquitectura, el proyecto es considerablemente simple. El peso del desarrollo recae sobre el desarrollo e implantación de los algoritmos empleados por el sistema y sobre el uso de diferentes técnicas de tratamiento de imágenes. Como resultado, la mayor parte de los diagramas de diseño no aportan una cantidad de información significativa sobre el proyecto.
Se incluyen a continuación los diagramas que se han considerado como significativos en la aplicación. Los diagramas incluidos contienen una representación externa de los dos módulos de los que se compone la aplicación y de la relación existente entre ellos, y una representación interna de su funcionamiento en forma de Diagramas de Flujo de Datos. Se incluye así mismo el Diagrama de Secuencia del proceso de análisis de la imagen y generación del Grafo de Rutas, pues éste es el proceso de mayor volumen y más complejo de la aplicación.
5.2.1. División en módulos
Módulo PC Vectorizador
Módulo PDA Enrutador Documento XML
5.2.2. Diagrama de Flujo de Datos del Módulo Vectorizador
5.2.3. Diagrama de Flujo de Datos del Módulo Enrutador
5.3. Grafo de Rutas
Un grafo es una estructura abstracta central de la teoría de grafos que representa una serie de relaciones entre elementos, y que se emplea en multitud de algoritmos matemáticos. Suele representarse como un conjunto de puntos denominados vértices o nodos conectados entre sí mediante una serie de líneas denominadas aristas o arcos. Generalmente, se suele definir matemáticamente como la combinación de dos conjuntos:
N es un conjunto de vértices o nodos
A Æ N x N es un conjunto de pares de nodos llamados arcos o aristas
Dentro de esta definición, se define a un grafo como no dirigido si los arcos son pares no dirigidos y grafo dirigido o dígrafo si lo son.
El Grafo de Rutas es el principal elemento del algoritmo de cálculo de rutas mínimas. Se trata de un grafo no dirigido que representa una abstracción del mapa de carreteras, reduciendo todos sus datos a únicamente aquellos que resultan importantes en el proceso de cálculo de rutas. Está compuesto por una
puede determinar el nodo cuyas coordenadas más se ajustan al del punto requerido por el usuario. Los arcos como ya se ha dicho, representan carreteras, pero como es natural en los arcos, son representados en el plano del grafo como líneas rectas, por lo que normalmente no se ajustarán a la carretera que representan, a menos que esa carretera sea también una línea recta. No obstante, tanto la carretera como el arco empezarán y terminarán en las mismas coordenadas.
Desde un punto de vista computacional, los datos asociados a los nodos son sus coordenadas sobre el plano del grafo, y el conjunto de arcos que pasan por ellos. Así mismo, mediante funciones asociados a ellos, los nodos pueden identificar a sus nodos vecinos, de modo que se puede decir que estos también son parte de los datos asociados a un nodo.
Los datos asociados a los arcos son su longitud y los nodos entre los cuales está trazado. La longitud es la misma que la de la carretera a la que representa, a pesar de que su trazado no coincida con ésta. En el caso de un arco que haya sido generado como parte del proceso de refinado o por parte del usuario mediante el editor de grafo, su longitud es la misma que la del propio arco, es decir, la del segmento que une los dos puntos sobre los que esta trazado. En el caso particular de dos arcos que hayan sido generados al dividir un arco en dos mediante la herramienta del editor de grafo para añadir nodos, la longitud de cada uno de los arcos resultantes es igual a un porcentaje
de la longitud total del arco del que provienen, de modo que la suma de sus longitudes sigue siendo la misma que la del arco original.
Como ya se ha definido, el grafo de rutas es un grafo no dirigido. Esto significa que las rutas que se pueden trazar pueden recorrer los arcos en cualquier sentido, lo que a su vez implica que el algoritmo de trazado de rutas considera que todas las carreteras son de doble sentido. Esto no es un problema en el caso de carreteras fuera de vía de ciudad, pues ese suele ser el caso. Al tratar mapas metropolitanos no obstante, esta limitación del grafo provoca que sea poco útil para desplazamientos en coche. Un peatón, por otro lado, podría seguir usando el mapa para calcular las rutas que requiera sin problemas.
Se considero en un momento del desarrollo del proyecto el empleo de un grafo dirigido para resolver este problema. No obstante, esta posibilidad se descartó posteriormente por varios motivos. El principal de estos motivos es el hecho de que el único modo para indicar a cada arco en que sentido discurría la calle que representaba era haciendo que el propio usuario lo indicase.
Además de que insertar el sentido correspondiente a todos los arcos del grafo es una tarea extremadamente pesada y lenta a la que definitivamente no se
5. 4. Módulo Vectorizador
El Módulo Vectorización es el primer módulo de los dos en los que se ha dividido el proyecto. Realizando su funcionamiento normal, tomara un mapa en un formato BMP, lo someterá a un proceso de análisis que resultará en la creación de un Grafo de Rutas que contendrá toda la información representativa para el cálculo de rutas sobre el mapa, refinará este grafo tanto por si mismo mediante una serie de algoritmos automatizados, como mediante acción directa y voluntaria del usuario, y codificará todo esta información en un documento XML con un cierto formato propio que será leído por el otro módulo para la realización de sus propias funciones.
El Módulo Vectorizador ha sido desarrollado para su uso sobre una plataforma PC. Esto es debido a varios motivos que o bien justifican que las tareas que va a realizar el módulo funcionarán mejor si se desarrolla sobre PC o bien directamente impiden que se desarrolle para una plataforma PDA con éxito. Primero, la realización de las tareas que se han asignado al Módulo de Vectorización requiere interactuar con un motor de vectorización, un tipo de aplicación que no existe en un formato portable. El desarrollo de un motor de vectorización propio para su funcionamiento en combinación con el sistema es una actividad que se ha considerado se encuentra fuera del alcance del proyecto. Además, existen motivos lógicos por los que no existe una versión para PDA de ningún motor de vectorización. La vectorización es un proceso muy pesado que requiere de un número elevado de operaciones matemáticas
considerablemente complejas, resultando del todo inviable sobre una plataforma tan limitada como una PDA.
Si bien este es un motivo por el cual no implantar la vectorización sobre la PDA, existen otros motivos por los cuales implantar el módulo en una plataforma PC. Es esperable que la generación del Grafo de Rutas de un determinado mapa se realice únicamente una vez por cada mapa con el que se quiera trabajar. Así mismo, es esperable que la principal vía a través de la cual van a obtenerse los mapas que van a ser empleados para el cálculo de rutas mínimas sea el propio PC del usuario, de modo que ya puede directamente, al tiempo que obtiene los diferentes mapas que desea emplear, prepararlos para su uso por parte del sistema de cálculo de rutas. Por último, la vectorización en sí no requiere de ninguna interacción con el dispositivo GPS. Por todos estos motivos parece evidente que este proceso debe ser realizado por parte del PC que luego pasará sus resultados a la PDA.
5.4.1. Tratamiento de la imagen
El principal propósito del Módulo Vectorizador es analizar la imagen del mapa para localizar las carreteras, calcular sus parámetros y generar el grafo de rutas a emplear por parte del dispositivo GPS.
5.4.1.1. Identificación de carreteras
Se ha considerado que el método más eficaz para identificar las carreteras, que en cuestiones de aspecto son extremadamente similares a otros elementos geográficos que podían fácilmente inducir a confusión por parte del algoritmo de conversión como ríos, líneas de coordenadas o texto de gran tamaño era mediante la intervención por parte del usuario. Así, antes de ejecutar la conversión, el usuario define que elementos son vías de circulación en el mapa. Para identificarlas, se ha considerado que debido al modo en el que se representan habitualmente las vías de circulación en los mapas de carreteras, el mejor modo era por la identificación del color que se emplea para dibujar cada uno de los tipos de vía. Así, lo único que tiene que hacer el usuario señalar mediante un simple clic sobre las propias vías de circulación los colores que se corresponden con los diferentes tipos de vías de circulación presentes en el mapa y que el usuario desea que sean incluidas en el cálculo del Grafo de Rutas.
5.4.1.2. Tratamiento en fases de la imagen
El proceso de tratamiento de imagen empleado para generar el grafo a partir del mapa de carreteras proporcionado ha sido dividido en varias fases para así simplificar la realización de pruebas sobre el código, la incorporación de modificaciones y la expansión del algoritmo. El resultado de cada una de estas fases es la entrada de la siguiente. Estas fases, están conceptualmente diferenciadas, debido a que realizan tareas claramente distintas ya sea sobre los datos de imagen original, la versión vectorizada de la imagen o el propio Grafo de Rutas, pero son de todos modos continuas e inseparables. Cuando se da al Módulo Vectorizador la orden de generación del Grafo de Rutas, se ejecutan todas las fases de forma continua. Debido a esto, la ejecución de cada una de las fases por separado resulta transparente a usuario.
Todas las fases trabajan bien sobre archivos temporales o bien sobre variables internas del programa. De este modo, la imagen de mapa original nunca se ve alterada.
5.4.1.2.1 Pretratado
Inicialmente la imagen recibe un proceso de pretratado orientado a simplificar su manipulación por parte del motor de vectorización. Inicialmente se reduce la imagen a una representación en blanco y negro en el que únicamente se ven representados los colores que han sido definidos por el usuario como pertenecientes a vías de circulación. Puesto que, debido normalmente a la falta de calidad de la imagen, es frecuente que una forma cuyo color en un primer momento era constante se haya visto convertido en una amalgama de diferentes tonalidades con pequeñas variaciones entre sí, se consideran como el mismo color aquellos que se encuentren dentro de una cierta similitud con un color definido como vía. Esta similitud se determina como la diferencia entre los valores de los diferentes bytes de colores, y la similitud mínima puede ser definida por el usuario de a cuerdo a sus necesidades y la calidad de la imagen. En sí, el sistema utiliza un sistema de colores de 32 bits, el proporcionado por el propio objeto Color de las librerías de C#, aunque el byte de Alpha no se emplea en absoluto, con la definición de color que realmente se está empleando durante el pretratado es de 24 bits.
A la imagen en blanco y negro resultante del pretratado se le aplican a continuación un filtro de sal y pimienta para eliminar el ruido que el tratamiento pueda haber introducido y un filtro de bordes que realza las vías.
5.4.1.2.2. Vectorización Mediante Autotrace
Para realizar el proceso de convertir la imagen de su formato ráster BMP al formato vectorial SVG, sobre el que se podrá trabajar de forma directa, se emplea el motor de vectorización AutoTrace. Esto no significa, no obstante, que no se tenga ningún control sobre el modo en que se realiza la conversión debido a que el proceso se ejecute de forma externa al código de la aplicación.
Autotrace permite varios parámetros de configuración que determinarán el modo en que se ejecutará la vectorización. Estos parámetros se han ajustado a los valores que se ha determinado que producirán los mejores resultados cuando sean aplicados sobre un mapa de carreteras habitual. No obstante, pueden ser modificados a voluntad por el usuario. La aplicación recuerda los valores introducidos y también es capaz de restaurar los valores predeterminados.
Los parámetros de control del motor de vectorización AutoTrace están recogidos en la siguiente tabla. Es importante notar que los valores que se define aquí como predeterminados son los predeterminados que emplea el Módulo Vectorizador, calculados tras probar el ajuste de múltiples de mapas de carreteras, y no los valores predeterminados de Autotrace, que tienen un
Nombre Tratamiento Valor Descripción
Background Color Constante FFFFFF (Blanco)
Define un color de la imagen como fondo, lo que implica que será ignorado durante la vectorización. Puesto que después del pretratado es una representación de las vías en negro sobre un fondo blanco cuyas características no son importantes para el sistema, se define ese color como fondo.
Centerline Constante True
Normalmente, AutoTrace almacena las características del mapa como una serie de formas definidas por una línea de borde y el color que llena el área que delimita. Al emplear esta opción, Autotrace representará los elementos de la imagen como líneas de un determinado grosor y un determinado color. Este modo es mucho más manejable por parte del sistema puesto que el propósito de la digitalización es precisamente la extracción de datos relativos a líneas.
Color Count Constante 1
Si se emplea este parámetro en la vectorización, AutoTrace reducirá el número colores de la imagen al tratarla, simplificando así la salida que produce y evitando la aparición de colores no deseados, como tonos de gris, en la imagen al aplicar filtros. Puesto que el negro es el único color de la imagen aparte del blanco, que como color de fondo es ignorado, la reducción de se limita a un solo color.
Corner Threshold Variable 150
Si en un determinado píxel, sus predecesores y sus sucesores forman un ángulo menor que éste, entonces se considera como una esquina, en otro caso se considera una curva. No obstante, si se encuentra dentro del radio de píxeles de Corner Surround de otra esquina, entonces no se considera como esquina propia sino como parte de otra esquina.
Corner Surround Variable 4
Determina cuantos píxeles serán analizados en torno a uno punto determinado para juzgar si ese punto es una esquina. Debido a esto, también determina como de “grandes” son las esquinas.
Corner Always Threshold
Variable 90
Si el ángulo presente en un píxel con potencial de ser esquina es menor que el valor de este parámetro, entonces en ese píxel hay una esquina, a pesar de que pueda encontrarse dentro del radio de Corner Surround de otra
