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

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 10 Capítulo 1 Introducción 1.1. Aclaraciones previas Dado a que aún no existen datos de modelos de superficie 1para la ciudad de Málaga, el proyecto ha tenido que desarrollarse para otra ciudad, en este caso hemos elegido el centro de Barcelona. En un futuro no se descarta implementarlo para la ciudad de Málaga siempre y cuando el Instituto Geográfico Nacional (IGN)[2] u otro organismo, proporcione un modelo digital de superficie para Málaga. Para más información se puede dirigir a la página del IGN y, en concreto, a la del Plan Nacional de Ortografía Aérea (PNOA)3. En esta página se pueden observar las zonas en las que existen actualmente modelos digitales. También es posible encontrar información sobre la previsión de dar soporte a otras zonas en un futuro. Otro aspecto a tener en cuenta es lo referente a la heurística del tiempo de exposición solar. La heurística se define como una función que busca un mayor rendimiento en el cálculo estimado de la solución general o la solución óptima. El problema radica en que no podemos determinar con exactitud una posible heurística para encontrar la solución óptima a nuestro problema de encontrar la ruta con menor tiempo de exposición solar. Por este 1Definición de los modelos de superficie y terreno: https://en.wikipedia.org/wiki/Digital_ elevation_model 2Instituto Geográfico Nacional: http://ign.es 3Plan Nacional Ortográfico Aéreo PNOA:http://pnoa.ign.es/es 11 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 Como observamos en el dibujo, el acimut en el Este valdría 90o, al Sur 180o,alOeste270o y culminando en el norte con 0o/360o. Este concepto es muy importante dado que nos dice en todo momento la dirección que toma la proyección de los rayos del sol. De esta manera sabemos las coordenadas que debemos visitar en cada paso durante la ruta para ver las alturas de los edificios que corresponderán a la línea formada por la proyección solar. Figura 1.12: Representación del acimut en los datos de entrada. Cada recuadro en el tablero posee una coordenada, por lo que trazamos la línea formada por la dirección del sol desde donde nos encontramos hasta los bordes del tablero, de forma que podemos ir consultando recuadro por recuadro de la línea la altura de los edificios y vegetación. 26 1.3.4.2. Elevación del sol La elevación del sol es la distancia angular vertical que hay entre el sol y el horizonte local del observador, o también llamado, plano local del observador. Diremos que el sol tiene 12ode elevación cuando su centro geométrico está situado a 12osobre el horizonte o plano local del observador. En las Figuras 1.13 y 1.14 se muestran la elevación del sol respecto a dos posiciones diferentes del observador. Figura 1.13: Observador situado en el nivel del mar, plano local y elevación del sol. 27 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)y0m 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.EnelejeX, en ambos extremos, se representaría la distancia en 2,5m.EnelejeYse 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 y como se refleja en la cuadrícula. Visitando los recuadros contiguos de la línea, como observamos en la figura, para hallar la altura tenemos que calcular la diferencia de la altura del recuadro intermedio del MDS y la altura a nivel del suelo del recuadro donde nos encontramos sacado del MDT y calcular la distancia euclídea a dichos recuadros. Con distancia y altura podemos calcular la altura angular que no es más que el ángulo formado por el observador y el punto más alto del edificio mediante la típica fórmula de los triángulos en trigonometría [9] para obtener la tangente: tan(–)=altura del edificio distancia euclidea (3.2) El cual hallando la arcotangente del valor obtenido obtendremos el ángulo y por tanto la altura angular, pero no sólo es suficiente con obtener la altura angular de cada uno de los edificios y accidentes geográficos que nos encontremos por el camino, sino que hay que quedarse con el máximo en la dirección del sol en ese momento. Si dicha altura angular máxima es mayor que la elevación del sol sabremos que en ese punto tendremos sombra, de lo contrario, estaremos expuestos al sol. 42 Figura 3.5: Representación gráfica de la altura angular. La altura angular dada por la elevación del sol y la altura angular del edificio las cuales son calculadas respecto a la perspectiva del observador. En este ejemplo nos demuestra que no tenemos sombra. Por lo tanto, hay que calcular para cada celda la altura angular para todas las posibles direcciones, o acimuts, que tome el sol. Hay que tener en cuenta que una variación mínima del ángulo del acimut se traduce en un cambio sugerente de la línea desde el observador al sol por lo que tenemos que establecer un incremento del acimut mínimo para guardar dichas alturas máximas angulares. Este incremento lo estableceremos en 5opor lo que si el ciclo completo solar para un día son 360oentonces tendríamos 72 valores para cada recuadro de la cuadrícula el cual reduciría bastante el tamaño de los datos. Para obtener dicho archivo con las alturas angulares usaremos la ecuación de la recta la cual nos determinará las líneas a trazar desde nuestra posición relativa hasta los bordes de la cuadrícula, siendo yel valor de la fila y xel valor de la columna procederíamos a calcular los puntos de yde la siguiente manera: ydestino ≠yorigen =m(xdestino ≠xorigen)(3.3) donde msería el valor de la pendiente que corresponde a la tangente del acimut.Con 43 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 ese tramo pueden haber edificios y vegetación. ¿Cómo sabemos cuáles puntos intermedios tenemos que revisar para calcular si hay sol o no a través de todo este tramo?. La solución la encontramos con el Algoritmo de Xiaolin Wu. El Algoritmo de Xiaolin Wu [12] es un algoritmo usado para minimizar el aliasing,se utiliza para dibujar líneas con bordes suaves en pantallas digitales. Figura 3.9: Aplicación del Algoritmo de Xiaolin Wu, a la izquierda vemos como la línea posee un antialiasing generado por el algoritmo y a la derecha una línea sin antialiasing ¿Y en qué nos beneficiaría el uso de este algoritmo?. Este algoritmo lo usaremos para pasarle como entrada un nodo origen y otro nodo destino para establecer el segmento formado por todas las coordenadas entre estos dos nodos. De esta manera podemos saber que coordenadas UTM se encuentran entre ambos nodos. En estas coordenadas intermedias calculamos la elevación del sol y el acimut a esa hora del día y la comparamos con la altura angular máxima para ese acimut. Si la altura angular máxima es mayor que la elevación, tenemos sombra, de lo contrario, tenemos sol. En el caso de tener sol tendremos que calcular el tiempo de exposición solar que nos llevaría caminar hasta la siguiente coordenada del segmento, en función de la velocidad del usuario. Por lo que al final de iterar por todos los puntos del segmento tendremos el tiempo de exposición solar total para ese segmento. 58 Figura 3.10: Ejemplo del funcionamiento del método calculateTimeSunLightExposureBetweenTwoVertexes con el algoritmo de Xiaolin Wu. El algoritmo traza una línea imaginaria entre el nodo origen y nodo destino. Para cada coordenada intermedia determinamos si hay sombra. En los recuadros negros tenemos sombra, mientras que en los rojos no. Entonces para cada recuadro rojo se calcula el tiempo que le llevaría al usuario llegar al recuadro siguiente en función de su velocidad y la distancia a dicho recuadro. Al final el tiempo de exposición solar viene dado en este caso por el tiempo de recorrer todos estos recuadros rojos a lo largo del segmento. 3.3.2. Plan de viaje Después de que el algoritmo haya calculado la ruta de acuerdo a las preferencias del usuario, OTP establecerá nuestro plan de viaje mediante la clase TripPlan pasánsole como parámetro la ruta generada. Esta clase construye el trayecto en función de una serie de pasos o etapas representados 59 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 74 Capítulo 5 Conclusiones 5.1. Valoraciones finales El campo relacionado con la búsqueda de rutas óptimas se encuentra en la actualidad en constante evolución. Cada día se incorporan nuevas opciones a tener en cuenta en el cálculo de rutas que satisfagan las necesidades del usuario. La introducción de una nueva opción, como es el cálculo de la ruta con más sombra, la convierten en una posibilidad a tener en cuenta. Sobretodo en un escenario como son las ciudades inteligentes. En ellas se buscan continuamente facilitar la movilidad a los ciudadanos. La realización de este proyecto ha implicado documentarse en el área de astronomía en todo lo relativo al sol, principalmente el acimut y la elevación, como ya introdujimos en la sección de Preliminares (1.3). Una gran parte del proyecto se ha centrado en el estudio de los modelos digitales de terreno y superficie. La interpretación de estos datos son primordiales para poder calcular las rutas. Además no hay que olvidarse del entendimiento del formato UTM y el sistema geodésico WSG84 que han sido claves para poder realizar esta parte. También se ha destinado un tiempo en asimilar el funcionamiento del grafo y el algoritmo de búsqueda. Al igual que todos los mecanismos intermedios que usa la plataforma OTP desde que se realiza la petición de cálculo de ruta hasta que es devuelta por la aplicación. Todo esto ha ahorrado trabajo en una parte del proyecto al no tener que programar el 75 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 yel 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