Feb 282014
 

Cuando arrancamos una aplicación Android, el sistema operativo crea un nuevo ‘hilo’ de procesamiento para la aplicación. En ese hilo, llamado hilo principal, es donde se ejecutan todas las operaciones del programa, incluidas las tareas relacionadas con la actualización del interfaz de usuario. Es por ello, que cuando realizamos una operación que consuma un tiempo apreciable, dejamos momentaneámente congelado el interfaz de usuario. Durante ese tiempo el interfaz no responderá a las acciones como pulsar botones, actualizaciones de pantalla, etc. En suma, es como si se quedara temporalmente colgada la aplicación. Ejemplos de este tipo de operaciones pueden ser el acceso a ficheros de la tarjeta de memoria, las consultas a través de internet o la inicialización de objetos complejos. Con el fin de que el interfaz de la aplicación atienda adecuadamente en todo momento a los eventos generados en el interfaz de usuario, es conveniente que dichas operaciones se hagan en otro hilo de procesamiento diferente del hilo principal

Android dispone de la clase AsyncTask pensada para dar solución a numerosas situaciones como las planteadas. La clase AsyncTask tiene un funcionamiento muy similar al que ofrece la clase SwingWorker cuando se trabaja en entornos Java-Swing

Para utilizarla tendremos que derivar una clase que descienda de AsyncTask y sobreescribir, al menos, el método doInBackground(). Todo lo que ejecutemos dentro de ese método se ejecutará en un hilo propio creado por AsyncTask, diferente del hilo que instanció nuestra clase, que generalmente será el hilo principal. AsyncTask ofrece otros métodos que nos permitirán comunicarnos con el hilo principal y transmitirle el progreso del proceso o el resultado final del mismo. Se trata de los métodos onProgressUpdate() y onPostExecute(). Si sobreescribimos estos métodos, todo lo que ejecutemos en ellos se ejecutará en el hilo principal. El método onProgressUpdate() se ejecutará cada vez que llamemos al método publishProgress() explicitamente desde dentro del método doInBackground(). El método onPostExecute() es llamado automáticamente cuando finaliza el proceso de doInBackground().

Hay tres clases genéricas que debemos indicar al derivar nuestra clase de AsyncTask: La primera corresponde al tipo de los parametros que recibe el método doInBackground(). La segunda corresponde a los parámetros que recibe el método onProgressUpdate(). La tercera clase es la de los valores devueltos por el método doInBackground() que coincide con los parámetros que se pasan al método onPostExecute()..

Veamos un ejemplo de un worker que actúa de contador. Dentro del método doInBackground() se va incrementando un contador cada segundo. Cada vez que incrementa el contador, manda publicar el resultado en un TextView existente en el UI.

Hay que destacar que el método ‘onProgressUpdate() recibe un array de parámetros del tipo declarado. Puede suceder que enviemos un mensaje a publicar y no sea publicado inmediatamente. En cualquier caso, cuando se ejecute el método, dara salida a los mensajes pendientes.

Vemos la forma de invocar la tarea desde la actividad principal: primero se instancia un objeto de la clase y luego se llama a su método ‘execute()‘. Podemos forzar que nuestra Activity espere el resultado de la tarea asíncrona llamando al método get() de la siguiente manera:

Esto forzará al hilo principal a esperar un resultado antes de seguir.

Por último, indicar que esta clase está pensada para tareas de corta duración, pongamos unos pocos segundos. Para tareas que lleven más tiempo, Android dispone de otros mecanismos específicos como los Service. También es posible utilizar el mecanismo de Threads y ThreadPools de Java. Encontraréis más documentación en Processes and Threads



Santiago Higuera (28 de febrero de 2014)

Feb 042014
 
Navegación a por estima

Vamos explicar el método que se utiliza en náutica para calcular la distancia y el rumbo directo entre dos puntos de los que se conocen sus coordenadas geográficas. El procedimiento proporciona valores precisos para puntos cuya separación sea menor de unas doscientas millas, esto es, unos 370 kilómetros. Es el denominado problema de estima inversa en navegación loxodrómica.

No vamos a entrar en las matemáticas del asunto, sino que vamos a utilizar una regla nemotécnica para memorizar dos triángulos rectángulos que nos permitirán deducir las fórmulas correspondientes. La justificación matemática se puede encontrar en cualquier tratado de náutica. A mí me gusta más que otros el libro de Luis Mederos ‘Navegación Astronómica’.

El problema que queremos resolver es, conocidas las coordenadas geográficas de dos puntos, calcular la distancia entre ellos y el rumbo directo a seguir para ir del primer al segundo punto. Llamaremos longitud1, latitud1, longitud2 y latitud2 a las coordenadas conocidas de los puntos.

Los dos triángulos rectángulos que nos proporcionan las fórmulas para relacionar las variables son los de la figura, donde el significado de las variables es el siguiente:

  • Δl: Incremento de latitud, esto es, latitud2-latitud1
  • R: rumbo para ir del primer punto al segundo. El rumbo es un ángulo medido desde el Norte hacia el Este (a derechas)
  • D: distancia entre los dos puntos
  • Ap: Apartamiento, esto es, la longitud del arco comprendido entre dos meridianos, medido a una latitud concreta. (ver ref)
  • lm: Latitud media, o sea, (latitud1+latitud2)/2
  • ΔL: incremento de longitud, es decir, (longitud2 – longitud1)

Calcularemos en primer lugar el Apartamiento, Ap, a partir de la fórmula que deducimos del segundo triángulo:

Ap =  ΔL * cos(lm)

En esta fórmula, como en las demás, es muy importante la utilización de las unidades correctas. En general, las coordenadas de los puntos inicial y final vendrán expresadas en grados sexagesimales. Tenemos que pasar todos los ángulos a radianes antes de comenzar a operar.

Una vez calculado el Apartamiento utilizaremos el primer triángulo de la figura para calcular el Rumbo y la Distancia:

R = atan( Ap /  Δl)
D = asin( Ap / sin(R) )

El rumbo obtenido estará expresado en radianes, por lo que habrá que pasarlo a grados para que sea de utilidad en el compás

La distancia también está en radianes. Habra que pasarla a minutos de arco, o lo que es lo mismo, a millas. Una vez en millas podremos expresarla en metros multiplicando por 1851:

D (millas) = D (minutos) = D (rad) * 180.0 /  π * 60 
D (metros) = D (millas) * 1851 

Os dejo un enlace a las rutinas java que resuelven el problema:

loxodromia.java

Por último indicar que la regla nemotécnica para memorizar los triángulos es la frase que aparece bajo la figura: Alrededor del Apartamento apareció la madre de Luis



Santiago Higuera (4 de febrero de 2014)

Feb 022014
 

El formato GPX, sin ser un estándar reconocido, ha sido un estándar de facto para la recogida y transmisión de datos con dispositivos GPS. El formato GPX fue desarrollado por Topographix.

GPX es una particularización del lenguaje XML adaptada para recoger información procedente de GPS. Un documento GPX es una colección de WayPoints, Routes y Tracks. Un documento GPX concreto no tiene por qué tener todos los elementos, puede tratarse simplemente de un documento con uno o varios Tracks, o quizás solo un Route, o unos cuantos WayPoints.

Tanto los Routes como los Tracks son colecciones de WayPoints, por lo que vamos a explicar primero qué es un WayPoint. Un WayPoint almacena los datos de una posición tomada con un dispositivo GPS: la Longitud y la Latitud. El WayPoint puede guardar también la Altitud del punto, la fecha-hora de la medida y otra serie de datos relacionados con la toma de posición por parte del GPS (precisión, fix,…). El formato prevé la posibilidad de dotar al WayPoint de un nombre y una descripción. El esquema de un WayPoint, según la especificación de versión 1.1, es el siguiente:

Una característica interesante del esquema del WayPoint es que admite lo que denomina extensiones. Cada WayPoint puede llevar información adicional en forma de un elemento extensions a definir por el productor de la información. De esta manera podemos incorporar a cada WayPoint la información procedente de determinados sensores, por ejemplo, o cualquier otra que nos interese almacenar junto con las coordenadas del punto (Todos los elementos GPX admiten la posibilidad de tener extensions, también los Routes y los Tracks o el propio documento GPX). Un ejemplo de WayPoint, que incorpora información adicional en su elemento extensions, podría ser el siguiente:

Los otros elementos que puede contener un documento GPX es lo que denomina Routes y Tracks. En ambos casos se trata de colecciones ordenadas de WayPoints. La Routes están pensadas para describir un camino a recorrer. Son una colección ordenada de puntos que nos permitan describir una ruta a seguir. Un ejemplo podría ser marcar el camino a seguir para ir de Madrid a Santander, fijando los WayPoint intermedios de la Route en Tordesillas, Valladolid, Palencia y Reinosa. Otro ejemplo podría ser describir una línea de autobús, marcando los puntos intermedios en cada una de las paradas.

Por su parte, los Tracks describen un camino recorrido. Se trata de los puntos que va grabando el GPS cuando lo llevamos activado mientras recorremos el camino. Los puntos de un Track suelen llevar el dato de la fecha-hora de la medida. En realidad los Tracks no son una colección de WayPoints, sino una colección de TrackSegments, cada uno de los cuales es una colección de WayPoints. Cada Track estará compuesto por uno o más segmentos de track que son los que contendrán los puntos. Un Track tendría por tanto una geometría equivalente a la de una MultiLineString en la que cada segmento sería una LineString.

Un detalle a tener en cuenta en el esquema formal de los WayPoints es que cuando aparecen como WayPoints aislados en un documento GPX llevan la etiqueta <wpt>, mientras que cuando aparecen formando parte de una Route o de un Track llevan las etiquetas <rtept> y <trkpt> respectivamente.

Podéis encontrar la definición formal del esquema de todos los elementos que componen un documento GPX en el siguiente enlace: http://www.topografix.com/GPX/1/1/



Santiago Higuera (1 de febrero de 2014)

Jan 282014
 

Los dispositivos Android disponen de un almacenamiento, denominado la ‘sdcard‘ que hace las veces de disco duro. Ahí se guardan las aplicaciones, los datos e incluso el sistema operativo. Para acceder al contenido de la sdcard se utiliza el método ‘getExternalStorageDirectory()‘ de la clase Environment

En cambio, cuando el dispositivo lleva una tarjeta de memoria adicional, no está estandarizada la manera de acceder a ella. Cada fabricante la monta en un directorio diferente. Una posible forma de arreglar el problema es el método ‘getSecondaryStorageDirectories()‘ que os proponemos a continuación. Si bien no es un método muy ortodoxo, en los dispositivos Android que tengo a mi alcance ha funcionado perfectamente. El código del método propuesto es el siguiente:

Lleva añadidas algunas sentencias ‘Log‘ para facilitar su exploración. Hay que destacar la forma en que se discriminan los dispositivos USB. También es interesante el método ‘System.getenv()’ que nos permite explorar las variables del sistema [1]. La sentencia System.getenv(“SECONDARY_STORAGE”) nos devuelve una cadena con una serie de paths separados por dos puntos. De ahí la necesidad de discriminar los USB.

Para realizar el método getSecondaryStorageDirectories() he consultado varias páginas de internet, pero sin duda la que más me ha abierto los ojos ha sido esta de StackOverflow.

[1] Vease en ese sentido el artículo ‘System.getenv() Method – System Environment Variables’ de Dr. Herong Yang



Santiago Higuera (28 enero 2014)

Mar 292012
 
En OpenLayers tenemos dos proyecciones definidas por defecto que son la EPSG:4326 (Coordenadas geográficas Datum WGS-84) y la EPSG::900913 (Spherical Mercator, habitualmente utilizada en los mapas de OpenStreetMap, Google y otros).

Podemos incorporar otras proyecciones. Para ello tenemos que incluir en nuestro código la librería PROJ4JS que nos permitirá definir proyecciones y realizar las correspondientes transformaciones entre ellas. La librería Proj4JS la podemos descargar desde:

http://trac.osgeo.org/proj4js/wiki/Download

Situaremos el fichero proj4js-combined.js en un directorio accesible desde nuestra página web a la que añadiremos una sentencia del tipo:


Ahora ya podemos utilizar en nustro código Javascript la definición de proyecciones. Por ejemplo, para definir la proyección UTM zona 30 Norte, (EPSG:23030), debemos incluir en el código Javascript la siguiente sentencia:

También podemos incluir una proyección concreta en nuestro código mediante la siguiente construcción:


Ahora solamente nos queda utilizar las proyecciones definidas. Por ejemplo podríamos pasar de WGS84 a UTM-30N mediante la siguiente sentencia:


Las definiciones de las distintas proyecciones las podemos obtener en :

http://spatialreference.org/

Hemos preparado un ejemplo completo en el que cargamos la capa del Mapa Topográfico Nacional Español Raster Escala 1:25.000 y la capa de las fotografías del Plan Nacional deOrtofotografía Aérea, PNOA. El resultado lo puedes ver en :

olutm.html

Santiago Higuera (30 Marzo 2012)