¿Cómo modelar mejor las rutas GPS para almacenamiento, visualización y análisis?

Estoy pensando en escribir software para tratar con GPS Tracks y Waypoints (principalmente almacenar, mostrar y calcular métricas como velocidad, pendiente y algunas estadísticas simples).

Me pregunto cuál debería ser el modelo de datos más robusto conceptualmente con respecto a los puntos de seguimiento, y aquí hay algunos "candidatos":

Considerando las pistas como secuencias de puntos de seguimiento:

1.1. Las pistas se consideran "2D", ya que las proyecciones de mapas son 2D. Los puntos de seguimiento pueden o no tener elevación, pueden o no tener marca de tiempo. La elevación y la marca de tiempo se consideran "extras", "opcionales". Para aplicaciones terrestres, la elevación es una función directa de lat / lon (obtenible a través de DEM);

1.2. Las pistas se consideran "3D" ya que el espacio geográfico es, de hecho, 3D, y la trayectoria del receptor es 3D (la proyección 2D es, por lo tanto, una forma de reducción de datos). La marca de tiempo puede o no estar presente (la pista podría haberse dibujado a mano).

1.3. Las pistas se consideran "4D" (3 espaciales + tiempo). Por lo tanto, un mapa dibujado a mano es un caso especial donde la elevación y la marca de tiempo están nullo no presentes, pero las propiedades del Trackpoint siempre están "allí".
Las pistas se consideran diccionarios de secuencias, donde todas las secuencias tienen la misma longitud. Hay una lista de latitudes, una lista de longitudes, una lista de elevaciones, una de las marcas de tiempo, etc. Esto facilita el cálculo de estadísticas de cada propiedad, y el concepto de Trackpoint se vuelve "virtual" en cierto sentido, ya que es un sección transversal de muchas corrientes.

Si entendí bien, el formato GPX adopta 1.1., KML adopta 1.2. (sin soporte para la marca de tiempo), y la API de Strava adopta 2. (en formato JSON), pero al final estos son solo formatos de ARCHIVO para la serialización y el almacenamiento, no necesariamente para el modelado, la representación computacional y la combinación de números.

¿Hay alguna forma preferible, en un sentido orientado a objetos, y por qué? (Creo que al menos una tipificación fuerte y un modelado sensato evitarían operaciones que no tienen sentido).

EDITAR: algunas preguntas adicionales "intrigantes":

¿Es una pista dibujada a mano CONCEPTUALMENTE lo mismo que un tracklog grabado por el dispositivo? ¿Deberían ser de diferentes tipos de datos?
¿Debería considerarse "correcto" que KML almacena elevaciones nulas como cero? Cero ES una elevación, y si no conoce la elevación, no debería asignarle un cero numérico, ¿no?
¿Debería importar, en una pista con elevación, si la elevación se extrae de datos DEM ("fuera de línea") o de datos GPS o datos barométricos ("en el campo")? ¿Debería estar marcado en el objeto Track? ¿Guardado en diferentes propiedades de Trackpoint? ¿Ignorado? ¿Deberían ser diferentes tipos de datos de recopilación?
Si edito una pista grabada en un dispositivo en un editor de mapas (agregando, moviendo y eliminando puntos), o combino pistas de diferentes fechas, ¿cómo deben manejarse las marcas de tiempo en los puntos de seguimiento? ¿Deberían "restablecerse" a nulo? ¿Debería crearse un objeto (colección de puntos de seguimiento) de un tipo diferente de los anteriores?

— heltonbiker
fuente

3. Las pistas son una colección de puntos con x, y, z, m [] y atributos de tiempo. Un archivo CSV que contiene estos 5 valores para cada punto capturado es más que suficiente para un modelo de datos robusto. Si necesita cosas sofisticadas como <>y {}para ayudarlo a organizar sus datos, y metadatos, lo está haciendo mal.

— nagytech

Estoy de acuerdo con un buen CSV antiguo, representa todo lo que el GPS está grabando. Pero, el formato GPX es bastante común para los dispositivos GPS. Este enlace puede valer algo, ya que tanto GPS como KML son formatos de datos XML. stackoverflow.com/questions/1820129/…

— Pete

Si bien XML es 'genial' y todo (por las razones en la publicación vinculada de @ Pete) ninguno de esos puntos es relevante. En todo caso, la sobrecarga no hace más que ralentizar el procesamiento de números y aumentar los métodos de almacenamiento y transmisión de datos. De acuerdo, si usted es una operación mom-n-pop, nunca tendrá suficientes datos para enfrentar estos problemas, y su cálculo de números no será intenso. De cualquier manera, no tendrá los recursos para mantener la operación tan cerca del metal, por lo que XML se aleja.

— nagytech

Tenga en cuenta que esta pregunta tiene mucho más que ver con el MODELADO y el diseño de datos (representación de su esencia conceptual) que con la implementación real. Los comentarios hasta ahora se centran en formatos de archivo, que es, por lo que pienso, aún más lejos, porque los formatos de archivo dependen más del medio de implementación que de la naturaleza de los datos en sí.

— heltonbiker

En términos OO, he usado una clase de línea que puede contener los puntos (lat, lng, ele, tiempo, velocidad, demora, etc.). Y, a partir de ahí, Rutas que representan "pistas" dibujadas a mano o previstas y Pistas que representan una pista real con datos de tiempo / velocidad. Conceptualmente, creo que son diferentes (dibujado a mano y / o suministrado por un cartógrafo, o tal, frente a una pista real). Los términos son solo semánticos, claro, pero el uso de tipos reales ha sido útil (en lugar de simplemente mezclarlo todo como una "Pista"). Además, cuando se trata de formatos de serialización, consideraría GeoJSON: en.wikipedia.org/wiki/GeoJSON .

— Charlie Collins

Respuestas:

No creo que esta pregunta pueda responderse definitivamente ya que hay muchas, muchas formas de abordar esto ...

Sin embargo, estos pensamientos pueden ser relevantes:

El almacenamiento de datos es relativamente poco importante. Independientemente del mecanismo que utilice, base de datos, JSON, KML, etc., sigue siendo "almacenamiento plano".

Lo importante es el software que usa y cómo representa los datos en el Software para que pueda realizar su modelado.

La velocidad está disponible de dos maneras, distancia x tiempo o como salida de un dispositivo GPS, que es de donde obtiene sus datos. Por lo tanto, el tiempo se vuelve irrelevante más que como elemento informativo.

Además, también puede considerar el tiempo utilizando un desplazamiento desde el inicio de la pista. Si tiene la velocidad y la distancia, puede calcular los tiempos en los puntos. (la distancia entre dos puntos se puede determinar por diferentes métodos )

La elevación debe considerarse parte del Modelo espacial, son relevantes para determinar una gran cantidad de información interesante sobre la pista en sí, por ejemplo, se puede calcular la pendiente que luego le permite comprender las variaciones de velocidad a lo largo de una pista. Si no hay pendiente, cualquier desaceleración o aumento de velocidad puede deberse a quitar el pie del acelerador.

En términos de fusión de pistas y pistas dibujadas a mano, el tiempo es de poca relevancia. Puede aplicar velocidades arbitrarias para determinar el tiempo, por ejemplo, cuánto tiempo recorrer una pista a una velocidad determinada. Si está fusionando pistas con varios días de diferencia, sus datos simplemente no tendrán sentido, por lo que tendrá que restablecer los campos de tiempo, posiblemente utilizando compensaciones desde el comienzo de la pista.

Si no se conoce la elevación, no se conoce, por lo tanto, no debería ser cero. Tampoco debería ser negativo, ya que las elevaciones negativas también son válidas. (En un valle debajo del nivel del mar, pozo de mina, etc.)

Sí, DEMS están disponibles, sí, puede extraer de ellos. ¿Será lo suficientemente preciso? Poco probable, a menos que la precisión no sea un problema. Las elevaciones proporcionadas por GPS o barométricas serán lo mejor que pueda obtener.

Entonces, para intentar darte una respuesta que se acerque:

Almacene los datos en cualquier formato plano que desee, pero recomendaría PostGRES con PostGIS es una buena opción, maneja muy bien el 3D. Luego puede usar las amplias funciones espaciales en PostGIS para manipular / modelar sus datos.

Si utiliza algún tipo de programa personalizado que desarrolle, utilice un enfoque orientado a objetos en lugar de matrices. Si usa matrices, también puede usar una base de datos.

— Mark Cupitt
fuente

Muchas gracias por su tiempo e interés, su respuesta me pareció muy interesante. Pero con una cosa "no puedo" estar de acuerdo: que la velocidad es la variable canónica, mientras que el tiempo no lo haría. Esto por muchas razones, pero principalmente porque la velocidad es la derivada de la distancia en el tiempo. Siempre obtendrá una buena velocidad, y una buena velocidad media especialmente (lo que me pareció más útil que la velocidad instantánea), si deriva la distancia del segmento sobre el tiempo del segmento. Por otro lado, si integra velocidades, el error de integración dará resultados muy incorrectos después de un pequeño número de muestras.

— heltonbiker

Sí, puedo admitir ese punto. sin embargo, el uso de GPS Tracks está en sí mismo sujeto a errores de posición. Todo depende de la precisión que pueda obtener. De acuerdo, el tiempo es bastante preciso, pero también obtendrá errores al usarlo debido a los errores de posición del GPS. Los intervalos de un segundo en los puntos de seguimiento son solo eso, un segundo, pero dentro del GPS, sus algoritmos bien pueden estar interpolando de todos modos para llegar a una posición estimada. Obviamente, la granularidad de los datos tendrá un gran impacto en cualquier método de análisis elegido

— Mark Cupitt

Muy bien dicho ... Es por eso que ya he dejado de trazar la "velocidad instantánea" por completo, yendo por algún tipo de "velocidad promedio instantánea", que sería: "para cada punto dado en una trayectoria, su velocidad promedio instantánea es el promedio velocidad de los últimos N minutos ". Traza muy bien y da una sensación adecuada de variaciones de velocidad a lo largo de un viaje. Pero el cálculo adecuado puede ser complicado y probablemente sea un poco computacionalmente intensivo.

— heltonbiker

Como ya se mencionó en otra respuesta, hay muchos enfoques diferentes. Como solicité "modelos de datos conceptualmente robustos", después de mucha investigación encontré dos grandes cuerpos de conocimiento que proporcionan dos enfoques bastante diferentes al concepto de "objetos en movimiento", y tienen mucha superposición (en el buen sentido):

Los libros de Gennady y Natalia Andrienko, publicados por Springer Verlag, por ejemplo, el excelente Visual Analytics of Movement (entre otros, de la misma editorial). Muy recomendable.
Las especificaciones abstractas (esquemas conceptuales) de ISO / OGC (normas ISO 191xx), especialmente ISO 19107 (esquema espacial), 19108 (esquema temporal), 19111 (referencia espacial por coordenadas), 19141 (características móviles) y 19148 (referencia lineal)

— heltonbiker
fuente