Wie lassen sich GPS-Tracks für die Speicherung, Visualisierung und Analyse am besten modellieren?

Ich denke darüber nach, eine Software für den Umgang mit GPS-Tracks und Wegpunkten zu schreiben (hauptsächlich zum Speichern, Anzeigen und Berechnen von Metriken wie Geschwindigkeit, Steigung und einigen einfachen Statistiken).

Ich frage mich, was das konzeptionell robusteste Datenmodell in Bezug auf Trackpoints sein sollte, und hier sind einige "Kandidaten":

1. Tracks als Sequenzen von Trackpoints betrachten:

   1.1. Spuren werden als "2D" betrachtet, da Kartenprojektionen 2D sind. Trackpoints haben möglicherweise eine Höhe oder einen Zeitstempel. Höhe und Zeitstempel gelten als "Extras", "optional". Für terrestrische Anwendungen ist die Höhe eine direkte Funktion von lat / lon (erhältlich über DEM).

   1.2. Spuren werden als "3D" betrachtet, da der geografische Raum tatsächlich 3D ist und die Flugbahn des Empfängers 3D ist (2D-Projektion ist daher eine Form der Datenreduktion). Möglicherweise ist ein Zeitstempel vorhanden oder nicht (die Spur wurde möglicherweise von Hand gezeichnet).

   1.3. Tracks werden als "4D" (3 räumliche + Zeit) betrachtet. Daher ist eine handgezeichnete Karte ein Sonderfall, bei dem Höhe und Zeitstempel vorhanden sind nulloder auf andere Weise nicht vorhanden sind, die Trackpoint-Eigenschaften jedoch immer "da" sind.

2. Tracks werden als Wörterbücher von Streams betrachtet, bei denen alle Streams gleich lang sind. Es gibt eine Liste von Breitengraden, eine Liste von Längengraden, eine Liste von Höhen, eine Liste von Zeitstempeln usw. Dies erleichtert die Berechnung von Statistiken für jede Eigenschaft, und das Konzept von Trackpoint wird in gewissem Sinne "virtuell", da es sich um ein Querschnitt vieler Bäche.

Wenn ich richtig verstanden habe, übernimmt das GPX-Format 1.1, KML 1.2. (ohne Unterstützung für Zeitstempel) und Strava API übernimmt 2. (im JSON-Format), aber am Ende handelt es sich nur um FILE-Formate für die Serialisierung und Speicherung, nicht unbedingt für die Modellierung, rechnerische Darstellung und Zahlenkalkulation.

Gibt es eine Form, die objektorientiert vorzuziehen ist, und warum? (Ich glaube, dass starke Typisierung und vernünftige Modellierung zumindest Operationen vermeiden würden, die keinen Sinn ergeben.)

EDIT: einige "faszinierende" Zusatzfragen:

• Ist eine von Hand gezeichnete Spur KONZEPTUELL dasselbe wie ein von einem Gerät aufgezeichnetes Tracklog? Sollten sie unterschiedliche Datentypen haben?
• Sollte es als "korrekt" betrachtet werden, dass KML Null-Erhebungen als Null speichert? Null IST eine Erhebung, und wenn Sie die Erhebung nicht kennen, sollten Sie ihr keine numerische Null zuweisen, nicht wahr?
• Sollte es bei einer Strecke mit Höhenangabe eine Rolle spielen, ob die Höhenangabe aus DEM-Daten ("offline") oder aus GPS-Daten oder Luftdruckdaten ("vor Ort") extrahiert wird? Soll dies im Track-Objekt markiert werden? In verschiedenen Trackpoint-Eigenschaften gespeichert? Ignoriert? Sollten sie unterschiedliche Sammlungsdatentypen sein?
• Wenn ich eine vom Gerät aufgezeichnete Spur in einem Karteneditor bearbeite (Hinzufügen, Verschieben und Entfernen von Punkten) oder Spuren von verschiedenen Daten kombiniere, wie sollen die Zeitstempel in den Spurpunkten behandelt werden? Sollten sie auf null "zurückgesetzt" werden? Soll ein Objekt (Trackpoint-Sammlung) eines anderen Typs als das vorherige erstellt werden?

Ich glaube nicht, dass diese Frage wirklich definitiv beantwortet werden kann, da es viele, viele Möglichkeiten gibt, dies zu erreichen.

Diese Gedanken können jedoch relevant sein:

Die Datenspeicherung ist relativ unwichtig. Unabhängig davon, welchen Mechanismus Sie verwenden, wie z. B. Datenbank, JSON, KML usw., handelt es sich immer noch um "Flat Storage".

Wichtig ist, welche Software Sie verwenden und wie Sie die Daten in der Software darstellen, damit Sie Ihre Modellierung durchführen können.

Geschwindigkeit ist auf zwei Arten verfügbar: Entfernung x Zeit oder als Ausgabe von einem GPS-Gerät, von dem aus Sie Ihre Daten beziehen. Daher wird Zeit außer als Informationselement irrelevant.

Außerdem können Sie die Zeit berücksichtigen, indem Sie einen Versatz vom Anfang der Spur verwenden. Wenn Sie die Geschwindigkeit und die Entfernung haben, können Sie die Zeiten an den Punkten berechnen. (Der Abstand zwischen zwei Punkten kann mit verschiedenen Methoden bestimmt werden. )

Die Höhe sollte als Teil des räumlichen Modells betrachtet werden. Sie ist relevant, um eine Vielzahl interessanter Informationen über die Strecke selbst zu ermitteln. Beispielsweise kann die Steigung berechnet werden, um dann Geschwindigkeitsschwankungen entlang einer Strecke zu verstehen. Wenn es keine Steigung gibt, kann eine Verlangsamung oder Geschwindigkeitssteigerung darauf zurückzuführen sein, dass der Fuß vom Gaspedal genommen wurde.

Für das Zusammenführen von Tracks und handgezeichneten Tracks ist die Zeit von geringer Bedeutung. Sie können beliebige Geschwindigkeiten anwenden, um die Zeit zu bestimmen, zum Beispiel, wie lange eine Spur mit einer bestimmten Geschwindigkeit zurückgelegt werden soll. Wenn Sie Titel im Abstand von mehreren Tagen zusammenführen, sind Ihre Daten einfach nicht sinnvoll, sodass Sie die Zeitfelder zurücksetzen müssen, möglicherweise mithilfe von Offsets vom Titelanfang.

Wenn die Höhe nicht bekannt ist, ist sie nicht bekannt, daher sollte sie nicht Null sein. Es sollte auch nicht negativ sein, da negative Erhebungen auch gültige Erhebungen sind. (In einem Tal unter dem Meeresspiegel, Minengrube usw.)

Ja, DEMS sind verfügbar. Ja, Sie können daraus extrahieren. Wird das genau genug sein? Unwahrscheinlich, es sei denn, Genauigkeit ist kein Problem. Mit GPS oder Barometer gelieferte Höhen sind das Beste, was Sie bekommen können.

Versuchen Sie also, Ihnen eine Antwort zu geben, die naheliegt:

Speichern Sie die Daten in einem beliebigen flachen Format, aber ich würde empfehlen, dass PostGRES mit PostGIS eine gute Option ist, da es 3D gut handhabt. Sie können dann die umfangreichen räumlichen Funktionen in PostGIS verwenden, um Ihre Daten zu bearbeiten / zu modellieren.

Wenn Sie ein benutzerdefiniertes Programm verwenden, das Sie entwickeln, verwenden Sie einen objektorientierten Ansatz anstelle von Arrays. Wenn Sie Arrays verwenden, können Sie auch eine Datenbank verwenden.

Wie bereits in einer anderen Antwort erwähnt, gibt es viele verschiedene Ansätze. Da ich nach "konzeptionell robusten Datenmodellen" gefragt habe, habe ich nach langer Recherche zwei große Wissensbestände gefunden, die zwei ganz unterschiedliche Ansätze für das Konzept "bewegter Objekte" bieten und sich (im guten Sinne) stark überschneiden:

1. Die Bücher von Gennady und Natalia Andrienko, herausgegeben vom Springer Verlag, zum Beispiel die exzellente Visual Analytics of Movement (unter anderem vom selben Verlag). Sehr empfehlenswert.
2. Die abstrakten Spezifikationen (konzeptionelle Schemata) von ISO / OGC (ISO 191xx-Normen), insbesondere ISO 19107 (räumliches Schema), 19108 (zeitliches Schema), 19111 (räumliche Referenzierung durch Koordinaten), 19141 (bewegliche Features) und 19148 (lineare Referenzierung)