ShadedPath: aplicación Android para calcular rutas peatonales con mínima exposición solar

1 2 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADUADO EN INGENIERÍA DEL SOFTWARE ShadedPath: aplicación Android para calcular rutas peatonales con mínima exposición solar (ShadedPath: Android application to compute pedestrian routes with minimal sun exposure) Realizado por Antonio Manuel Rivas Fuentes Tutorizado por Dr. José Francisco Chicano García Departamento Lenguaje y Ciencias de la Computación UNIVERSIDAD DE MÁLAGA MÁLAGA, OCTUBRE 2015 Fecha de defensa: El Secretario del Tribunal 4 Resumen: El trabajo de fin de grado consiste en realizar una aplicación móvil basada en Android [7]. Para calcular la ruta más sombreada desde un punto de origen a un punto de destino. Dicha aplicación móvil realizará peticiones a un servidor que estará ejecutando un programa que realizará el cálculo de rutas conforme a los parámetros que elegirá el usuario desde su móvil. Estos parámetros pueden ser: la hora de partida, la fecha y la importancia de la sombra a la hora de calcular la ruta. Siempre podremos elegir entre una ruta más corta o una más sombreada, según la importancia que le quiera dar el usuario. La lógica de la aplicación del lado del servidor que realiza el cálculo está basada en OpenTripPlanner, el cual usa algoritmos de búsqueda para encontrar el camino más corto. Sirviéndonos de dicho algoritmo realizaremos las modificaciones e implementaciones necesarias para calcular la ruta más sombreada. Palabras Clave: algoritmo de búsqueda, open trip planner, sombra, aplicación móvil, Android Abstract:This project focuses on developing an Android mobile application that calculates the most shaded route between an origin and target location. The user can set preferences through this mobile application. The application will make requests to a server that will be executed in an external machine. The preferences are: departure time, date and the importance that a shadow route might be to the user. The server-side application that computes routes is based on OpenTripPlanner platform. This application uses search algorithms to find the shortest path between two locations. We extend the functionality of this algorithm to the needs of our project. Keywords: search algorithm, open trip planner, shadow, mobile application, Android 5 6 Índice general 1. Introducción 11 1.1. Aclaracionesprevias .............................. 11 1.2. Definición .................................... 12 1.3. Preliminares................................... 13 1.3.1. Modelos digitales de terreno y superficie . . . . . . . . . . . . . . . 13 1.3.2. Sistemas de coordenadas Universal Transversal Mercator . . . . . . 14 1.3.3. World Geodetic System (WGS84) . . . . . . . . . . . . . . . . . . . 23 1.3.4. Conceptos astronómicos . . . . . . . . . . . . . . . . . . . . . . . . 24 1.3.4.1. Acimut ............................ 25 1.3.4.2. Elevación del sol . . . . . . . . . . . . . . . . . . . . . . . 27 1.4. Fasesdelproyecto................................ 28 1.5. Métodos materiales utilizados . . . . . . . . . . . . . . . . . . . . . . . . . 29 2. Análisis 31 2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3. Cálculo de la ruta 35 3.1. Datosdeentrada ................................ 35 3.1.1. Los datos de alturas a partir de los modelos digitales . . . . . . . . 36 3.1.2. Cálculo y ajuste de los datos de los modelos digitales de superficie . 39 3.1.3. Cálculo de la altura angular de las coordenadas . . . . . . . . . . . 41 3.2. Algoritmo de búsqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.2.1. Funcionamiento del Algoritmo A* en el grafo . . . . . . . . . . . . . 49 3.3. La plataforma OpenTripPlanner para el cálculo de la ruta . . . . . . . . . 53 7 3.3.1. Cálculo del tiempo de exposición solar . . . . . . . . . . . . . . . . 57 3.3.2. Plandeviaje .............................. 59 4. La aplicación móvil 65 4.1. La estructura de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.1.1. La Action Bar ............................. 68 4.1.2. Información de la ruta y las distintas etapas . . . . . . . . . . . . . 70 4.1.3. Notificación de errores y excepciones . . . . . . . . . . . . . . . . . 72 5. Conclusiones 75 5.1. Valoracionesfinales............................... 75 5.2. Trabajofuturo.................................. 76 A. Manual de instalación 79 A.1.Puestaenmarcha................................ 79 A.1.1. Arrancar desde línea de comandos . . . . . . . . . . . . . . . . . . . 79 A.1.2. Establecer el entorno a través de un IDE . . . . . . . . . . . . . . . 80 A.1.3. Interfaz web para probar el cálculo de rutas . . . . . . . . . . . . . 81 B. Aplicaciones adjuntas 83 B.1. OrderAndNormalizeMDSFile . . . . . . . . . . . . . . . . . . . . . . . . . . 83 B.2.AngleElevationFile ............................... 84 Bibliografía 87 8 9 Figura 1.3: Las figura muestra el resultado de la proyección UTM sobre el meridiano de Greenwich (en la parte superior el hemisferio correspondiente al antimeridiano 180oy en la parte inferior el hemisferio correspondiente al propio meridiano 0o). Sin embargo surgen algunos inconvenientes con este formato y es que no existe una uniformidad en la escala de distancias. Esto quiere decir que a medida que nos alejamos del punto de tangencia esfera-cilindro en la dirección perpendicular al cilindro, las distancias se agrandan como podemos observar en la Figura 1.3. Este problema se soluciona con la introducción de los husos. Se procede a dividir la superficie terrestre en 60 husos o zonas iguales de 6grados de longitud. Con esto se tiene 60 proyecciones iguales, pero cada una con su respectivo meridiano central. Los husos se numeran del 1al 60 comenzando desde el antimeridiano de Greenwich (180o) hacia el este. De este modo el huso comprendido entre 180oWy174oWes el primero. El huso comprendido entre 6oWy0oEes el 30, en el que queda el cuadrante nororiental de la península ibérica. Esto se puede apreciar mejor en la Figura 1.4. A su vez dentro de cada huso se establece una división en zonas. Cada zona posee 8o de latitud y 6ode longitud. Se designa cada una con el número de su huso y una letra mayúscula. El resultado final es una cuadrícula como la que se muestra en la Figura 1.5. 16 Figura 1.4: Las figura muestra el resultado de la proyección UTM sobre el meridiano de Greenwich (en la parte superior el hemisferio correspondiente al antimeridiano 180oy en la parte inferior el hemisferio correspondiente al propio meridiano 0o). Figura 1.5: Cuadrícula UTM Para denominar las zonas se usa, como se dijo, una letra mayúscula. Para ello se ha seguido la dirección de Sur a Norte partiendo de la letra Csiguiendo el orden alfabético a excepto de las vocales y las letras que pueden confundirse con un número: la B, la Oy la letra P. Las zonas entre la My la Xcorresponden al hemisferio Norte, y las zonas entre la Cy la Lal hemisferio Sur. Como excepción, la zona Xposee 12ode latitud y se extiende desde los 72oNhasta los 84oN. 17 En la imagen anterior se observa que la Península Ibérica abarca 6zonas: 29T,30T,31T, 29S,30S y31S. Ahora para definir la geometría del huso consideraremos a modo de ejemplo el huso 31 donde se ubica la Península Ibérica. Este huso 31 se prolonga desde los 0ohasta los 6o. En general todos los husos poseen un meridiano central que los divide en 2partes iguales con una longitud de 3oE. El meridiano central se utilizará en la proyección UTM de cada huso. La proyección UTM no recoge latitudes superiores a los 84oNni a los 80oS. La primera zona de letra Xaparece entre los 84oNy los 72oNde latitud. La última aparece con la letra Centre los 72oSy los 80oS. 18 Figura 1.6: Geometría del huso Como se ilustra en la Figura 1.6, este sería el resultado de proyectar el huso 31 según su meridiano central (3oE). Como se observa, éste lo divide en dos partes iguales. Esto permite establecer dos ejes cartesianos XeYsobre el huso, de tal manera que el eje X es el ecuador y el eje Yel meridiano central. Estos ejes cartesianos permiten determinar puntos sobre el huso haciendo uso de dos coordenadas rectangulares XeYque se denominan coordenadas UTM. El origen del sistema de coordenadas UTM se encuentra por tanto, en la intersección del Ecuador con el antimeridiano de Greenwich. Cada huso posee su propio origen de coorde19 nadas donde el paralelo del Ecuador es el origen Yy la coordenada Xcorresponde con el meridiano central del huso, que en la Figura 1.6 vemos que es 500.000 (entre 0oEy6o E). La idea de las coordenadas UTM es que sus dos valores X e Y sean siempre positivos. Por ello no se ha elegido las coordenadas X=0 e Y=0 para el origen. Cada zona UTM es expresada por el número de huso del 1al 60 y una letra de zona de CaX. Se descompone a su vez en regiones rectangulares de 100km de lado por lo tanto eso da una superficie de 10.000km2. Cada cuadrado de 100km de lado se designa mediante una pareja de letras mayúsculas. Dando lugar a una cuadrícula hectokilométrica, que en el caso de la península ibérica tendría el siguiente aspecto: Figura 1.7: Cuadrícula UTM España La primera letra de la designación de los cuadrados de 100km expresa la posición a lo largo de un meridiano en el huso. La segunda letra expresa la posición del cuadrado a lo largo de un paralelo. Así, la designación 30T UN permite identificar un cuadrado de 20 100km de lado en la superficie terrestre. La letra Uexpresa la posición del cuadrado en la dirección Este-Oeste y la letra Nen la posición Norte-Sur. El siguiente cuadrado de 100km a la derecha de UN será VN. El cuadrado de 100km al norte será UP, mientras el que se encuentra al sur será UM. El Instituto Nacional de Geografía (IGN) dispone de mapas topográficos, en los cuales se puede observar con más detenimiento el uso de este formato. Figura 1.8: Ejemplo de mapa topográfico del IGN Concretamente, en la Figura 1.8, se observa la cuadrícula UTM. Cada cuadrado posee un área de 1km2. 21 Figura 1.9: Detalle de una cuadrícula UTM Para hacer referencia a cada punto de la cuadrícula UTM, se usan dos valores llamados coordenadas. Existe una coordenada Xque expresa un valor en metros sobre la horizontal, mientras que la coordenada Yhace lo propio sobre la vertical del plano. En la Figura 1.9 se representa un segmento de cuadrícula UTM. Cada cuadrado representa una extensión de 1km2. La coordenada Xrepresenta una distancia sobre la horizontal y va tomando valores en metros: 520.000,521.000,522.000, etc... a intervalos de 1.000m (1km). La coordenada Yrepresenta una distancia sobre la vertical y va tomando los valores en metros 4.670.000,4.671.000,4.672.000, etc... a intervalos de 1.000m (1km). La posición del punto Ase expresa mediante las coordenadas X e Y de su intersección sobre la cuadrícula. Este es el caso más sencillo pero no el más frecuente. 22 Lo más común sería encontrarnos un punto como el B, el cual no se sitúa en ningún vértice de la cuadrícula. En este caso si nos fijamos en el punto Cde coordenadas X=525.000 e Y=4.670.000 en el vértice de la cuadrícula deberemos medir la distancia horizontal y vertical hacia el punto B. Si para esta distancia horizontal se obtienen 800m, la coordenada X será 525.000+800=525.800, mientras que para la Yserá 4.670.000+700=4.670.700. Por consiguiente la coordenada Xaumenta hacia el Este y la coordenada Yaumenta hacia el Norte5. Ya hemos definido el formato UTM el cual define las coordenadas XeY. Existe un tercer valor que es la coordenada Zy es el que nos otorgará la elevación en ese punto geográfico. Este nuevo valor expresa su cota o altitud con respecto al nivel del mar en metros. Por ejemplo si el punto Ase halla a 872m sobre el nivel del mar, equivaldrá a Z=872. Este valor estará en formato WGS84 que detallaremos en la sección que viene a continuación. 1.3.3. World Geodetic System (WGS84) El formato World Geodetic System (WGS84) [3] se basa en un patrón matemático en 3 dimensiones que busca representar la tierra por medio de un elipsoide. Es un sistema de referencia terrestre único para referenciar las posiciones y vectores. Se estableció utilizando observaciones Doppler al sistema de satélites de navegación NNSS oTransit, de tal forma que se adapta lo mejor posible a toda la Tierra. Se define así mismo como un sistema cartesiano geocéntrico de la siguiente manera: Origen, centro de masas de la Tierra, incluyendo océanos y atmósfera. Eje Zparalelo a la dirección del polo CIO o polo medio definido por el BIH, época 1984 con una precisión de 0,005". El eje Xes la intersección del meridiano origen, Greenwich, y el plano que pasa por el origen y es perpendicular al eje Z, el meridiano de referencia coincide con el meridiano cero del BIH en la época 1984 con una precisión de 0,005". Realmente el meridiano origen se define como el IERS Reference Meridian (IRM). 5Sistema de coordenadas geográficas UTM:http://www.aristasur.com/contenido/ sistema-de-coordenadas-geograficas-utm 23 El eje Yortogonal a los anteriores, pasando por el origen. Figura 1.10: Definición de WGS84 (Fuente: NIMA) La altura, que representa la coordenada Zen el UTM anteriormente descrito, está tomada con dicho formato. Es decir, la altura con respecto a un determinado elipsoide con semieje mayor y menor bien definidos y cuya superficie casa bien con la placa continental europea. Para el caso que nos toca, en España, el elipsoide se puede encontrar por encima o por debajo del nivel del mar, por lo que hay que tener en cuenta que pueda haber una pérdida de precisión a la hora de obtener las alturas de los archivos en formato UTM6. 1.3.4. Conceptos astronómicos Otro aspecto fundamental a tener en cuenta es la posición y elevación del sol en todo momento durante la ruta elegida. Para comprenderlos tenemos que introducir los conceptos de acimut y de elevación del sol [8]. 6Sistemas geodésicos de referencia: http://www.ign.es/ign/layoutIn/ actividadesGeodesiaStmagd.do 24 1.3.4.1. Acimut En astronomía el acimut es el ángulo o longitud de arco medido sobre el horizonte celeste que forman el punto cardinal norte y la proyección vertical del astro sobre el horizonte del observador, el cual se sitúa en una determinada latitud. Para nuestro caso, el sol es el cuerpo celeste. El acimut se mide en grados y determina la posición del sol en todo momento del día moviéndose en el sentido de las agujas del reloj. El acimut depende completamente de la posición concreta del observador, es decir, el sol puede ser visto bajo diferentes coordenadas horizontales por diferentes observadores situados en puntos diferentes del globo. Figura 1.11: Representación del acimut. 25 2.1. Requisitos funcionales A continuación se describe los requisitos funcionales de los que dispondrá la aplicación: Identificador del requisito Nombre Descripción REQF-01 Seleccionar hora y fecha. La aplicación debe dar la posibilidad al usuario de seleccionar la hora y la fecha de partida de la ruta. REQF-02 Establecer la importancia de la sombra en la ruta. El usuario podrá establecer mediante un intervalo de 0a10, la relevancia o peso que tendrá la sombra en la ruta. REQF-03 Establecer el origen y el destino. El usuario podrá establecer el origen y el destino de la ruta en el mapa de la aplicación. REQF-04 Mostrar la ruta. Una vez elegido el origen y el destino, la aplicación calculará la ruta y la mostrará en pantalla. 32 REQF-05 Recalcular la ruta. Una vez calculada la ruta, el usuario podrá de nuevo recalcularla. Funcionalidad introducida por si el usuario desea modificar los parámetros de entrada para la misma ruta. REQF-06 Mostrar información de la ruta. Una vez realizado el cálculo y mostrada la ruta, también se mostrará información general de la ruta: tiempo del recorrido, tiempo de exposición solar y distancia. REQF-07 Mostrar información de etapas de la ruta. Una vez calculada la ruta, el usuario podrá acceder a la información de las distintas etapas de la misma. Cada etapa tendrá el tiempo y el porcentaje de exposición solar. 2.2. Requisitos no funcionales Los requisitos no funcionales irán enfocados principalmente al rendimiento del sistema, la arquitectura y la usabilidad en sí. 33 Identificador del requisito Tipo de requisito no funcional Nombre Descripción REQNF-01 Requisito de proceso. Formato del archivo de entrada de coordenadas y alturas. Los datos que recibe de entrada la aplicación deben cumplir el formato XYZ en el sistema UTM. REQNF-02 Requisito de producto. Desarrollo en Android. La aplicación será desarrollada para la plataforma Android. REQNF-03 Requisito de usabilidad. Notificación de errores e información. La aplicación notificará al usuario en todo momento si se ha producido un error al cargar los datos o todo lo que tenga que ver también con el proceso de cálculo de la ruta. REQNF-04 Requisito de arquitectura. Servidor web. La aplicación en Android realizará las peticiones de cálculo a una máquina externa que estará ejecutando un servidor web, el cual procesará las peticiones y devolverá una respuesta. REQNF-05 Requisito de recursos. Cálculo de rutas mediante OpenTripPlanner. En la máquina externa que ejecute el servidor web habrá una instancia de la plataforma OpenTripPlanner, el cual se encargará de realizar los cálculos de ruta. REQNF-06 Requisito de interfaz. Cálculo de ruta sobre Google Maps. En la aplicación Android se usará Google Maps para la visualización de la ruta. REQNF-07 Requisito de rendimiento. Recursos de la máquina servidor. El servidor web gozará de las características idóneas a nivel de procesador y memoria, así como conexión, para satisfacer el cálculo de las rutas y procesamiento de peticiones y respuestas en un tiempo óptimo. 34 Capítulo 3 Cálculo de la ruta En esta sección se detallarán en profundidad los procesos para el cálculo de la ruta. Se explicarán los diferentes pasos para llegar a este fin como son: 1. El cálculo de alturas a partir de los modelos digitales de terreno (MDT) y superficie (MDS). 2. El cálculo de la altura angular en una coordenada a raíz de las alturas de dichos modelos. 3. El algoritmo de búsqueda para el cálculo de la ruta. 4. La plataforma OpenTripPlanner que usaremos de base para dicho fin, que desplegará el servidor y que modificaremos y añadiremos las funcionalidades para nuestro propósito. 3.1. Datos de entrada Los cálculos de la ruta se realizan en base a unos ficheros de entrada en el que cada línea representa una coordenada en UTM seguida de la elevación del terreno o superficie respecto del nivel del mar. Antes de poder usar estos datos en bruto, tenemos que realizar una serie de modificaciones en estos datos para poder usarlos en la aplicación. 35 3.1.1. Los datos de alturas a partir de los modelos digitales Un aspecto importante para el desarrollo de la aplicación es el cálculo de las alturas de los edificios y la vegetación con el objetivo de comprobar si tenemos o no sombra en un punto geográfico. Para hacer esto usaremos los MDT yMDS. Dichos modelos los podemos encontrar en la página del Instituto Geográfico Nacional (IGN) para casi todo el territorio peninsular. En concreto, los modelos MDT nos dan la altura respecto al nivel del mar de todo el relieve del terreno con una resolución de 5m×5mdispuestos en una cuadrícula, mientras que los MDS nos dan los mismos datos sin estar organizados en una cuadrícula, y en este caso contará con la altura de los edificios y vegetación sobre el relieve del terreno. Los MDS poseen una resolución de 0,5 puntos/m2. Cada archivo cubre un área de 2km ×2km. Figura 3.1: Representación del MDS yMDT Para el MDT tenemos un formato de archivo ASCII Grid que se compone de una matriz bidimensional que será convertido a un formato más amigable que simplifica la posterior manipulación de los datos. El mismo IGN nos ofrece una herramienta1para poder convertir el archivo ASCII al formato XYZ , que está formado por filas de tres valores: X,YyZ. Las dos primeras columnas, XeY, se refieren a las coordenadas en formato UTM, mientras que la tercera columna, Z, es la altura de dicho punto en el sistema WGS84. Una vez realizado el cambio de formato el archivo tendrá el aspecto siguiente: 1Herramientas del IGN: http://www.ign.es/ign/layoutIn/herramientas.do 36 ... 428235 4580000 20.091 428240 4580000 20.382 428245 4580000 20.473 ... Una vez obtenido el archivo MDT correspondiente procedemos a manipular el archivo MDS. El archivo MDS posee una extensión .las ó .laz, por lo que han de ser convertidos también a un formato amigable para poder manipular los datos. IGN no ofrece ninguna herramienta para poder manejar este tipo de archivos pero la suite de herramientas LASTools 2nos ayudará para dicho fin. En concreto usaremos la herramienta llamada laszip que permite descomprimir el archivo .laz a un formato XYZ. 2Suite de herramientas de LASTools:http://rapidlasso.com 37 Figura 3.2: Interfaz de la aplicación laszip Esto generará un archivo txt que contiene todos los puntos en el siguiente formato: ... 430011.43 4581792.94 25.51 430013.09 4581793.21 27.22 430014.88 4581793.33 25.66 ... Como ya dijimos anteriormente, los MDS no están dispuestos en una cuadrícula y tienen una resolución de 0,5 puntos/m2. Esto genera los resultados que observamos arriba, por lo que a la hora de combinarlos con los datos del MDT. Estos últimos tienen una resolución de 5m×5my se nos hace bastante difícil y para nada trivial calcular la diferencia entre ambos modelos para obtener la altura de los edificios y vegetación, por lo que por propósitos de eficiencia al realizar los cálculos, se normalizará el MDS a la misma resolución del MDT. 38 3.1.2. Cálculo y ajuste de los datos de los modelos digitales de superficie Para poder usar los datos del MDS con el MDT, utilizaremos una Distribución Gaussiana odistribución normal. Cada punto del MDS lo redondearemos y normalizaremos a múltiplos de 5, de acuerdo con la resolución del MDT, y haremos una media ponderada de dichos puntos cuyo peso será mayor mientras más cerca se hallen del centro del recuadro que representa la coordenada. Determinamos el centro como el punto más exacto aunque esto puede dar cierta pérdida de precisión pues el usuario no tiene que estar precisamente en el centro de un recuadro puesto que el área de una celda es de 25m2. Situaremos el centro del recuadro a una distancia de 2,5m de cada lado, ya que la resolución es de 5m×5m. De esta forma a valores cercanos al centro, las alturas en dicho punto tendrán mayor importancia mientras que aquellos que se acerquen a los bordes del recuadro, tendrán menos. Con este concepto redondeamos XeYde cada coordenada del MDS. Realizamos la diferencia entre el valor redondeado y el valor original. Con el resultado podemos determinar la relevancia que tendrá ese punto en el recuadro. Siendo el valor redondeado el centro, si la diferencia es cercana a 0, tendrá mayor relevancia que aquellos con una diferencia mayor. Esto lo conseguimos mediante interpolación3. Por lo que al final para cada recuadro del MDT tendríamos una lista de puntos de altura con sus ponderaciones correspondientes basados en su distancia al centro de ese recuadro. Con esto se realiza la media ponderada para cada recuadro de la cuadrícula, se ordena y se obtiene al final el archivo MDS normalizado para poder utilizarlo junto al MDT. 3Definición de interpolación: https://es.wikipedia.org/wiki/Interpolacion 39 Para interpolar y obtener así el peso o importancia del punto del MDS a su recuadro más próximo según redondeo usaremos la siguiente fórmula de interpolación lineal: x2=(y2−y1)∗(x3−x1) y3−y1 +x1(3.1) Donde cada variable: x1yx3toman el valor 0y1respectivamente que representa el intervalo de ponderación y siendo x2el valor de ponderación devuelto por la ecuación asociado al punto que estamos evaluando que se encuentra dentro de este intervalo. y3ey1toma el valor de la distancia al centro (2,5m) y 0m respectivamente e y2 será un valor dentro de este intervalo. Será la diferencia entre el valor redondeado del punto a un múltiplo de 5y el valor original del mismo, que están asociados a los valores XeYde la coordenada. Figura 3.3: Representación de la distribución Gaussiana. En el eje X, en ambos extremos, se representaría la distancia en 2,5m. En el eje Yse representan los pesos que es mayor a medida que nos dirigimos al centro. Hay que tener en cuenta que las diferencias entre el valor original y el valor redondeado siempre se hacen en valor absoluto, por eso aunque resulte en valor negativo la diferencia de la distancia, se tomará siempre en positivo. 40 Figura 3.4: Representación de un recuadro 5m×5mdonde los puntos de mayor volumen y más cercanos al centro tienen más importancia en el MDS. Para todos los puntos del MDS correspondientes a este recuadro, se realizará una media ponderada dando como resultado la altura normalizada con la misma resolución del MDT. De esta manera ya podremos usar los modelos correctamente al tener la misma resolución para todos los recuadros de la cuadrícula. 3.1.3. Cálculo de la altura angular de las coordenadas Una vez normalizado los datos del MDS, y habiendo introducido los conceptos del acimut y la elevación del sol, ya estamos próximos a calcular si tenemos sombra en un punto geográfico. La elevación del sol se mide en grados y los valores de las alturas de los edificios y vegetación están medidos en metros. Para saber si tenemos sombra en un punto basta con calcular la altura angular en la coordenada que queremos averiguar. Como ya especificamos, el acimut es un ángulo que se forma tomando como referencia el norte con la proyección vertical del observador hacia el sol dependiendo en qué latitud se encuentre. De esta manera para cada acimut distinto en una posición geográfica, la elevación del sol irá cambiando, por lo que de acuerdo a la dirección del sol y su elevación en ese momento tenemos que ver en esa dirección todos los edificios y vegetación que podrían darnos o no sombra. En la Figura 1.12 mostramos la representación del acimut 41 Esta heurística de la distancia sólo tendrá más relevancia en función de las preferencias del usuario por lo que será máxima si el usuario prefiere una ruta más corta a otra con más sombra. Si por el contrario prefiere una ruta con más sombra, la heurística será casi 0. Sin embargo, nunca permitiremos que esto ocurra. La razón de que nunca hagamos nula esta heurística para la ruta con más sombra es debido a que una heurística no nula evita expansiones innecesarias en la búsqueda de la ruta desde un nodo cualquiera al nodo de destino. Si lo hacemos nulo (h(n) = 0), el algoritmo se comportará como un Algoritmo de Dijkstra buscando todos los posibles caminos desde un nodo, empeorando de esa manera, el rendimiento del algoritmo. Los costes de las aristas del grafo serán medidos siempre en unidades de tiempo, ya sea el tiempo de distancia o de exposición solar. La heurística será calculada mediante la distancia euclídea dividido por la velocidad del viandante que supondremos por defecto, 1,33km/h. La distancia euclídea es la distancia que habría entre dos puntos en un espacio euclídeo. Por lo tanto, la distancia euclídea entre un punto P= (p1, p2, ..., pn) y Q= (q1, q2, ..., qn) en un espacio euclídeo n-dimensional se define como: dE(P, Q) = q(p1−q1)2+ (p2−q2)2+... + (pn−qn)2(3.5) Nuestro espacio cartesiano se define en R2, ya que trabajamos con coordenadas geográficas, latitud y longitud de una posición. 48 3.2.1. Funcionamiento del Algoritmo A* en el grafo El grafo que usaremos para calcular la ruta está basado en la plataforma OpenStreetMap (OSM)4. Esta plataforma posee una base de datos con más de 30GB de datos geográficos vectoriales de información muy diversa y detallada (carreteras, caminos, edificios, restaurantes, parques naturales...). Otras páginas, como es Mapzen5, ofrece un servicio online de porciones de datos de dicha base de datos semanalmente. Los datos OSM son capturados mediante el uso de dispositivos GPS, así como algunos de ellos permiten grabar trazas de rutas. Estas trazas se pueden cargar en el servidor de OpenStreetMap. El formato OSM es un formato de archivo XML propio de OpenStreetMap. En dicho formato se establece al principio los límites del área así como los nodos con sus respectivos identificadores y posiciones geográficas. Dicho esto, vamos a presentar el procedimiento en pseudocódigo de como se comportaría el algoritmo A*, así como funciones y métodos auxiliares para este cálculo: 4Grafos callejeros a través de la plataforma OpenStreetMap:https://www.openstreetmap.org/ 5Metro extracts City-sized portions of OpenStreetMap https://mapzen.com/data/metro-extracts 49 Algorithm 1 Algoritmo A* 1: procedure aStar(origen : Node, destino : Node) 2: nodoActual = null 3: listaAbierta = origen 4: repeat 5: nodoActual = nodoConMenorF(listaAbierta) 6: listaCerrada->añadir(nodoActual) 7: if nodoActual == destino then 8: return nodoActual 9: else 10: listaAdyacentes = getAdyacentes(nodoActual) 11: repeat 12: adyacente = listaAdyacentes->sacar() 13: if adyacente NOT IN listaAbierta && adyacente NOT IN listaCerrada then 14: setCostesNodo(nodoActual, adyacente, destino) 15: adyacente -> setPadre(nodoActual) 16: listaAbierta->añadir(adyacente) 17: else if adyacente IN listaAbierta then 18: if adyacente -> getG() < nodoActual -> getG() then 19: setCostesNodo(nodoActual, adyacente, destino) 20: adyacente -> setPadre(nodoActual) 21: end if 22: end if 23: until listaAdyacentes == ∅ 24: end if 25: until listaAbierta == ∅ 26: end procedure 50 Algorithm 2 Función para obtener nodo con menor valor f(n) 1: function nodoConMenorF(listaDeNodos : List of Node) 2: resultado = listaDeNodos[0] 3: j=0 4: for i=1UNTIL i< tamaño(listaDeNodos) do 5: if listaDeNodos[i] -> getF() < resultado -> getF() then 6: resultado = listaDeNodos[i] 7: j=i 8: end if 9: end for 10: listaDeNodos->sacar(j) 11: return resultado 12: end function Algorithm 3 Procedimiento para establecer los costes de f(n),g(n) yh(n) 1: procedure setCostesNodo(padre : Node, hijo : Node, destino : Node) 2: costeH = getCosteHeuristica(hijo, destino) 3: costeG = getCosteG(padre, hijo) 4: hijo -> setG(padre -> getG() + costeG) 5: hijo -> setH(padre -> getG() + costeH) 6: hijo -> setF(hijo -> getG() + hijo -> getH()) 7: end procedure 51 El algoritmo A* (1) añade al comienzo el nodo origen en la lista abierta, la cual es una lista que contiene todos los nodos que quedan por evaluar. Seguirá repitiendo lo mismo mientras la lista no esté vacía o el nodo actual sea el nodo destino. De toda esta lista se saca aquel nodo con menor valor fpara establecerlo después como el nodo actual. Seguidamente sacamos el nodo de la lista abierta para meterlo a la lista cerrada, que es una lista de nodos que ya han sido tratados y no necesitan ser revisados. Una vez comprobado que el nodo actual es distinto del nodo destino, tomamos todos los nodos adyacentes al actual. Por cada uno de ellos se comprueba que no se encuentre ni en la lista abierta, ni en la cerrada o que por el contrario se encuentre únicamente en la lista abierta. Si este nodo adyacente no está estas listas, se le asigna los costes para f(n),g(n) yh(n), siendo nel nodo que estamos evaluando. Hacemos que el nodo adyacente apunte al nodo actual, el cual es su nodo padre, y añadimos este nodo adyacente a la lista abierta. Si por el contrario, este nodo adyacente ya se encuentra en la lista abierta, hemos de revisar si el camino para este nodo es mejor usando el coste g. Si este coste es menor significa que será un camino mejor, de ser así, cambiamos el padre del nodo adyacente (por estar en la lista abierta se supone que ya tenía asignado un padre) tomando como padre el nodo actual y recalculando los costes de f(n),g(n) yh(n) para este nodo. Este proceso, como dijimos, acabará cuando se tome para explorarlo de la lista abierta el nodo destino por lo que habremos dado con el camino, y por lo tanto, con la solución. En caso contrario, si la lista está vacía, significará que no se ha encontrado el camino, por lo tanto, no se ha encontrado la solución. La ruta se construirá siguiendo los nodos padres a los que apuntan desde el nodo destino al nodo origen. La función nodoConMenorF (2) se encarga de devolver el nodo con menor valor f(n). Su implementación consiste en recorrer la lista de nodos y devolver aquel con el menor valor de f(n). Antes de devolver el nodo, éste es eliminado de la lista abierta. 52 El procedimiento setCostesNodo(3) se encarga de establecer los costes para f(n),g(n) y h(n) necesarios para calcular la ruta con mínimo coste. En dicha función de evaluación, g(n) representa el coste real del camino recorrido para llegar al nodo destino y h(n) representa el valor heurístico del nodo a evaluar desde el actual hasta el nodo de destino. Por lo tanto y teniendo en cuenta lo anterior, nuestro valor g(n) será el tiempo en segundos desde el nodo padre hasta el nodo hijo (n). Es decir, dejamos constancia del camino real que nos llevará al nodo hijo. Asimismo, el valor h(n) ha de ser un valor de estimación del tiempo restante para llegar al nodo destino. De esta forma, solo nos queda asignar al nodo hijo el coste gque ya tuviese su nodo padre más el coste gaquí calculado. De igual forma para asignar el coste hal nodo hijo hemos de tener en cuenta la acumulación que tiene el coste gdel nodo padre al que le hemos de sumar el nuevo valor hcalculado del hijo. Luego al nodo hijo se le asigna el coste f, el cual es la suma de gyh. Hay que tener en cuenta que los algoritmos citados anteriormente describen de una forma general como se comporta el algoritmo A*. Sin embargo, la plataforma OTP utiliza un Heap para que al sacar aquellos nodos con coste mínimo su complejidad sea O(1) en vez de O(n) como podemos observar en la función nodoConMenorF, por lo que hay que tener en cuenta que estas funciones auxiliares al algoritmo A* no serían usadas en esta plataforma. 3.3. La plataforma OpenTripPlanner para el cálculo de la ruta Una vez introducidos los datos de entrada de alturas, los conceptos básicos del algoritmo de búsqueda y el funcionamiento del algoritmo A* podremos introducir la plataforma que se encargará de toda la lógica del cálculo de ruta. En un principio se pensó en la idea de partir de cero en la implementación del algoritmo de búsqueda así como el manejo de grafos para calcular la ruta. Pero debido a la com53 plejidad que supondría, sobretodo esto último y el manejo de los datos de altura del área que queremos cubrir (que suponen del orden de unos 500MB), lo hacen bastante inviable trasladarlo a una aplicación móvil. Por todo esto y por tal de no alejarnos del verdadero propósito que supone el proyecto, hemos decidido usar una plataforma que hace uso de los grafos OSM e implementa el algoritmo A* con la heurística de la distancia euclídea ya citados en capítulos anteriores. Sólo será necesario modificar la funcionalidad del algoritmo e introducir los módulos necesarios para este cálculo de ruta en concreto. Por lo tanto, se ha decidido a la creación de una arquitectura de cliente/servidor [1] que soporte las peticiones de cálculo de rutas a través de la aplicación móvil para mostrarlo en pantalla. Dicha plataforma es OpenTripPlanner. OpenTripPlanner (OTP)6es una plataforma Open Source multi-modal ymulti-agencia para planificar viajes. Lanzado en 2009, el proyecto ha suscitado una próspera comunidad de usuarios y desarrolladores recibiendo soporte incluso de agencias públicas, startups y empresas de transporte. OTP ha sido implementado en muchas partes del mundo e incluso es el motor para la creación de rutas detrás de muchas aplicaciones populares en smartphones. Esta plataforma está basada en una arquitectura cliente-servidor que suministra una interfaz web para calcular rutas mediante un mapa y también una API (basada en servicios REST [10] para aplicaciones de terceros). OTP se constituye de datos abiertos de tipo General Transit Feed Specification (GTFS)7para el tránsito en las distintas moda6OpenTripPlanner:http://www.opentripplanner.org/ 7General Transit Feed Specification:https://en.wikipedia.org/wiki/General_Transit_Feed_ 54 Figura 3.8: Diagrama de clases que usaremos en la plataforma OTP. lidades existentes y OpenStreetMap para las redes callejeras. OTP cuenta con una serie de paquetes para el cálculo de rutas. Nos fijaremos, en especial, en el paquete routing que contiene toda la lógica para el cálculo de rutas. A continuación estableceremos el diagrama de las clases que intervendrán en el cálculo de la ruta: Specification 55 Cuando el usuario realiza una petición a través de la aplicación móvil, introduciendo sus preferencias deseadas, OTP la procesará mediante la clase PlannerResource. Una vez ejecutada la petición, la respuesta es devuelta en formato XML,JSON o texto plano dependiendo de la configuración del cliente. En esta clase se establece una instancia de la clase Router, la cual define la configuración de la ruta para el grafo de un área específica que hayamos elegido. A esta instancia, en su creación, se le pasará otra instancia de la clase RoutingRequest que contendrá los parámetros establecidos por el usuario para el cálculo de la ruta. Es en esta clase donde añadiremos la variable shadedWalk para el peso o relevancia que tendrá la sombra en la ruta que será asignada entre 0y10. Con esto ya podremos introducir el parámetro shadedWalk en la petición para poder capturarlo y poder procesarlo. Con el objeto de la clase Router se procede a instanciar un objeto de la clase GraphPathFinder. Esta clase contiene la definición para construir el árbol de búsqueda con el camino más corto a través de la clase AStar para nuestro grafo asignado. AStar calcula la ruta haciéndose servir de un conjunto de estados de la clase State, que representa un estado del grafo de estados del algoritmo A*. Por cada estado se asocia un Edge. Cada Edge posee un par de nodos de la clase Vertex con el origen y el destino de cada arista que es la que representa la calle por donde se transita. Es en la clase StreetEdge (que hereda de Edge) donde se establecerá el coste de ir de un nodo a otro. Cada nodo de la clase Vertex posee un conjunto de datos de StreetEdge que parten y llegan a dicho nodo. Esta clase representa los segmentos de la calle y donde se realiza el coste de atravesar cada una de ellas. Aquí realizaremos las modificaciones pertinentes para asignar la ponderación resultado de la relevancia que haya querido dar el usuario a la sombra en su ruta. El cálculo de la ponderación vendrá dado por la siguiente fórmula: coste =pesosombra ∗tiempoexposiciónsolar + (10 −pesosombra)∗tiempoduración(3.6) Si el usuario asigna el máximo de peso de la sombra, en este caso 10, no se tendrá en cuenta el tiempo de la duración hasta el destino. Si por el contrario se asigna 0, no se tendrá en cuenta el tiempo de exposición solar para calcular la ruta. Este cálculo se hará 56 mediante la clase ShadedPath con el método formulatePonderate que recibe el peso de la sombra, el tiempo de exposición solar y el tiempo que se tarda en atravesar la calle. Una vez establecido el coste, la clase AStar mediante una estructura de datos de tipo BinHeap, guardará los costes para cada estado en dicha estructura. Esta se comportará como una lista abierta que realizará el comportamiento que describimos en la sección 3.2. 3.3.1. Cálculo del tiempo de exposición solar La característica del cálculo del tiempo de exposición solar (que sirve en la fórmula de ponderación señalada antes) es uno de los núcleos de la aplicación. Se procederá a explicar el procedimiento del cálculo en esta sección. La clase StreetEdge es la que se centra en el cálculo del coste de atravesar un segmento de calle. Es aquí donde asignaremos el valor del tiempo de exposición solar. Para ello nos haremos servir de la clase ShadedPath que es la que se va a encargar de computar toda la lógica referente al cálculo de la sombra. Concretamente, nos enfocaremos en el método calculateTimeSunLightExposureBetweenTwoVertexes. Este método se encargará de calcular el tiempo de exposición solar en segundos entre dos nodos. Estos poseen una latitud y longitud unidos por un segmento. Debido a que los datos de entrada están en coordenadas UTM (para cada par de nodos origen y destino) debemos convertir las coordenadas a este formato para poder consultar los datos de las alturas angulares máximas cargados en el arranque del servidor. Estos datos serán almacenados en una matriz bidimensional de la clase HeighCoordinate, en la que cada posición de esta matriz representará una coordenada geográfica en UTM y para cada una de estas coordenadas, se guardará una estructura de datos de par <clave, valor> donde la clave es el acimut y el valor la altura angular máxima para dicho acimut. Con el origen y el destino de nuestro segmento y con la clase SunRelativePosition le pasamos como parámetros la latitud, la longitud, la hora y la fecha en la que nos encontramos. Así obtendremos con exactitud el valor del acimut y elevación solar en estos puntos. Pero, ¿Cómo calculamos estos valores para los puntos intermedios del segmento?. Un segmento puede tener una distancia importante (a veces incluso de cientos de metros) y en 57 64 Capítulo 4 La aplicación móvil Como comentamos en anteriores secciones, la arquitectura del proyecto será del tipo cliente-servidor. La aplicación móvil será nuestro cliente y la parte servidor será el servidor web que esté ejecutando OTP. Esta aplicación móvil realizará una petición al servidor para calcular la ruta mediante servicios REST [10]. Concretamente ejecutará una petición GET en la cual se le pasará como parámetros la latitud, longitud, hora, fecha, el modo de tránsito (en nuestro caso WALK) y el peso de la sombra. Una vez procesada la solicitud, el servidor devolverá la respuesta en JSON oXML, dependiendo de la configuración de cabecera, que para nuestro caso será JSON. Por lo que esta respuesta será deserializada y usada para realizar las operaciones y así mostrar la ruta e información relevante al usuario en la aplicación. 65 Figura 4.1: Arquitectura de la aplicación. 4.1. La estructura de la aplicación La aplicación Android contará con una interfaz de Google Maps. El usuario en todo momento podrá elegir el origen y el destino de su ruta manteniendo pulsado el punto del mapa. Se seleccionará a través de un diálogo informativo que se abrirá al realizar dicha acción. Una vez hecho esto, automáticamente la aplicación realizará una petición al servidor donde está ejecutándose OTP. Este iniciará el cálculo para más tarde devolver la respuesta en formato JSON. La aplicación móvil analiza la respuesta y la deserializa mediante la biblioteca GSON, instanciándola en un objeto de la clase OTPRouteShaded. Esta clase ha sido generada siguiendo el código de prácticas denominado Plain Old Java Object (POJO)1, el cual nos será de utilidad a la hora de deserializar la respuesta que nos envíe el servidor y podamos trabajar con ella más cómodamente para mostrar la ruta. Para construir la ruta utilizaremos la clase Step que sería la clase análoga a WalkStep en el lado del servidor. Esta clase nos define cada etapa de la ruta construida y está formada por los siguientes atributos: la distancia, tiempo de exposición solar, nombre de la calle, 1Plain Old Java Object: https://en.wikipedia.org/wiki/Plain_Old_Java_Object 66 Figura 4.2: Diagrama de clases en las que se deserializa la respuesta en formato JSON. latitud y longitud en la que empezaría la etapa. Cada una representa un segmento de la ruta. Se darán indicaciones de como el usuario debe moverse por cada una de ellas hasta llegar al destino. La información de las mismas también será necesaria para poder crear y posicionar los marcadores en el mapa para visualizar la ruta. Cada marcador (que simboliza el comienzo de cada etapa) estará oculto. Cuando el usuario necesite saber información sobre esa etapa seleccionará el item que le corresponda. Seguidamente se mostrará el marcador. Si lo seleccionamos veremos información del tiempo y del porcentaje de exposición solar. A la hora de trazar las líneas entre marcadores se usarán Polylines que trazan una línea entre dos puntos con su latitud y longitud respectivas. 67 Figura 4.3: Ruta representada con el uso de polylines. Los marcadores: origen y destino salen visualizados mientras que los intermedios están ocultos por tal de no sobrecargar la interfaz. 4.1.1. La Action Bar Uno de los aspectos más importantes de la aplicación es la barra de acciones o ActionBar, introducida en la versión 3.0 de Android. En ella incluimos las diversas opciones relacionadas con las preferencias para calcular la ruta. Las opciones presentes en la barra serán: Establecer la hora a través de un selector de hora. Establecer la fecha a través de un selector de fecha. Recalcular la ruta que ya fue calculada con anterioridad. Establecer el peso o relevancia que tendrá la sombra en la ruta a través de un deslizador en el que el usuario podrá elegir desde 0hasta 10. Mostrar información general de la ruta, así como cada una de las etapas de la misma. 68 Establecer la dirección al servidor OTP al que se le hará las peticiones para cálculo de rutas. Figura 4.4: Opciones en el menú ActionBar de izquierda a derecha: la primera opción nos permite mostrar una lista con todas las etapas de la ruta e información general, la segunda para recalcularla, la tercera para establecer la hora de inicio, la cuarta para establecer la fecha de inicio, la quinta para asignar la relevancia de la sombra y la última opción para establecer la dirección del servidor donde se encuentre ejecutando OTP. 69 4.1.2. Información de la ruta y las distintas etapas Para cada ruta necesitamos mostrar al usuario la siguiente información: tiempo de exposición y porcentaje solar, distancia y dirección a tomar para cada etapa. Así también como información general de la ruta: el tiempo de distancia, el tiempo de exposición solar total y la distancia total. Para ello se ha optado por usar una ventana deslizante que se activará al pulsar la primera opción de la barra de acción. Figura 4.5: Captura de la aplicación donde puede verse la información de la ruta. Arriba tenemos el tiempo del trayecto así como el tiempo de exposición solar. Seguidamente tenemos la distancia en metros y una lista con todas las etapas de nuestra ruta y dirección que debemos tomar en cada una. 70 Al seleccionar una etapa se hará visible el marcador asignado en el mapa. Se nos mostrará un diálogo de información para ese marcador con el tiempo de exposición solar y porcentaje del mismo. Para calcular dicho porcentaje hemos realizado la división entre el tiempo durante el que hay exposición solar dividido entre el tiempo total de la etapa y multiplicado por 100. Figura 4.6: En la etapa Carrer de Sant Pau tenemos un tiempo de exposición solar de 9 segundos que representa un 14 % de la exposición solar en esa etapa. 71 Figura 4.7: En este otro ejemplo: Ronda de Sant Pau tenemos un tiempo de exposición solar de 27 segundos que representa un 100 % de la exposición solar en esa etapa. En este caso la exposición solar es máxima. 4.1.3. Notificación de errores y excepciones Como en toda aplicación, es necesario tratar los errores para evitar bloqueos innecesarios. Estos errores serán debidos a imprevistos que hayan ocurrido en el servidor durante el proceso de cálculo de la ruta. Otro caso sería si no obtuviéramos una respuesta en un tiempo por defecto y sea necesario notificárselo al usuario. Los diferentes avisos de errores serán los siguientes: Notificación al usuario de que se ha producido un error al establecer el origen o el destino de la ruta fuera del área que soporta la aplicación. Notificación al usuario que intenta calcular la ruta sin haber establecido el origen y el destino. Notificación al usuario de que el servidor está tardando demasiado en responder o que no ha podido establecerse la conexión con el servidor. 72 Figura 4.8: Error mostrado si el servidor no se encuentra disponible al calcular la ruta. Figura 4.9: Error mostrado si se intenta calcular la ruta fuera del área que soporta la aplicación servidor. Figura 4.10: Error mostrado si se intenta calcular la ruta o mostrar la ruta si aún no se ha establecido el origen y el destino. 73 sobre el arranque de la aplicación nos podemos dirigir aquí1. El parámetro -jar ejecuta la clase principal del proyecto. OTP es un proyecto basado en Maven. Cualquier modificación realizada requiera la ejecución del comando mvn clean package para construir el fichero binario. Para más información sobre como construir el proyecto desde las fuentes nos podemos dirigir aquí2. Con la opción -build e-inMemory le indicamos la ruta donde se halla el grafo y de qué manera queremos cargarlo, en este caso, en memoria. A.1.2. Establecer el entorno a través de un IDE Toda la información relacionada con el arranque de la aplicación desde un IDE se puede encontrar en este enlace3. En primer lugar se recomienda para el proceso usar uno de los IDE siguientes: Netbeans,Eclipse oIntellij IDEA. Abrimos OpenTripPlanner que viene adjunto con la memoria y procedemos a crear una nueva configuración de arranque. Tenemos que identificar la clase principal que se encuentra en el paquete org.opentripplanner.standalone y cuyo nombre es OTPMain. Esta es la clase encargada de ejecutar el programa así como de arrancar el servidor web e iniciar los servicios web. Es necesario decirle al servidor donde se encuentran los grafos OSM a cargar en memoria para poder usarlos. Esta información la introducimos como argumento del programa en Program arguments y dichos parámetros serán: –build /pathtoproject –inMemory, que en este caso el grafo se ubica en el directorio raíz del proyecto. Debemos tener en cuenta que siempre que se quiera mover el archivo de directorio deberemos volver a reescribir la ruta en el argumento del programa. Por último queda asignarle la memoria necesaria para ejecutar el proyecto. Se recomienda poner un mínimo de 2GB, ya que por debajo de esa cantidad puede experimentar problemas de rendimiento y bloqueos. El argumento de la memoria lo asignaremos en el campo VM options mediante el parámetro -XmxNG donde Nserá el número de gigas de memoria que queremos asignar. 1Basic Usage of OpenTripPlanner: http://docs.opentripplanner.org/en/latest/Basic-Usage/ #basic-usage-of-opentripplanner 2Building OTP from Source: http://docs.opentripplanner.org/en/latest/Getting-OTP/ #building-from-source 3Working on OTP in an IDE:http://opentripplanner.readthedocs.org/en/latest/ Developers-Guide/index.html?highlight=IDE 80 Figura A.1: Configuración de arranque en el IDE Intellij IDEA. A.1.3. Interfaz web para probar el cálculo de rutas Para la realización de pruebas en el servidor se ha optado por la interfaz web que proporciona la misma aplicación. Una vez arrancado el servidor podemos acceder introduciendo la dirección: http://localhost:8080. Se nos iniciará la interfaz web con el mapa apuntando a la zona del grafo que hemos cargado, en nuestro caso, Barcelona. Una vez cargada la interfaz, en la parte inferior izquierda, observaremos un recuadro de opciones para nuestro viaje con el nombre Trip Options. En nuestro caso debemos seleccionar la modalidad Walk Only y aparecerá un recuadro con todas las opciones para esa modalidad: la hora, la fecha de salida y la relevancia de la sombra mediante un selector que va del 0al 10. Sólo queda asignar el origen y destino de la ruta en el mapa y hacer click en Plan Your Trip para cargar la ruta. 81 Figura A.2: Ejemplo de cálculo de ruta de la interfaz web. 82 Apéndice B Aplicaciones adjuntas Hemos tenido que crear dos aplicaciones anexas al proyecto principal para convertir los datos en bruto a una estructura apropiada para la finalidad del proyecto. Dichas aplicaciones son: OrderAndNormalizeMDSFile yAngleElevationFile B.1. OrderAndNormalizeMDSFile Esta aplicación tiene el propósito de ordenar los puntos de elevación de un archivo en formato XYZ asociados a un MDS. El archivo o archivos suministrados por el IGN tiene una resolución de 0,5 puntos/m2para el MDS y de 5m×5mpara el MDT. Para poder obtener las alturas angulares, por cuestiones de eficiencia y rendimiento en el cálculo, que tanto el MDS como el MDT tengan la misma resolución. El proyecto toma un archivo en formato XYZ. Cada coordenada XeYes redondeada a un múltiplo de 5y es añadida a una estructura de tipo Map siendo la clave la coordenada <X,Y> y el valor una lista de elevaciones para esa coordenada. Una vez cargados todos los puntos se procede a realizar una media ponderada de todos ellos con las elevaciones asociadas a cada coordenada. Esta ponderación va en función a la distancia al centro de esa coordenada. De modo que a menor distancia al centro, mayor ponderación. 83 Esta explicación se puede ver con más detenimiento en la sección 3.1.2. Si deseamos añadir más de un MDS para normalizarlo y ordenarlo hay que tener en cuenta que las coordenadas deben ser contiguas entre sí. Esto quiere decir que si para un archivo que comienza en una coordenada Xen 428.000 y acaba en 432.000, el siguiente no debería comenzar en 440.000 si no en 432.000 al igual que las coordenadas Yque también deben estar en el mismo rango. Esto es para respetar la integridad de los datos y que no hayan ‘vacíos’ ya que podría provocar que haya posiciones nulas en mitad de la matriz bidimensional. Al final de la ejecución se creará un archivo presentando la misma resolución que en el archivo MDT. B.2. AngleElevationFile Esta aplicación recoge el archivo creado anteriormente en formato XYZ del MDS y el archivo con el mismo formato para el MDT con la finalidad de calcular la máxima altura angular para cada coordenada y acimut. El proyecto establece un incremento del acimut establecido por el usuario y un inicio y final del valor del acimut que se quieren calcular para cada punto de la cuadrícula. El programa cargará los datos en una matriz bidimensional con los datos del MDT yMDS. La matriz se recorrerá por filas y columnas para calcular las alturas angulares para cada acimut. Este proceso puede ser bastante largo en función del tamaño de los modelos digitales. Al final de la ejecución se obtendrá un archivo con las alturas máximas angulares asociadas a cada acimut para cada coordenada geográfica. A continuación mostramos como quedarían los datos representados en el archivo: ... 428235 4580000 70 20.091 84 428235 4580000 75 20.382 428235 4580000 80 20.473 ... El tercer y cuarto valor de cada línea corresponden al acimut y altura angular respectivamente. Este archivo será el que cargue la aplicación OTP para realizar los cálculos de la sombra en la ruta. Para comprender mejor el funcionamiento de este proyecto nos podemos remitir a la aplicación TestDiagonal que pinta en pantalla todas las líneas. Cada una de ellas representa un acimut partiendo de la posición relativa del observador. Se recorrerían todas las coordenadas que las forman y se calcularía el máximo valor de altura angular de los edificios, vegetación o accidentes geográficos que se encuentren. Una ilustración de este ejemplo se mostró en la figura[3.7] de la sección 3.1.2. El cálculo de alturas angulares puede durar bastante tiempo por lo que se aconseja usar un ordenador con buenas prestaciones. También podemos compilar el proyecto y calcular las alturas angulares por intervalos dando como resultado varios ficheros de entradas que se le pasarán a la aplicación. Una muestra de estos ficheros lo podemos encontrar en la carpeta files de OpenTripPlanner que son los mismos que se cargan al inicio de la ejecución del servidor para calcular las rutas como comentamos en capítulos anteriores. 85 86 Bibliografía [1] Alex Berson. Client/server architecture. McGraw-Hill series on computer communications. McGraw-Hill, New York, Auckland, Bogota, 1996. [2] Rachel S. Gordon. Schildt, herbert. Java 2: the complete reference. 5th ed, 2003. [3] Muneendra Kumar. World geodetic system 1984: A modern and accurate global reference frame. Marine Geodesy, 12(2):117–126, 1988. [4] John A O’Keefe. The Universal Transverse Mercator grid and projection, the professional geographer. Association of American Geographers, 4:19–24, 1952. [5] Robert Joseph Peckham. Range-Resolved Optical Remote Sensing of the Atmosphere. Springer-Verlag, New York, 2005. [6] Robert Joseph Peckham. Digital Terrain Modelling. Springer-Verlag Berlin Heidelberg, 2007. [7] Sebastien Perochon and Javier Piqueres Juan. Android: guia de desarrollo de aplicaciones para smartphones y tabletas. ENI, Cornella de Llobregat, Barcelona, 2012. [8] Ibrahim Reda and Afshin Andreas. Solar position algorithm for solar radiation applications. Solar Energy, 76(5):577–589, 2004. [9] Elbridge P. Vance, Alberto Saenger, and Armando A. Armendariz. Modern algebra and trigonometry. Addison-Wesley, Reading (Massachusetts) [etc.], bilingua, 1st printing edition, 1964. 87 [10] Ruben Verborgh, Seth v. Hooland, Aaron S. Cope, Sebastian Chan, Erik Mannens, and Rik Van de Walle. The fallacy of the multi-api culture: Conceptual and practical benefits of representational state transfer (REST). Journal of Documentation, 71(2):233–252, 2015. [11] Chengliang Wang, Qian Zheng, Yayun Peng, Debraj De, and Wen-Zhan Song. Distributed abnormal activity detection in smart environments. Special issue on "Smart Learning with Sensor Network Technologies", International Journal of Distributed Sensor Networks, Hindawi Publishing Corporation, 2014. [12] Xiaolin Wu. An efficient antialiasing technique. ACM SIGGRAPH Computer Graphics, 25:143–152, 1991. [13] R. L. Zeng, W.; Church. Finding shortest paths on real road networks: the case for A*. International Journal of Geographical Information Science 23, 25:531–543, 2009. 88