¿La mejor modelo GPS pistas de almacenamiento, visualización y análisis?

Question

Estoy pensando en la escritura de software para lidiar con GPS Tracks y Waypoints (en su mayoría almacenar, mostrar y calcular medidas tales como la velocidad, el grado, y algunas estadísticas simples).

Me pregunto cuál debe ser el más conceptualmente sólido modelo de datos con respecto a trackpoints, y aquí están algunos de los "candidatos":

1. Teniendo en cuenta las Pistas como las secuencias de los Trackpoints:

   1.1. Las pistas son considerados "2D", ya que las proyecciones de los mapas son en 2D. Trackpoints podría o no haber elevación, puede o no tener la marca de hora. La elevación y la marca de tiempo se tienen en cuenta los "extras", "opcional". Para aplicaciones terrestres, elevación es una función directa de lat/lon (que se consigue a través de la DEM);

   1.2. Las pistas son considerados "3D" ya que el espacio geográfico es, en efecto 3D, y la trayectoria del receptor es 3D (proyección 2D es así una forma de reducción de datos). Marca de tiempo puede o no estar presente (la pista de que podría haber sido dibujados a mano).

   1.3. Las pistas son considerados "4D" (3 espaciales + tiempo). Por lo tanto, un dibujado a mano el mapa es un caso especial donde la elevación y la fecha y hora son null o, de lo contrario no existe, pero el Trackpoint propiedades son siempre "no".

2. Las pistas son considerados los diccionarios de los arroyos, donde todas las corrientes tienen la misma longitud. Hay una lista de las latitudes, una lista de longitudes, una lista de elevaciones, una de las marcas de tiempo, etc. Esto hace más fácil para el cálculo de estadísticas de cada propiedad, y el concepto de Trackpoint se convierte en "virtual" en un sentido, ya que es una sección transversal de muchas corrientes.

Si la he entendido a la derecha, el formato GPX adopta 1.1., KML adopta 1.2. (con el apoyo de fecha y hora), y Strava API adopta 2. (en formato JSON), pero al final estos son sólo los formatos de ARCHIVO para la serialización y almacenamiento, no necesariamente para el modelado, representación computacional y numbercrunching.

Hay alguna forma de que se de la copa, en un objeto-orientado sentido, y por qué? (Yo creo que el tipado fuerte y sensible a modelar a menos evitar operaciones que no tiene sentido).

EDIT: algunos "intrigante" preguntas adicionales:

• Es un dibujado a mano de la pista CONCEPTUALMENTE lo mismo que un dispositivo de grabado tracklog? Deben ser de tipos de datos diferentes?
• Debe ser considerado "correcto" KML tiendas null elevaciones como el cero? El cero ES una elevación, y si usted no sabe la elevación no debe asignar un cero, ¿no?
• Debe asunto, en una pista con la elevación, si la elevación es extraído del DEM de datos ("offline") o a partir de los datos del GPS o de la presión barométrica de datos ("en el campo")? Debe ser señalado en el objeto de Pista? Guardado a las diferentes propiedades del Trackpoint? Ignorado? Deben ser diferentes de la colección de tipos de datos?
• Si puedo editar un dispositivo pista grabada en un editor de mapas (agregar, mover y eliminar puntos), o combinar las pistas de diferentes fechas, cómo debe ser la hora en la trackpoints ser manejado? Deben ser "resetted" a null? Si un objeto (trackpoint colección) de un tipo diferente de ser creado a partir de las anteriores?

Answer 1

No creo que esta pregunta en realidad puede ser contestada de forma definitiva, ya que hay muchas, muchas maneras de acercarse a este ..

Sin embargo, estos pensamientos pueden ser relevantes:

El almacenamiento de los datos es relativamente poco importante. Independientemente del mecanismo que se utilice, de la Base de datos, JSON, KML, etc, todavía es "plana de almacenamiento".

Lo importante es el software que se utiliza y cómo se representan los datos en el Software para que usted pueda llevar a cabo su modelado.

La velocidad está disponible en dos formas, la distancia de x tiempo o como una salida de un dispositivo GPS, que es donde está el abastecimiento de sus datos. Por lo tanto, el tiempo se vuelve irrelevante otra manera que como un artículo informativo.

Además, también se puede considerar el tiempo mediante el uso de un desplazamiento desde el inicio de la pista. Si usted tiene la velocidad y la distancia, entonces usted puede calcular los tiempos en los puntos. (la distancia entre dos puntos puede ser determinado por una serie de diferentes métodos)

La elevación debe ser considerada parte de un Modelo Espacial, son relevantes para determinar un montón de información interesante sobre la pista en sí, por ejemplo, el grado puede ser calculado que permite entender las variaciones de velocidad a lo largo de una pista. Si no hay ninguna nota, ningún tipo de ralentización o aumento de la velocidad puede haber sido debido a retirar el pie del acelerador.

En términos de la fusión de las pistas y dibujado a mano de las pistas, el tiempo es de poca relevancia. Usted puede aplicar arbitraria de velocidades para determinar el tiempo, por ejemplo, cuánto tiempo para recorrer una pista a una velocidad determinada. Si desea combinar pistas de varios días de diferencia, los datos simplemente no tienen sentido por lo que tendrá que restablecer los campos de tiempo, posiblemente usando las compensaciones de la forma de la pista principio.

Si la elevación no se conoce, no se sabe, por lo tanto no debe ser cero. Tampoco debe ser negativa, tan negativa elevaciones son válidos de elevación. (En una debajo del nivel del mar del valle, de la mina rajo, etc)

Sí, los DEMÓCRATAS están disponibles, Sí que se puede extraer de ellos. Va a ser lo suficientemente preciso? Poco probable, a menos que la precisión no es un problema. GPS o barométrica siempre Elevaciones será mejor que te puede pasar.

Así que para intentar dar una respuesta que pasa cerca de:

Almacenar los datos en cualquier plano formato que quieras, pero yo recomendaría, Postgresql con PostGIS es una buena opción, maneja el 3D muy bien. Usted puede entonces usar la amplia gama de funciones espaciales en PostGIS para manipular/modelo de los datos.

Si utiliza algún tipo de programa personalizado a desarrollar, utilizar un enfoque Orientado a Objeto, en lugar de matrices. Si se utilizan las matrices, usted puede también utilizar una base de datos.

Answer 2

Como ya se ha mencionado en otra respuesta, hay muchos enfoques diferentes. Desde que me pidió "conceptualmente sólido modelos de datos", después de un montón de investigación, he encontrado dos grandes cuerpos de conocimiento que proporcionan dos enfoques muy diferentes a los "objetos en movimiento" concepto, y tiene una gran cantidad de superposición (en un buen sentido):

1. Los libros de Gennady y Natalia Andrienko, publicado por Springer Verlag, por ejemplo, el excelente análisis Visual de Movimiento (entre otros, de la misma editorial). Muy recomendable.
2. El Resumen de Especificaciones (esquemas conceptuales) de la ISO/OGC (ISO 191xx normas), especialmente ISO 19107 Espacial (Esquema), 19108 (Temporal Esquema), 19111 (Referencia Espacial por Coordenadas), 19141 (Rasgos en Movimiento) y 19148 (Referencia Lineal)