El mejor camino

Qué encontrarás en esta entrada?

• Comparación entre OruxMaps, S Health y GPSies en una ruta de senderismo.

Si en la última entrada os hablábamos de traspasar fronteras con el Samsung Gear S3 Frontier, hoy vamos a verlo en acción y compararlo con otros sistemas a la hora de hacer senderismo.

En primer lugar, os dejo la ruta que hicimos ayer, y que nos servirá de base a nuestras pruebas.

Se trata de una ruta circular que iniciamos en la estación de Cercanías de Guadalajara y que recorría los cerros cercanos de Valdenoches.

Vamos a ver tres registros de la ruta, aunque todos ellos están relacionados:

• OruxMaps: Es la forma en la que siempre he registrado la ruta, con la conocida aplicación gratuita española que, en mi opinión, es una de las mejores que existen para Android. Ésta registra los datos del GPS del móvil según la configuración que se le haya establecido. En mi caso, es la siguiente:

• S Health: Es el registro que hace la aplicación deportiva de Samsung. En este caso la lanzo desde el Gear S3. Mantengo el reloj conectado por bluetooth (por lo que se usa el GPS del móvil, y no el del reloj), pero le tengo en "no molestar" (para que no me lleguen notificaciones continuamente que me gasten la batería) y dejo la pantalla apagada cuando no lo estoy usando. En estas condiciones el gasto de batería es bastante aceptable (poco más del 20% en una ruta que supera las 8 horas). Téngase en cuenta que, al llevar el reloj conectado al móvil, los datos sobre la ubicación se obtienen de la misma fuente que con OruxMaps, pero con distinta frecuencia de muestreo.

• GPSies: Este caso consiste en subir la ruta desde OruxMaps a GPSies (la que se muestra al principio de la entrada), con lo cual, deberían coincidir los datos, pero veremos que hay diferencias.

Distancia

Ancestral obsesión del hombre con las medidas, lo primero es determinar lo largo de la ruta, y el resultado es el siguiente:

• Longitud OruxMaps: 32,74 Km.
• Longitud S Health: 32,23 Km.
• Longitud GPSies: 32,31 Km.

¿A qué se deben estas diferencias? En primer lugar, quería indicar que en mis primeras pruebas la diferencia entre OruxMaps y S Health era mucho mayor. Descubrí lo susceptible que es la distancia a las variaciones de la frecuencia de muestreo, y es que, al ser esta menor (se toman las medidas más espaciadas), los trayectos curvilíneos se aproximan por rectas que van acortando kilómetros a la larga. Mi conclusión es que contra mayor sea la frecuencia de muestreo, más detallada es nuestra ruta, más realista, y termina siendo más larga.

Izquierda: OruxMaps (con mi configuración actual es la ruta más detallada, más real, y por tanto, más larga). Derecha: S Health.

Tras este análisis previo, subí la frecuencia de muestreo de OruxMaps tal y como indicaba más arriba, y pasó así de marcar bastante menos distancia a ajustarse más a la real, estando por encima de S Health (que viene con una frecuencia de muestreo bastante apropiada de por sí, aunque que yo sepa, ésta no es configurable).

El aumento de precisión en OruxMaps podía tener varios efectos adversos: por una parte, un excesivo consumo de batería, por otra, la creación de archivos inmanejablemente grandes. Después de probarlo en una ruta de 8 horas, he de decir que no he notado un consumo excesivo de batería mayor al de otras ocasiones, y el archivo generado (tras 30Km registrados con gran detalle) pesa unos 1'5Mb, siendo manejable con fluidez por cualquier aplicación.

¿Pero, y GPSies? En este caso, a la hora de editar la ruta por GPSies, su herramienta obliga a no sobrepasar un máximo de puntos. El excesivo detalle de OruxMaps obliga a simplificar la ruta cuando se pasa a GPSies, perdiéndose algunos metros por el camino.

Velocidad

Además de las diferencias en la distancia total, en las estadísticas que se dan al final de la ruta vemos otras incongruencias entre ambos registros.

Izquierda: OruxMaps. Derecha: S Health.

• Velocidad media: Si entendemos como "descanso" el hecho de estarse quieto un momento para disfrutar de las vistas o coger aliento, y "pausa en el registro" a la acción de cortar la medición GPS durante el tiempo que vas a estar parado (por ejemplo, mientras se come), OruxMaps considera la velocidad media total (incluyendo "descansos" y "pausas en el registro") y la velocidad media en movimiento (sin incluir ni "descansos" ni "pausas en el registro"). S Health, por otro lado, sólo muestra la velocidad media durante el ejercicio (que incluye "descansos", pero no "pausas en el registro"). Esto hace que haya fluctuaciones entre los datos mostrados por sendas aplicaciones.

• Velocidad Máxima: Está claro que andando no hemos alcanzado los 20 km/h, por lo que el dato de OruxMaps es erróneo (pudiendo deberse al corte en el registro a la hora de comer). Respecto a los 6,2 Km/h de S Health, diría que tampoco son correctos, ya que recuerdo una cuesta por la que bajamos corriendo, debiendo haber superado los 9 Km/h en ese tramo.

 

Altitud

Un punto importante es el tema de la altitud.

Según estoy viendo, parece que a las distintas aplicaciones se les da más o menos bien medir diferencias de altitudes, pero tienen un problema para determinar el valor absoluto de la misma. Para ello, también he jugado un poco con las configuraciones, usando en el caso de OruxMaps el barómetro calibrado por GPS como método para calcular la altitud.

En estas condiciones, vemos tres perfiles de altitud distintos:

• OruxMaps: Da un perfil del altitudes que parece "medido", y no "descargado de Internet". Me baso en la irregularidad de la gráfica así como en el cambio brusco que da tras el descanso de la comida (entre ambos cerros). Respecto al máximo, llega a los 963 m, aunque la gráfica (que parece simplificada) sólo muestra hasta los 959 m. En ambos casos, parece quedarse un poco por debajo de la altitud real.

• S Health: No tengo claro si la altitud por este método la recoge del barómetro del reloj o utiliza algún método desde el teléfono. Lo que se ve es que el perfil es distinto al de OruxMaps: no muestra el salto brusco tras la comida (entre ambos picos) y su valor absoluto es mucho menor (el máximo en 943 m (30 metros por debajo de lo real).

• GPSies: Una vez más, GPSies sorprende dando el valor de la altitud más exacto (máximo en 973 m). Recordar que está basado en los datos de OruxMaps, pero los corrige de alguna manera. Esto se ve, por ejemplo, porque tampoco muestra la irregularidad de OruxMaps entre ambos cerros.

En las mesetas de los cerros parece moverse la altitud entre los 963 y los 972 m

El perfil de altitudes de GPSies parece ser el más preciso

Conclusiones

Tras lo visto, seguiré usando los tres sistemas:

• OruxMaps: Me permite un registro detallado de la ruta. Puedo añadir marcadores con comentarios mientras la hago, navegar viendo el mapa a tiempo real, y el registro puede configurarse para que sea extremadamente preciso sin condenar la batería. Respecto a al altitud, tendré que tener en cuenta que es un valor aproximado, pero que puede fluctuar sobre el real.

• S Health: Mientras que OruxMaps es mi aplicación para documentar la ruta, utilizaré S Health con fines deportivos. Registra mi actividad diaria, me ayuda a establecer objetivos y con el Gear S3, tengo acceso rápido a la consulta de datos online, como la distancia recorrida en un momento dado. En cuestión de distancias, la diferencia con la real no es demasiado importante, aunque sí lo son los errores en la altitud.

• GPSies: GPSies es una aplicación que me gusta bastante para compartir rutas. Puedes subirlas desde OruxMaps directamente, hemos visto que corrige la altitud dejándola perfecta y permite la edición para incluir puntos y comentarios que enriquezcan el mapa de nuestra aventura, pudiéndolo compartir luego, por ejemplo, en una entrada como esta.

Cartografía desde el móvil con OruxMaps y MOBAC

Qué encontrarás en esta entrada?

• Presentación de MOBAC.
• Conexión con OruxMaps. 

En este blog ya hemos hablado alguna vez de cartografía y, en concreto, de su integración con dispositivos móviles. A este respecto puedo decir que, a día de hoy, la alternativa que más me convence con mucha diferencia es OruxMaps, una aplicación gratuita y española con unas características y funcionamiento realmente excepcionales.

Recientemente me topé con un pequeño problema. Su resolución, y las tecnologías con las que me he encontrado por el camino, creo que son lo suficientemente interesantes como para llenar las líneas que estamos escribiendo en este espacio.

Aclarar, en cualquier caso, que el público al que va dirigida esta entrada es al usuario medio de este tipo de tecnologías. Daremos algunas cosas por sabidas, y al mismo tiempo es obvio que al usuario experimentado todo lo que vamos a contar le parecerá una trivialidad. Espero, eso sí, que pueda ser de utilidad al usuario medio que estuviese en una situación similar a la que yo estaba hace un par de días.

Uno de los grandes puntos en los que sobresale OruxMaps es su gestión de mapas. Aún recuerdo, en una etapa temprana del desarrollo de las tecnologías de tracking (que el GPS registrase la ruta que estás siguiendo), cómo las aplicaciones más punteras ofrecían la posibilidad de registrar la ruta sobre una superficie de color plano, de tal manera que no había más referencias que la del propio camino que estabas tomando. Se ofrecía entonces, como ventaja de pago, la posibilidad de añadir un sencillo mapa de base.

Hoy en día OruxMaps proporciona infinidad de mapas online, con la posibilidad de descargarlos para su uso offline y la de añadir nuevos mapas sabiendo los servidores en los que están alojados.

El uso de mapas offline es básico. En plena ruta, es muy posible perder la señal de datos para descargarlos de manera online, y en cualquier caso es un gasto de energía y megas fácilmente evitable. Para ello es muy conveniente descargarse el mapa en casa, con una conexión WiFi.

OruxMaps da la posibilidad de descargarse una parte de un mapa online que estés visualizando en ese momento, para que luego puedas usarlo cuando quieras sin conexión. Esta herramienta es muy útil, y no he tenido problemas con ella hasta ahora, que he querido ampliar mi rango de acción y me he topado con una limitación: sólo se permite la descarga de un bloque que como máximo ocupe 500MB.

Mapa IGN Ráster - Alcalá de Henares (ejemplo de mapa por imágenes no vectoriales)

Mapa OSM MapQuest - Alcalá de Henares (ejemplo de mapa vectorial)

Los mapas ocupan de manera diferente según cómo estén construidos: hay mapas vectoriales, que ocupan muy poco puesto que guardan sólo información vectorial, y al reescalarse se redibujan atendiendo a los vectores que los definen, pero también hay mapas escaneados, que lo que hacen es mostrarte a cada nivel de zoom una imagen, por ejemplo, en TIFF. Los últimos suelen ser mucho más detallados, pero a cambio, ocupan bastante más. Si queremos descargarnos la Comunidad de Madrid de un mapa como el IGN Ráster, vamos a necesitar bastante más de 500 MB.

¿Cuál es la solución? Sin salir de OruxMaps la única solución (según he visto, quizás esté equivocado) es descargarse múltiples retículas de 500MB como máximo. Esto es un poco lioso, puesto que cada retícula tarda un tiempo considerable en descargarse, y si algún día queremos actualizar todo el mapa, deberemos volver a descargar todas las retículas una por una, definiéndolas a mano, con el respectivo solapamiento entre retículas que produciría que el mapa final acabase pesando más. Es un proceso lento, costoso y poco eficiente. Una vez descargado, OruxMaps carga (ya sea de forma manual, o automáticamente, según la configuración) cada trozo de mapa cuando corresponda. Esto tampoco es elegante: estar haciendo una ruta y tenerla partida en varios trozos de mapa.

Mi pregunta era: ¿existe alguna forma de utilizar en OruxMaps mapas offline "grandes" (de más de 500MB)? La respuesta es sí.

Para ello nos basaremos en una aplicación externa bastante popular: MOBile Atlas Creator (o MOBAC).

Este software multiplataforma (vale para Windows, Linux, OSX...) permite, entre otras cosas, visualizar mapas de distintas fuentes, descargarlos y convertirlos en un formato compatible para una gran variedad de programas, entre los que se encuentra OruxMaps.

Aunque también cuenta con sus limitaciones en el tamaño de los mapas, y con respecto al solape de capas del mismo nivel, éstas están bastante por encima de los 500MB máximos que permite OruxMaps.

 

Como vemos en la imagen  de un poco más arriba, una vez elegido el mapa que queramos utilizar, se selecciona con el ratón la parte del mismo que queramos (esto ya es un avance, porque con el ratón tenemos bastante más precisión que la que tendríamos con el dedo desde OruxMaps, y si queremos rectificar la selección es también más fácil desde el ordenador que desde un móvil o tablet), seleccionamos los niveles de zoom y le damos a "Add selection" para incluir las capas en nuestro atlas. Como podéis ver, he seleccionado gran parte del Este de la Comunidad de Madrid. Seleccionando las capas de zoom desde la 17 a la 0 (ambas incluidas), tenemos un mapa de 1GB (el doble del máximo permitido por OruxMaps).

Al darle a "Create Atlas" empieza la descarga y la conversión al formato que le hayamos indicado. Una vez finalizado, y habiendo elegido el formato "OruxMaps Sqlite", obtenemos dos archivos en la siguiente ruta:

 

<directorio_raíz_del_MOBAC>/atlases/<nombre_del_mapa>/

 

Uno es un ".xml" de unos pocos kBs y el otro es un ".db" que ocupa más. La carpeta con el nombre que le hayamos puesto al mapa, que contiene los dos archivos, ha de copiarse tal cual al móvil, dentro de la ruta:

 

<directorio_oruxmaps>/mapfiles/

De tal manera que tengamos, por ejemplo:

oruxmaps/mapfiles/Madrid Este Raste IGN/

que contega:

• Madrid Este Raste IGN.otrk2.xml (14,46 KB).
• OruxMapsImages.db (977,26 MB)

El traspaso de este archivo fue un tema que también se me complicó un poco. Generalmente, paso archivos del ordenador al móvil por red local mediante WiFi vía SFTP (SSH File Transfer Protocol). Esto funciona muy bien y es lo más cómodo para archivos de unos cuantos megas, pero parece que no va tan bien para archivos de gran tamaño.

 

La mejor alternativa parece ser el cable USB, pero por lo visto las últimas versiones de Android utilizan el protocolo MTP (Multimedia Transfer Protocol), que es parte del PTP (Picture Transfer Protocol) desarrollado por Microsoft, y que dependiendo de la versión del sistema operativo que tengas, puede dar problemas en Linux. De hecho, después de leer varios foros al respecto, no conseguí hacer funcionar el MTP en Ubuntu 14.04 con mi Nexus 5.

 

La solución en este caso fue una tontería: cuando elegimos el protocolo PTP (seleccionable desde el móvil cuando está enchufado al equipo), se nos abren las carpetas de imágenes (puesto que este protocolo está diseñado para transferir fotos). Sin embargo, nada nos impide copiar un archivo del formato que sea a la carpeta de imágenes, y luego moverlo con un explorador de archivos desde el móvil (Solid Explorer es mi favorito).

Por WiFi pasar el archivo de mapas de alrededor de 1GB tardó más de 3 horas en pasarse al 50%, con el consecuente calentamiento y gasto de batería del móvil. Mediante USB 3.0, utilizando el protocolo PTP, unos pocos segundos.

 

 

Una vez copiados los archivos, abrimos OruxMaps y comprobamos que el mapa se lee a la perfección.

Algo interesante es que con MOBAC podemos añadir varias fuentes de mapas además de las que ya vienen. Una forma de hacerlo es con un mapa WMS (Web Map Service). Para ello, en la carpeta:

 

<directorio_raíz_del_MOBAC>/mapsources/

Debemos añadir un archivo ".xml" que contenga lo siguiente:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<customWmsMapSource>
<name>NOMBRE</name>
<minZoom>0</minZoom>
<maxZoom>20</maxZoom>
<tileType>png</tileType>
<version>1.1.1</version>
<url>http://url_del_wms?</url>
<coordinatesystem>EPSG:4326</coordinatesystem>
</customWmsMapSource>

He de decir que no se me da demasiado bien rellenar estos archivos, y aunque parece simple, me ha costado hacerlos funcionar (y en ocasiones me ha resultado imposible detectar dónde podría estar el error). En principio habría que cambiar el nombre, seleccionar la escala mínima y máxima, poner el formato de la imagen y la ruta del servidor. En ocasiones es necesario añadir la capa, mediante la etiqueta <layers>. Aquí podréis encontrar más información al respecto.

Un ejemplo que parece que he conseguido hacer funcionar es el mapa de riqueza de especies de Magrama:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<customWmsMapSource>
<name>Riqueza Especies</name>
<minZoom>0</minZoom>
<maxZoom>20</maxZoom>
<tileType>png</tileType>
<version>1.1.1</version>
<url>http://wms.magrama.es/sig/Biodiversidad/RiquezaEspecies/wms.aspx?</url>
<coordinatesystem>EPSG:4326</coordinatesystem>
</customWmsMapSource>

Mapa de Riqueza de Especies de Magrama

La gracia está en que cualquiera de estos mapas que configuremos para ver en MOBAC, podremos descargarlos para su uso offline desde nuestro móvil con OruxMaps.

 

Podéis ver algunos mapas WMS en  el Catálogo de Servicios WEB de Mapas de Biodiversidad del Ministerio de Agricultura, Alimentación y Medio Ambiente, en Instituto Geológico y Minero de España (IGME), y en IDEE, por ejemplo.

Por último, hablaros de la posibilidad de incluir GPXs en MOBAC, de manera que podamos visualizar nuestras rutas sobre los mapas que hayamos configurado previamente.

En resumen, MOBAC ha sido un interesante descubrimiento para mi, con una integración total con OruxMaps, una aplicación que me parece digna de admiración en su campo.

La sexta reencarnación del ave fénix

¿Qué encontrarás en esta entrada?

• Primeras impresiones del Garmin Fénix 6 PRO.
• Comparación con OruxMaps y el SAMSUNG Gear S3 Frontier.

Hoy, en Astaroth's World, unas primeras impresiones del Garmin Fénix 6 PRO. Acabo de hacerme con este estupendo reloj y hoy lo he puesto a prueba en una excursión de senderismo.

Como en otras ocasiones, os dejo el mapa:

En rojo, OruxMaps, mi referencia habitual para estos casos, con datos adquiridos del sensor del móvil. En azul, el Garmin Fénix 6 PRO. Mi primera duda es de dónde obtiene los datos Garmin. A simple vista, ambos registros son muy similares (lo cual, me parece positivo). Tanto es así que surge la duda de si estamos utilizando los datos de GPS del reloj o los del móvil (como pasaba cuando llevabas el SAMSUNG Gear S3 Frontier conectado por Bluetooth al móvil).

Yo tenía la impresión de que el Garmin Fénix 6 PRO era distinto y, efectivamente, si nos fijamos en las sutiles diferencias, vemos que no parecen en absoluto medidas obtenidas de un sensor común con distintas frecuencias.

También se ve que la línea de Garmin se desvía ligeramente más del camino que OruxMaps. Esto desmonta un poco el mito de que los GPS de estos relojes especializados son más precisos que ningún otro dispositivo. Aunque no sea una prueba ideal, el hecho de que el trazado del GPS del móvil (a través de OruxMaps) se adapte mejor a la fotografía satelital, parece un indicativo de que su registro es más fiel a la realidad.

En cualquier caso, noté diferencias mucho más acusadas en el uso del SAMSUNG Gear S3 Frontier. Las diferencias entre OruxMaps (a través del móvil) y el Garmin Fénix 6 PRO son mínimas, hasta el punto de que en esta prueba, de unos 13 Km, coincide el kilometraje hasta en dos decimales.

Estadísticas en Garmin

Estadísticas en OruxMaps

Decir que de OruxMaps me fío en el número de kilómetros, pero no en el resto de estadísticas y, en especial, de los valores que ofrece de la velocidad. En cuestión de recopilar datos, Garmin ofrece infinidad de ellos y de manera bastante correcta.

En relación con la altitud, el punto más alto visitado en esta excursión es la conexión con el Camino de la Barca (aunque está casi a la misma altura que la cima del Cerro de Las Hondas). Según los mapas topográficos, esto sucede a unos 720 msnm.

OruxMaps da 729 msnm, lo cual está casi 10 metros por encima del valor real, mientras que Garmin da unos muy aproximados 721msnm. Garmin también ofrece un modelo corregido en el que, curiosamente, da 730 msnm, acercándose más a la cifra de OruxMaps.

Altitud "corregida" de Garmin

Altitud del altímetro barométrico de Garmin

Valores de OruxMaps

En conclusión, lo más fiable (al menos, en este test) parece ser el altímetro barométrico de Garmin (sin correción alguna).

Respecto a la batería, en 3:46:39 ha gastado menos de un 20% (en torno al 17%). Hay que tener en cuenta que ha ido con todos los sensores activos. Esto es similar a lo que gastaba el Samsung Gear S3 Frontier al ir conectado al móvil. Sin embargo, ya hemos indicado que, en ese caso, el reloj de Samsung ahorraba batería tomando los datos GPS del móvil (lo cual no parece ocurrir en el reloj de Garmin). Dicho esto, quedaría pendiente de comprobar si el gasto llevando el Garmin sin conexión con el móvil es similar al de hoy, o aumenta drásticamente como pasaba en el reloj de Samsung, haciendo que cada vez le costase más aguantar 8 horas.

Respecto a mi experiencia usándolo, excepto por algún problema con la navegación (que parecía liarse en tramos en los que hay que volver sobre tus propios pasos), la verdad es que ha sido agradable. El ver todos esos datos (que además se pueden configurar como quieras) en tiempo real es el sueño de todo geek.

En resumen:

• Precisión del GPS: OruxMaps (usando el GPS del móvil) parece un poco más preciso que el reloj de Garmin, aunque son muy similares.

• Kilometraje: ambos dan un valor idéntico en el recuento de kilómetros. Esto nunca pasaba exactamente con el reloj de Samsung.

• Estadísticas: los datos de Garmin son abrumadores. Ese es su punto fuerte.

• Altitud: La altitud barométrica del Garmin parece muy fiable, no siendo necesaria correcciones posteriores.

• Batería: a falta de más pruebas, parece que aguantaría muy sobradamente mis excursiones más largas (de unas 8 horas).

Seguiré probándolo en próximas excursiones, por lo que seguramente no sea la última vez que oigáis del Garmin Fenix 6 PRO en este blog.

Todos los caminos llevan a Villarejo

Qué encontrarás en esta entrada?

• Comparación entre tres medidas GPS de un mismo recorrido realizadas con dos dispositivos distintos.
• Ubicaciones de Google: una poderosa fuente de datos, pero no siempre fiable.

En la anterior entrada os hablada de mi último paseillo (Orusco - Villarejo). Allí os mostraba la ruta que seguí, pero he caído en que para esa excursión en concreto tengo tres juegos de datos "distintos", así que me he puesto a compararlos (zoom en el mapa de abajo para ver las diferencias).

Los juegos de datos

El primer juego de datos es el de Oruxmaps (en el mapa está en rojo). Este es el que suelo considerar más fiable. Los datos son obtenidos mediante el GPS del móvil (SAMSUNG Galaxy Note 9), teniendo configurada la frecuencia y otros parámetros en la aplicación.

El segundo juego de datos es el del smart watch Samsung S3 Frontier (azul), que son adquiridos mediante la aplicación S-Health. Esta fuente es completamente independiente, porque llevé reloj y teléfono desconectados entre sí. Esto hizo que el reloj gastase muchísima más batería ya que tenía que utilizar su GPS integrado, en lugar de leerlo del GPS del móvil. Con lo cual, son dos juegos de datos completamente independientes.

El tercer juego de datos (negro) es un poco "trampa". Se trata de los datos que automáticamente guarda Google en su historial de ubicaciones y que, como he comentado en anteriores ocasiones, podéis descargar y utilizarlo a vuestro antojo. La "trampa" es que estos datos se obtienen del mismo GPS del móvil que está leyendo Oruxmaps, salvo que con unos parámetros distintos de guardado. Esto hace que básicamente sea la misma ruta con un mayor espaciado entre punto y punto.

Análisis visual

En primera instancia, aparentemente el GPS del reloj da un resultado más preciso cuando lo colocamos sobre un mapa. Es decir, la línea azul se desvía menos del trazado de las calles que las líneas roja y negra (recuerdo que estas dos últimas tienen la misma fuente de datos: el móvil).

Sin embargo, hay ocasiones en las que ninguna va por el trazado de la calle.

Lo cual nos deja dos alternativas: todos estos datos GPS tienen un error muy patente a estas escalas, o el mapa es impreciso. Personalmente, y sin ningún motivo para ello, me inclino por una combinación de ambas causas, dándole más peso al error de los GPS.

También hay alguna ocasión en la que las líneas asociadas a las medidas del móvil se ajustan mejor que las del reloj, pero siendo justos, es en mucho menor proporción.

En el tramo de la iglesia de Carabaña se ve perfecto. Este error lo vi a tiempo real, mientras hacía la ruta, despistándome bastante.

Lo primero, aclarar que los mapas de Google no están exentos de errores y aunque aperezca la iglesia en la esquina inferior izquierda, realmente es el edificio del centro del mapa (en Valdaracete el error es aún peor, parece que Google quisiera escondernos las iglesias xD). El caso es que bordeé la iglesia haciendo un círculo  (aproximadamente, la línea azul), pero en el GPS del móvil aparecía algo bastante más raro, como se ve arriba.

Comparación de estadísticas

Los datos según cada fuente, son los siguientes.

ORUXMAPS

• Distancia: 28,0 km
• Duración: 8 horas, 22 minutos y 23 segundos
• Velocidad media: 3,3 km/h
• Elevación mínima: 575 m
• Elevación máxima: 788 m
• Ascenso total: 736 m
• Descenso total: 595 m

S-HEALTH

• Distancia: 27,5 km
• Duración: 8 horas, 22 minutos y 10 segundos
• Velocidad media: 3,3 km/h
• Elevación mínima: 539 m
• Elevación máxima: 751 m
• Ascenso total: 705 m
• Descenso total: 559 m

Las de Google no se calculan automáticamente porque el formato de los datos es distinto (KML en lugar de GPX).

Como vemos, los datos son similares, aunque con el reloj he perdido medio kilómetro (tomando como bueno el valor del móvil, que tiene una frecuencia de muestreo mayor, el error del reloj sería menor al 2%). La diferencia de tiempos (13 segundos) se debe claramente al tiempo que tardé en activar/parar cada dispositivo en relación con el otro. La velocidad media coincide, lo que es un buen indicador.

Las elevaciones son un caso a parte. No coinciden ni los valores absolutos (que son unos 36 m mayores en Oruxmaps) ni los acumulados (lo cual no se explicaría simplemente con un error de cero de 36 m). Sin embargo, si coincide la diferencia de cota máxima y mínima (entorno a 213 m).

En cualquier caso, la discrepancia en la altitud y sus cálculos derivados no es nada nuevo. Abajo os muestro el análisis de GPSies con los mismos datos.

El misterio de Google

Investigando sobre el tema, me he dado cuenta de algo curioso: ¡Google nos miente en el historial de ubicaciones! Y lo peor es que muestra burdas medidas del GPS, dando la apariencia de una falta enorme de precisión, cuando realmente cuenta con datos bien precisos. Me explico mejor bajo el GIF.

 

 

Como veis, en un tramo en el que estoy realizando mediciones continuas con el GPS del móvil, Google aprovecha esas medidas precisas y guarda con detalle el recorrido (línea negra del mapa con varias líneas). Sin embargo, se ve que a la hora de mostrarlo en el historial de ubicaciones, prima la necesidad de encajar con alguno de los puntos definidos en los mapas de Google.

 

Esto puede ser útil para medidas menos precisas: al pasar cerca e una pizzería a la hora de cenar, y salir de allí una hora después, aunque el GPS no te marque dentro de la pizzería podría ser buena idea sugerir que has estado cenando en ese local. Sin embargo, alterar medias precisas en un caso como este sólo consigue distorsionar los recorridos y acortar las distancias, de manera que hace menos fiable las estadísticas que se muestran en esa sección.

 

Conclusiones

Basándome en el análisis visual, diría que el GPS del reloj tiene más precisión que el del móvil, si bien es verdad que la diferencia es pequeña, que el reloj también falla a veces, que no se puede configurar la frecuencia de muestreo en S-Health (según creo, y esto se traduce en un acortamiento irreal de las distancias), que no se pueden añadir waypoints y que el consumo de batería es excesivo. Por todo ello, aunque intentaré seguir tomando ambas medidas en paralelo, creo que seguiré usando los valores de Oruxmaps desde el GPS del móvil.

Como vimos en una entrada anterior, los datos de la altitud no son buenos en ningún caso. Lo más aproximado que hay (a juzgar por lo marcado en los mapas), son los datos que muestra GPSies tras la corrección automática de altitudes que realiza al subir una ruta.

 

 

Y la última conclusión es que no os fiéis de las distancias del historial de ubicaciones de Google, ya que nos roba algún que otro kilómetro. Ya no volveré a mirar con los mismos ojos los kilómetros que me quedan para llagar a la luna.

¡Mira por dónde pisas! (con MATLAB/OCTAVE)

Qué encontrarás en esta entrada?

• Análisis en OCTAVE de un ".gpx".

Algunos de vosotros quizás conozcáis mi oscura obsesión por hacer grafiquitas de todo en MATLAB (u OCTAVE). Tras la entrada del otro día, no he podido resistirme a intentar pasar los datos al ordenador y analizarlos por mi cuenta. En esta entrada os doy unas pinceladas de cómo lo he hecho y os muestro algunos resultados.

El primer paso, es hacer que un archivo ".gpx" sea inteligible para MATLAB/OCTAVE. Después de ver algún módulo para OCTAVE (que es lo que tengo ahora mismo instalado en el ordenador), no conseguí cargarlo por problemas de dependencias... así que "no me compliqué", y me hice mi propio script en Shell de Linux que leyese el ".gpx" como un archivo de texto, extrajese los datos de latitud, longitud y elevación, y crease con ellos un archivo ".m" que pudiese ejecutar en MATLAB/OCTAVE.

Izquierda: datos originales de un ".gpx". Derecha: archivo ".m".

Una vez con los datos en un ".m" estamos listos para jugar. En la primera imagen vemos una especie de cuadro de mandos. Arriba a la izquierda tenemos el mapa de la ruta sobre una maya de líneas que representan la superficie terrestre. A su derecha, tenemos un globo terráqueo en el que se representa el punto donde se localiza la ruta. Bajo estas, se encuentra el clásico perfil de altitud, y más abajo, el perfil de velocidades.

Para esta prueba he utilizado los datos de GPSies de mi última ruta.

Podemos utilizar, por tanto, estos datos para comparar los resultados. Vemos que la forma de la ruta es similar (si bien, en mi versión la estética es un poco más minimalista, puesto que no muestra un mapa debajo). Sin embargo, lo que sí incluye es la altitud, de manera que representa la ruta en 3D, y calcula las distancias teniendo en cuenta las subidas.

Arriba se muestra el perfil de la ruta. A la derecha, los dos cerros más elevados que el resto. La línea gris del suelo representa la superficie plana a la altura del mar. Se observa también que la curvatura de la tierra a estas escalas es demasiado pequeña como para suponer una corrección significante en la medida de las distancias.

Y hablando de curvaturas, se ha tenido en cuenta la corrección del elipsoide. La tierra es más achatada por los polos que por el ecuador, por lo que no es una esfera, sino un "elipsoide oblato". Las distancias de la ruta se calculan basándose en la posición que tienen sobre la superficie terrestre dada su latitud, longitud y elevación, por lo que es importante conocer con exactitud el radio terrestre en cada punto. Para ello me ha sido muy útil esta respuesta en Xataka Ciencia, sin embargo, a la hora de implementarlo punto a punto, suponía un esfuerzo de computación considerable, por lo que se ha tomado un valor escalar constante del radio de La Tierra para toda la ruta basada en la latitud inicial.

Con todo, esto el resultado es... un poco pobre.

Y es que aún dista un poco de los datos de GPSies, que sin lugar a dudas son más aproximados a los reales:

• Distancia plana: 29,77 Km frente a 32,31 Km de GPSies.

• Distancia con elevación: 29,98 Km (+220m) frente a 32,51 Km (+200m) de GPSies.

• Tiempo: Respecto al tiempo, he de decir que los datos que exporta GPSies después de transformarlos desde OruxMaps (como hablábamos el otro día) son un poco raros, con lo cual falla cualquier medida derivada, como las velocidades. Esto sale algo mejor si utilizamos el archivo original de OruxMaps.

• Elevación: Los datos de elevación máxima, mínima y su diferencia son correctos. Se discrepa en la subida acumulada, que sale mayor que en GPSies, pero que parece que en este caso su cálculo tampoco está muy claro, porque ofrecen dos formas de hacerlo, una de ellas experimental.

Por último, he analizado el intervalo de muestreo. Mientras que en el archivo original de OruxMaps el intervalo de muestreo es de 2 segundos salvo errores en la precisión del GPS (según mi configuración actual), en el caso de GPSies (que no es más que una adaptación del archivo original de OruxMaps) es una auténtica orgía de valores:

Hay que tener en cuenta esto ya que es habitual hacer estimaciones pensando que el intervalo de muestreo es contante. En este caso, esas aproximaciones se alejarán notablemente de la realidad.

Y hasta aquí mi primer contacto con el análisis de datos ".gpx" en MATLAB/OCTAVE. No sé vosotros, pero yo he echado la mañana con esta tontería :p...