Come modellare al meglio le tracce GPS per l'archiviazione, la visualizzazione e l'analisi?

Sto pensando di scrivere software per gestire tracce GPS e waypoint (principalmente per memorizzare, visualizzare e calcolare metriche come velocità, grado e alcune semplici statistiche).

Mi chiedo quale dovrebbe essere il modello di dati concettualmente più solido per quanto riguarda i trackpoint, e qui ci sono alcuni "candidati":

Considerando le tracce come sequenze di trackpoint:

1.1. Le tracce sono considerate "2D", poiché le proiezioni delle mappe sono 2D. I punti di tracciamento potrebbero avere o meno elevazione, o meno il timestamp. L'elevazione e il timestamp sono considerati "extra", "opzionali". Per applicazioni terrestri, l'elevazione è una funzione diretta di lat / lon (ottenibile tramite DEM);

1.2. Le tracce sono considerate "3D" poiché lo spazio geografico è, in effetti 3D, e la traiettoria del ricevitore è 3D (la proiezione 2D è quindi una forma di riduzione dei dati). Il timestamp potrebbe essere o meno presente (la traccia potrebbe essere stata disegnata a mano).

1.3. Le tracce sono considerate "4D" (3 spaziali + tempo). Pertanto, una mappa disegnata a mano è un caso speciale in cui elevazione e data / ora sono nullo non sono presenti, ma le proprietà Trackpoint sono sempre "lì".
Le tracce sono considerate dizionari di flussi, in cui tutti i flussi hanno uguale lunghezza. C'è un elenco di latitudini, un elenco di longitudini, un elenco di elevazioni, uno di timestamp, ecc. Ciò rende facile calcolare le statistiche di ogni proprietà e il concetto di Trackpoint diventa "virtuale" in un certo senso, dal momento che è un sezione di molti flussi.

Se ho capito bene, il formato GPX adotta 1.1., KML adotta 1.2. (senza supporto per il timestamp) e Strava API adotta 2. (in formato JSON), ma alla fine questi sono solo formati FILE per la serializzazione e l'archiviazione, non necessariamente per la modellazione, la rappresentazione computazionale e lo scricchiolio dei numeri.

Esiste una forma preferibile, in senso orientato agli oggetti, e perché? (Credo che la tipizzazione forte e la modellazione sensata almeno evitino operazioni che non hanno senso).

EDIT: alcune domande aggiuntive "intriganti":

Una traccia disegnata a mano è CONCETTAMENTE la stessa cosa di un tracklog registrato dal dispositivo? Dovrebbero essere di diversi tipi di dati?
Dovrebbe essere considerato "corretto" che KML memorizzi elevazioni nulle come zero? Lo zero È un'elevazione e se non si conosce l'elevazione non è necessario assegnargli uno zero numerico, vero?
Dovrebbe importare, in una traccia con elevazione, se l'elevazione viene estratta dai dati DEM ("offline") o dai dati GPS o dati barometrici ("sul campo")? Questo dovrebbe essere contrassegnato nell'oggetto Traccia? Salvato in diverse proprietà Trackpoint? Ignorato? Dovrebbero essere tipi di dati di raccolta diversi?
Se modifico una traccia registrata dal dispositivo in un editor di mappe (aggiungendo, spostando e rimuovendo punti) o combinando tracce di date diverse, come devono essere gestiti i timestamp nei trackpoint? Dovrebbero essere "reimpostati" su null? Dovrebbe essere creato un oggetto (raccolta trackpoint) di un tipo diverso dai precedenti?

— heltonbiker
fonte

3. Le tracce sono una raccolta di punti con attributi x, y, z, m [] e time. Un file CSV contenente questi 5 valori per ciascun punto acquisito è più che sufficiente per un modello di dati affidabile. Se hai bisogno di cose fantasiose come <>e {}per aiutarti a organizzare i tuoi dati - e metadati - stai sbagliando.

— nagytech,

Concordo solo con un buon vecchio CSV, rappresenta tutto ciò che il GPS sta registrando. Ma il formato GPX è abbastanza comune per i dispositivi GPS. Questo collegamento può valere qualcosa in quanto sia GPS che KML sono formati di dati XML. stackoverflow.com/questions/1820129/…

— Pete,

Mentre XML è "fantastico" e tutti (per i motivi nel post collegato di @ Pete) nessuno di questi punti è rilevante. Se non altro, l'overhead non fa altro che rallentare il crunching dei numeri e gonfiare i metodi di archiviazione e trasmissione dei dati. Certo, se sei un'operazione mom-n-pop non avrai mai abbastanza dati per affrontare questi problemi e il tuo scricchiolio dei numeri non sarà intenso. Ad ogni modo, non avrai le risorse per sostenere l'operazione così da vicino il metallo, quindi via XML.

— nagytech,

Si noti che questa domanda ha molto più a che fare con la MODELLAZIONE e la progettazione dei dati (rappresentazione della sua essenza concettuale) rispetto all'attuazione effettiva. I commenti si concentrano finora sui formati di file, che è, da quello che penso, ancora più lontano, perché i formati di file dipendono più dal mezzo di implementazione che dalla natura dei dati stessi.

— heltonbiker,

In termini di OO, ho usato una classe Line che può contenere i punti (lat, lng, ele, time, speed, rilevamento, ecc.). E, da lì, rotte che rappresentano "tracce" disegnate a mano o previste e tracce che rappresentano una traccia effettiva con dati tempo / velocità. Concettualmente, penso che siano diversi (disegnati a mano e / o forniti da un cartografo, o simili, rispetto a una traccia reale). I termini sono solo semantica, certo, ma usare tipi reali è stato utile (piuttosto che unirli tutti insieme come "Traccia"). Inoltre, quando si tratta di formati di serializzazione, prenderei in considerazione GeoJSON: en.wikipedia.org/wiki/GeoJSON .

— Charlie Collins,

Risposte:

Non credo che a questa domanda possa effettivamente essere data una risposta definitiva in quanto ci sono molti, molti modi per affrontarlo.

Tuttavia, questi pensieri possono essere rilevanti:

La memorizzazione dei dati è relativamente poco importante. Qualunque meccanismo tu usi, Database, JSON, KML, ecc., È ancora "memoria piatta".

Ciò che è importante è il software che usi e come rappresenti i dati nel software in modo da poter condurre la tua modellazione.

La velocità è disponibile in due modi, distanza x tempo o come uscita da un dispositivo GPS, da dove provengono i tuoi dati. Pertanto il tempo diventa irrilevante se non come elemento informativo.

Inoltre, puoi anche considerare il tempo usando un offset dall'inizio della traccia. Se hai la velocità e la distanza, puoi calcolare i tempi nei punti. (la distanza tra due punti può essere determinata con diversi metodi )

L'elevazione dovrebbe essere considerata parte del modello spaziale, sono rilevanti per determinare tutta una serie di informazioni interessanti sulla traccia stessa, ad esempio è possibile calcolare il grado che consente quindi di comprendere le variazioni di velocità lungo una traccia. In assenza di pendenza, qualsiasi rallentamento o aumento della velocità potrebbe essere stato causato dalla rimozione del piede dall'acceleratore.

In termini di fusione di tracce e tracce disegnate a mano, il tempo è di scarsa rilevanza. È possibile applicare velocità arbitrarie per determinare il tempo, ad esempio, per quanto tempo attraversare una pista a una determinata velocità. Se stai unendo le tracce a distanza di diversi giorni, i tuoi dati semplicemente non avranno senso, quindi dovrai reimpostare i campi temporali, possibilmente usando gli offset dall'inizio della traccia.

Se l'elevazione non è nota, non è nota, pertanto non dovrebbe essere zero. Inoltre, non dovrebbe essere negativo, poiché anche gli aumenti negativi sono validi. (In una valle sotto il livello del mare, miniera, ecc.)

Sì, sono disponibili DEMS, Sì, è possibile estrarre da essi. Sarà abbastanza preciso? Improbabile, a meno che la precisione non sia un problema. GPS o barometri forniti I prospetti saranno i migliori che puoi ottenere.

Quindi, per provare a darti una risposta che si avvicina:

Archivia i dati in qualsiasi formato piatto che ti piace, ma ti consiglio, PostGRES con PostGIS è una buona opzione, gestisce bene il 3D. È quindi possibile utilizzare le ampie funzioni spaziali di PostGIS per manipolare / modellare i dati.

Se si utilizza una qualche forma di programma personalizzato sviluppato, utilizzare un approccio orientato agli oggetti piuttosto che array. Se si utilizzano array, è possibile utilizzare anche un database.

— Mark Cupitt
fonte

Grazie mille per il tuo tempo e interesse, ho trovato la tua risposta molto interessante. Ma con una cosa "non posso" essere d'accordo: quella velocità è la variabile canonica, mentre il tempo no. Questo per molte ragioni, ma principalmente perché la velocità è la derivata della distanza nel tempo. Otterrai sempre una buona velocità e una buona velocità media specialmente (che ho trovato più utile della velocità istantanea), se derivi la distanza del segmento nel tempo del segmento. D'altra parte, se si integrano le velocità, l'errore di integrazione produrrà risultati molto sbagliati dopo un breve numero di campioni.

— Heltonbiker,

Sì, posso ammettere questo punto. tuttavia, l'uso delle tracce GPS è di per sé soggetto a errori di posizione. È tutta una questione di precisione che puoi ottenere. D'accordo, il tempo è abbastanza preciso, ma si otterranno errori anche usando a causa degli errori di posizione GPS. Gli intervalli di un secondo sui punti di tracciamento sono proprio questo, un secondo, ma all'interno del GPS, i suoi algoritmi potrebbero benissimo essere interpolati per arrivare a una posizione stimata. Ovviamente la granularità dei dati avrà un grande impatto su qualsiasi metodo di analisi scelto

— Mark Cupitt,

Molto ben messo ... Ecco perché ho già rinunciato a tracciare la "velocità istantanea" del tutto, cercando una sorta di "velocità media istantanea", che sarebbe: "per ogni dato punto di una traiettoria, la sua velocità media istantanea è la media velocità degli ultimi N minuti. " Trama molto bello e dà un senso appropriato delle variazioni di velocità durante un viaggio. Ma il calcolo corretto può essere complicato ed è probabilmente un po 'intenso dal punto di vista computazionale.

— Heltonbiker,

Come già accennato in un'altra risposta, ci sono molti approcci diversi. Da quando ho chiesto "modelli di dati concettualmente robusti", dopo molte ricerche ho trovato due grandi corpi di conoscenza che forniscono due approcci piuttosto diversi al concetto di "oggetti in movimento" e hanno molte sovrapposizioni (in senso buono):

I libri di Gennady e Natalia Andrienko, pubblicati da Springer Verlag, ad esempio l'eccellente Visual Analytics of Movement (tra gli altri dello stesso editore). Altamente raccomandato.
I astratte Specifiche (schemi concettuali) di ISO / OGC (ISO 191xx norme), specialmente ISO 19107 (Spatial Schema), 19108 (Temporal Schema), 19111 (Spatial Referencing da Coordinate), 19141 (Caratteristiche Moving) e 19148 (Linear riferimento)

— heltonbiker
fonte