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

17

Estoy pensando en escribir un software para lidiar con Tracks y puntos de ruta de GPS (principalmente almacenar, mostrar y calcular métricas como la velocidad, el grado y algunas estadísticas simples).

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

  1. Teniendo en cuenta 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", "opcional". Para aplicaciones terrestres, la elevación es una función directa de lat / lon (que se puede obtener 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 en el que la elevación y la marca de tiempo son null o no están presentes, pero las propiedades del punto de seguimiento siempre están "ahí".

  2. 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 convierte en "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 Strava API adopta 2. (en formato JSON), pero al final estos son solo formatos de ARCHIVO para serialización y almacenamiento, no necesariamente para modelado, representación computacional y compresión numérica.

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

EDITAR: algunas preguntas adicionales "intrigantes":

  • ¿Una pista dibujada a mano CONCEPTUALMENTE es lo mismo que un tracklog grabado por dispositivo? ¿Deben ser de diferentes tipos de datos?
  • ¿Debe considerarse "correcto" que KML almacene las elevaciones nulas como cero? El cero es una elevación, y si no sabes la elevación, no deberías asignarle un cero numérico, ¿no?
  • ¿Debería importar, en una pista con elevación, si la elevación se extrae de datos de DEM ("fuera de línea") o de datos de 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 tipos de datos de colección diferentes?
  • Si edito una pista grabada por 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? ¿Deben ser "restablecidos" a nulo? ¿Debería crearse un objeto (colección de puntos de rastreo) de un tipo diferente de los anteriores?
pregunta heltonbiker 20.06.2013 - 05:24

2 respuestas

4

No creo que esta pregunta pueda responderse definitivamente ya que hay muchas, muchas maneras 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., todavía es "almacenamiento plano".

Lo que es importante es el software que utiliza y la forma en que representa los datos en el Software para que pueda realizar su modelado.

La velocidad está disponible de dos maneras, la distancia x el tiempo o como una salida de un dispositivo GPS, que es desde donde está obteniendo sus datos. Por lo tanto, el tiempo se vuelve irrelevante más que como un 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, entonces puede calcular los tiempos en los puntos. (la distancia entre dos puntos puede ser determinada por una cantidad de métodos diferentes)

La elevación se debe considerar parte del modelo espacial, son relevantes para determinar toda una serie de información interesante sobre la pista en sí, por ejemplo, se puede calcular el grado que 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 la eliminación del pie del acelerador.

En cuanto a la combinación de pistas y pistas dibujadas a mano, el tiempo tiene 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, entonces 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 debe ser cero. Tampoco debe ser negativo, ya que las elevaciones negativas son válidas también. (En un valle bajo el nivel del mar, pozo de minas, etc.)

Sí, los DEMS están disponibles, sí, puede extraerlos. ¿Será lo suficientemente preciso? Es poco probable, a menos que la precisión no sea un problema. GPS o barométrico siempre que Elevations sea lo mejor que puedas obtener.

Entonces, para intentar darle una respuesta que se cierre:

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

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

    
respondido por el Mark Cupitt 22.11.2013 - 09:42
0

Como ya se mencionó en otra respuesta, hay muchos enfoques diferentes. Desde que solicité "modelos de datos robustos desde el punto de vista conceptual", después de mucha investigación, encontré dos grandes cuerpos de conocimiento que brindan dos enfoques muy diferentes al concepto de "objetos en movimiento" y tienen muchos traslapes (en el buen sentido):

  1. Los libros de Gennady y Natalia Andrienko, publicados por Springer Verlag, por ejemplo, el excelente Analítica visual del movimiento (entre otros del mismo editor). Muy recomendable.
  2. 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)
respondido por el heltonbiker 06.10.2014 - 19:18

Lea otras preguntas en las etiquetas