Comment modéliser au mieux les traces GPS pour le stockage, la visualisation et l'analyse?

Je pense à écrire un logiciel pour gérer les traces GPS et les waypoints (principalement stocker, afficher et calculer des mesures telles que la vitesse, la note et quelques statistiques simples).

Je me demande quel devrait être le modèle de données le plus robuste sur le plan conceptuel concernant les points de cheminement, et voici quelques "candidats":

1. En considérant les pistes comme des séquences de Trackpoints:

   1.1. Les pistes sont considérées comme "2D", car les projections cartographiques sont 2D. Les points de suivi peuvent ou non avoir une élévation, peuvent ou non avoir un horodatage. L'élévation et l'horodatage sont considérés comme des "extras", "facultatifs". Pour les applications terrestres, l'élévation est une fonction directe du lat / lon (pouvant être obtenue via DEM);

   1.2. Les pistes sont considérées comme "3D" car l'espace géographique est, en effet, 3D, et la trajectoire du récepteur est 3D (la projection 2D est donc une forme de réduction des données). L'horodatage peut ou non être présent (la piste aurait pu être dessinée à la main).

   1.3. Les pistes sont considérées comme "4D" (3 spatiales + temporelles). Ainsi, une carte dessinée à la main est un cas spécial où l'élévation et l'horodatage sont nullou non présents, mais les propriétés de Trackpoint sont toujours "là".

2. Les pistes sont considérées comme des dictionnaires de flux, où tous les flux ont des longueurs égales. Il y a une liste de latitudes, une liste de longitudes, une liste d'élévations, une des horodatages, etc. Cela facilite le calcul des statistiques de chaque propriété, et le concept de Trackpoint devient "virtuel" dans un sens, car c'est un coupe transversale de nombreux cours d'eau.

Si j'ai bien compris, le format GPX adopte 1.1., KML adopte 1.2. (sans prise en charge de l'horodatage), et l'API Strava en adopte 2. (au format JSON), mais à la fin ce ne sont que des formats FILE pour la sérialisation et le stockage, pas nécessairement pour la modélisation, la représentation informatique et le calcul des nombres.

Existe-t-il une forme préférable, dans un sens orienté objet, et pourquoi? (Je crois qu'au moins un typage fort et une modélisation sensible éviteraient des opérations qui n'ont pas de sens).

EDIT: quelques questions supplémentaires "intrigantes":

• Une piste dessinée à la main est-elle CONCEPTUELLEMENT la même chose qu'un tracklog enregistré par un périphérique? Doivent-ils être de différents types de données?
• Doit-on considérer comme "correct" que KML stocke les élévations nulles à zéro? Le zéro EST une élévation, et si vous ne connaissez pas l'élévation, vous ne devriez pas lui attribuer un zéro numérique, n'est-ce pas?
• Faut-il compter, dans une piste avec élévation, si l'altitude est extraite des données DEM ("hors ligne") ou des données GPS ou barométriques ("sur le terrain")? Doit-il être signalé dans l'objet Track? Enregistré dans différentes propriétés de Trackpoint? Ignoré? Doit-il s'agir de types de données de collection différents?
• Si je modifie une piste enregistrée par un appareil dans un éditeur de carte (ajout, déplacement et suppression de points), ou si je combine des pistes de différentes dates, comment les horodatages des points de trace doivent-ils être traités? Doivent-ils être "remis à zéro" à null? Un objet (collection de points de cheminement) d'un type différent doit-il être créé à partir des anciens?

Je ne pense pas que cette question puisse être résolue de manière définitive car il existe de nombreuses façons d'aborder cela ..

Cependant, ces réflexions peuvent être pertinentes:

Le stockage des données est relativement peu important. Quel que soit le mécanisme que vous utilisez, Base de données, JSON, KML, etc., il s'agit toujours d'un «stockage plat».

Ce qui est important, c'est le logiciel que vous utilisez et la façon dont vous représentez les données dans le logiciel afin que vous puissiez effectuer votre modélisation.

La vitesse est disponible de deux manières, distance x temps ou en tant que sortie d'un appareil GPS, d'où vous vous procurez vos données. Par conséquent, le temps n'est plus pertinent que comme élément d'information.

De plus, vous pouvez également prendre en compte le temps en utilisant un décalage à partir du début de la piste. Si vous avez la vitesse et la distance, vous pouvez calculer les temps aux points. (la distance entre deux points peut être déterminée par un certain nombre de méthodes différentes )

L'élévation doit être considérée comme faisant partie du modèle spatial, elles sont pertinentes pour déterminer toute une série d'informations intéressantes sur la piste elle-même, par exemple, la pente peut être calculée, ce qui vous permet ensuite de comprendre les variations de vitesse le long d'une piste. S'il n'y a pas de pente, tout ralentissement ou augmentation de vitesse peut être dû au retrait du pied de l'accélérateur.

En termes de fusion de pistes et de pistes dessinées à la main, le temps est peu pertinent. Vous pouvez appliquer des vitesses arbitraires pour déterminer le temps, par exemple, combien de temps pour parcourir une piste à une vitesse donnée. Si vous fusionnez des pistes à plusieurs jours d'intervalle, vos données n'auront tout simplement aucun sens, vous devrez donc réinitialiser les champs temporels, en utilisant éventuellement des décalages pour le début de la piste.

Si l'altitude n'est pas connue, elle n'est pas connue, elle ne doit donc pas être nulle. Il ne doit pas non plus être négatif, car les élévations négatives sont également des élévations valides. (Dans une vallée en dessous du niveau de la mer, une mine, etc.)

Oui, les DEMS sont disponibles, oui vous pouvez en extraire. Est-ce que ce sera assez précis? Peu probable, sauf si la précision n'est pas un problème. Les altitudes fournies par GPS ou barométrique seront les meilleures que vous puissiez obtenir.

Donc, pour essayer de vous donner une réponse qui se rapproche:

Stockez les données dans n'importe quel format plat que vous aimez, mais je recommanderais, PostGRES avec PostGIS est une bonne option, il gère bien la 3D. Vous pouvez ensuite utiliser les fonctions spatiales étendues de PostGIS pour manipuler / modéliser vos données.

Si vous utilisez une forme de programme personnalisé que vous développez, utilisez une approche orientée objet plutôt que des tableaux. Si vous utilisez des tableaux, vous pouvez également utiliser une base de données.

Comme déjà mentionné dans une autre réponse, il existe de nombreuses approches différentes. Depuis que j'ai demandé des "modèles de données conceptuellement robustes", après de nombreuses recherches, j'ai trouvé deux grands ensembles de connaissances qui fournissent deux approches très différentes du concept des "objets en mouvement" et qui se chevauchent beaucoup (dans le bon sens):

1. Les livres de Gennady et Natalia Andrienko, publiés par Springer Verlag, par exemple l'excellent Visual Analytics of Movement (entre autres du même éditeur). Hautement recommandé.
2. Les spécifications abstraites (schémas conceptuels) de l'ISO / OGC (normes ISO 191xx), spécialement ISO 19107 (Schéma spatial), 19108 (Schéma temporel), 19111 (Référencement spatial par coordonnées), 19141 (Caractéristiques mobiles) et 19148 (Référencement linéaire)