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?
fuente
<>y{}para ayudarlo a organizar sus datos, y metadatos, lo está haciendo mal.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.
fuente
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):
fuente