Newsgroup: it.comp.java
Titolo: Dati GPS ridondanti

Ciao a tutti,
sto sviluppando un sistema per il monitoraggio della posizione di
mezzi, il quale acquisisce i dati GPS ad intervalli di 1 secondo. Per
ottimizzare lo spazio occupato sarebbe opportuno non effettuare lo
storing di tutti i dati, perchè spesso ridondanti. Ad esempio, se un
mezzo sta fermo, o si muove in linea retta, per X secondi, sarebbe
ridondante archiviare tutti i secondi...
Avreste qualche suggerimento in merito?
Grazie mille in anticipo
Carmelo

 Avreste qualche suggerimento in merito?
se la distanza tra due punti non supera la soglia X allora non memorizzi
il punto.
Se la soglia X e' piccola come credo puoi considerare la superfcie
terrestre piana e semplificarti i calcoli...altrimenti esistono classi
gia' fatte che ti calcolano la distanza tra due coordinate.


Dovrei forse utilizzare un sistema GIS esistente?
Se si, sapreste consigliarmene uno open source?


Ok, dovrei considerare un range di tolleranza, perchè la posizione GPS
non è precisa in modo assoluto... Infatti, anche rimanendo fermi, in
alcuni istanti la posizione potrebbe risultare diversa...
Capisco come potrei fare nel caso in cui il mezzo è fermo, ma nel caso
in cui si muove in linea retta, come fare per capire che il moto è
rettilineo? Calcolando la distanza tra due punti non dovrebbe
funzionare in questo caso...

 rettilineo? Calcolando la distanza tra due punti non dovrebbe
il gps ti da punti e tra un punto e l'altro puoi solo assumere che il
moto sia stato rettilineo.


Certamente, il GPS fornisce la posizione ogni secondo, quindi il moto
in 1 secondo può assumersi rettilineo. Ma volevo intendere un'altra
cosa: per evitare di memorizzare dati ridondanti sarebbe opportuno
riconoscere se il mezzo si muove su una linea retta, in modo da non
memorizzare ogni posizione della retta...

 memorizzare ogni posizione della retta...
ti tieni in mente gli ultimi 2 punti su db e gli ultimi 2 punti letti
dal gps.
se le due rette risultanti sono "compatibili" ignori.
se non lo sono memorizzi nel db i 2 punti.
poi avanti cosi' leggendo un punto alla volta.
facendo cosi' pero' se il mezzo va in linea retta per 20 km nel db hai
l'inizio del rettilineo e basta fino a che non fa una curva, quindi se
ti interessa tracciare la posizione in tempo quasi reale metterei
comunque un punto ogni X metri anche se sto andando in linea retta.

 poi avanti cosi' leggendo un punto alla volta.
oppure per il controllo di "compatibilita" forse e' meglio usare
l'ultimo punto e verificarlo con la retta del database. i 2 punti in
memoria ti servono comunque per aggiornare il dd.
forse cosi' limiti i falsi positivi ma non ci giurerei. bisogna provare
e trovare l'algoritmo giusto.

 poi avanti cosi' leggendo un punto alla volta.
Non funziona necessariamente. Supponiamo che ci si muova descrivendo una 
circonferenza abbastanza ampia. Tre punti consecutivi potrebbero 
risultare allineati, entro il limite della tolleranza, senza che ciò 
debba necessariamente avvenire per, mettiamo, 10 punti consecutivi. 
Punti 1-2-3 quasi allineati, 2-3-4 quasi allineati, 4-5-6 quasi 
allineati, ma 1-2-3-4-5 non allineati.
Bisognerebbe memorizzare le direzioni minima e massima del moto (per 
esempi0, l'angolo tra la linea del movimento e il parallelo), e quando 
lo scarto tra minimo e massimo è maggiore di un tot il moto non si 
intende più rettilineo, e si ricomincia.


Ho calcolato che il DB delle posizioni dei mezzi dovrebbe occupare
circa 41GB/anno. Pensate che per limitarne la dimensione dovrei
cercare di memorizzare solo le variazioni di posizione, oppure
potrebbe essere utile anche individuare i movimenti rettilinei?

On 30 Ott, 15:06, hybris <hybr...@NOSPAMgmail.com> wrote:

Ho calcolato che il DB delle posizioni dei mezzi dovrebbe occupare


 wrote:

Ma é un progetto tuo ? E' aperto ?
Oppure é closed
Se fosse aperto mi piacerebbe ficcare un po il naso a scopo
didattico ...
Ciao


E' un progetto a cui sto lavorando, al momento non open

 potrebbe essere utile anche individuare i movimenti rettilinei?
Togliere le posizioni ridondanti (ossia quando il veicolo è fermo) ha 
senso, un po' meno l'idea di individuare gli spostamenti rettilinei e 
rimuovere le posizione intermedie: anche se lo spostamento è in linea 
retta non è detto che sia percorso a velocità costante, per cui 
perderesti l'informazione che lega la posizione precisa con il tempo.
Per fare un esempio concreto: se un veicolo percorre 50Km in linea 
retta, di cui i primi 20 a una velocità di 5Km/h e il resto a 100Km/h, 
conservando solo le posizioni estreme del percorso poi non sai in che 
punto il veicolo si trovava in un dato istante.
Caso limite e difficilmente riscontrabile in realtà ma penso renda 
l'idea, soprattutto se si considerano i margini di errore dei GPS (sulla 
decina di metri, per quelli civili).
Piuttosto mi orienterei sull'ottimizzazione della compressione dei dati 
archiviati (vedi precedenti domande).
.paolo

 Comunque mon mi sembra una dimensione eccessiva...
La metodologia che ho seguito è stata quella di estrarre le
informazioni dalla stringa NMEA e memorizzarle sui relativi campi di
un db MySql. Nessuna compressione ovviamente, dato che sono su DB,
anzi, lo spazio occupato è quasi il doppio di quello che avrebbero se
fossero in semplice formato testo... Ma se fossero in semplice testo
non sarebbe possibile effettuare query...

 Nessuna compressione ovviamente, dato che sono su DB [...]
Anche MySQL, se non ricordo male (non credo, ma decisamente non è il mio 
motore db preferito), supporta alcune modalità di compressione dei dati.
In alternativa potresti usare un altro db o un formato intermedio tra i 
database e i file di testo, come HDF5 per esempio (pensato proprio per 
casi come il tuo).
Sinceramente però non credo, come dicevo, che ce ne sia la necessità: 
40Gb oggi non sono certo un problema, con un HD da 500 vai avanti più di 
dieci anni.
Piuttosto è da valutare come reagisce MySQL con un carico di questo 
tipo... MyISAM ha un limite di 4Gb, InnoDB non ha questo vincolo.
.paolo


Grazie per la tua risposta Paolo.
Il problema non è tanto la dimensione di 40GB su disco, in quanto come
dici tu con uno da 500GB vado avanti per 10 anni, se campiono la
posizione ogni 10 secondi, altrimenti se prendo la posizione ogni
secondo mi basta per un anno... In ogni caso, il problema è come
reagirebbe MySql (InnoDB) ad un DB di dimensioni maggiori ai 40GB...
Hai detto che HDF5 farebbe al caso mio. Perchè?
Grazie ancora
Carmelo

 Hai detto che HDF5 farebbe al caso mio. Perch�?
E' stato pensato e viene utilizzato quando c'� la necessit� di 
archiviare grosse moli di dati e di accedervi in modo molto rapido.
Vedilo un po' come un database dove si archiviano dati effettuando 
insert in modo continuativo (come quelle provenienti da strumenti 
scientifici o geografici), nessun (o quasi) update e molte select in 
modo veloce.
Ha poi delle interfacce in Java ben curate e documentate.
Per archiviare dati in parte _molto_ simili ai tuoi l'ho usato con 
risultati molto validi (anche se con un altro linguaggio, ma questo 
conta poco).
.paolo