Con quale precisione devo memorizzare latitudine e longitudine?

103

Stavo leggendo questa domanda qui:

Quale tipo di dati utilizzare quando si archiviano i dati di latitudine e longitudine nei database SQL?

E sembra che il consenso generale sia che usare Decimal (9,6) sia la strada da percorrere. La domanda per me è: quanto è accurato ne ho davvero bisogno?

Ad esempio, l'API di Google restituisce un risultato come:

"lat": 37.4219720,
"lng": -122.0841430

Di quante cifre ho bisogno su -122.0841430? Ho letto diverse guide ma non riesco a capirle abbastanza per capirlo.

Per essere più precisi nella mia domanda: se voglio essere preciso entro 50 piedi dalla posizione esatta, quanti punti decimali devo memorizzare?

Forse una domanda migliore sarebbe effettivamente una domanda non di programmazione, ma sarebbe: quanto più preciso ti dà ogni punto decimale?

È così semplice?

Voce di elenco
x00 = 6000 miglia
xx0 = 600 miglia
xxx = 60 miglia
xxx.x = 6 miglia
xxx.xx = 0,6 miglia
eccetera?

mysql geolocation

— Cittadino
fonte

7

La precisione delle coordinate dipende da DOVE sono quelle coordinate, perché la superficie del pianeta non è una sfera perfetta e anche la distanza dai poli è un fattore MAGGIORE MAGGIORE. Tuttavia, 3 cifre decimali, in media, sono di circa 120 metri / 400 piedi. 4 decimali sarebbero 12 metri / 40 piedi, ecc ...

— Marc B

1

Vedi questa domanda su GIS stackexchange: gis.stackexchange.com/questions/8650/…

— Flimm

1

possibile duplicato di Qual è il tipo di dati ideale da utilizzare quando si memorizza latitudine / longitudine in un database MySQL?

— Gajus

191

Precisione rispetto ai decimali all'equatore

decimal  degrees    distance
places
-------------------------------  
0        1.0        111 km
1        0.1        11.1 km
2        0.01       1.11 km
3        0.001      111 m
4        0.0001     11.1 m
5        0.00001    1.11 m
6        0.000001   0.111 m
7        0.0000001  1.11 cm
8        0.00000001 1.11 mm

rif: https://en.wikipedia.org/wiki/Decimal_degrees#Precision

— Noushad
fonte

4

Se questi sono all'equatore significa che si tratta di errori nel caso peggiore?

— Liath

6

In realtà, l'equatore è il caso migliore. Un grado di latitudine e un grado di longitudine hanno le stesse dimensioni all'equatore (miglia 69), ma un grado di longitudine si riduce a zero quando si avvicina a uno dei due poli. Ecco una spiegazione molto carina: nationalatlas.gov/articles/mapping/a_latlong.html#four

— codingoutloud

11

@codingoutloud Che farebbe questi errori peggiori. O per essere pedanti, questi sono gli errori peggiori per l'utilizzo di lat / lon a livello del mare. Ad un'altitudine di 6.378 m, l'errore aumenta dello 0,1%.

— Scott B

@codingoutload: quel link apparentemente non è più presente :(

— Tom Stambaugh,

1

@Tom Stambaugh: C'è web.archive.org per questo: web.archive.org/web/20070810120810/http://nationalatlas.gov/…

— Stefan Steiger

19

+----------------+-------------+
|    Decimals    |  Precision  |
+----------------+-------------+
|    5           |  1m         |
|    4           |  11m        |
|    3           |  111m       |
+----------------+-------------+

Se vuoi una precisione di 50 piedi (15 m), scegli 4 cifre. Cosìdecimal(9,6)

— Gustav
fonte

9

Se stai usando SQL Server ... Vale la pena notare che una precisione di 1-9 utilizza 5 byte. Quindi potresti usare un decimale (9,6) invece di un decimale (7,4) e sfruttare la maggiore precisione poiché entrambi occupano la stessa quantità di spazio.

— Theo

Per la latitudine, usa (8,6)(o (6,4)per salvare salva un byte (in MySQL).

— Rick James

15

Progetto database e studio questa domanda da tempo. Utilizziamo un'applicazione standard con un backend Oracle in cui i campi dati sono stati definiti per consentire 17 cifre decimali. Ridicolo! È in millesimi di pollice. Nessuno strumento GPS al mondo è così preciso. Quindi mettiamo da parte 17 cifre decimali e affrontiamo la pratica. Il governo garantisce che il loro sistema è buono con "una precisione pseudorange" nel caso peggiore "di 7,8 metri con un livello di confidenza del 95%", ma poi prosegue dicendo che l'effettiva FAA (utilizzando i loro strumenti di alta qualità) ha mostrato che le letture GPS di solito sono buone per entro un metro.

Quindi devi farti due domande: 1) Qual è la fonte dei tuoi valori? 2) Per cosa verranno utilizzati i dati?

I telefoni cellulari non sono particolarmente accurati e le letture di Google / MapQuest sono probabilmente buone solo fino a 4 o 5 decimali. Uno strumento GPS di alta qualità potrebbe farti ottenere 6 (negli Stati Uniti). Ma catturare più di questo è uno spreco di digitazione e spazio di archiviazione. Inoltre, se viene eseguita una ricerca sui valori, è utile che un utente sappia che 6 sarebbe il massimo che dovrebbe cercare (ovviamente qualsiasi valore di ricerca inserito dovrebbe essere prima arrotondato con la stessa precisione del valore dei dati cercato ).

Inoltre, se tutto ciò che devi fare è visualizzare una posizione su Google Maps o inserirla in un GPS per arrivarci, quattro o cinque sono sufficienti.

Devo ridere delle persone qui intorno che inseriscono tutte quelle cifre. E dove stanno misurando esattamente? Pomello della porta d'ingresso? Cassetta postale davanti? Centro di costruzione? In cima alla torre cellulare? E ... lo prendono tutti costantemente nello stesso posto?

Come buon progetto di database, accetterei valori da un utente per forse più di cinque cifre decimali, quindi arrotondare e catturare solo cinque per coerenza [forse sei se i tuoi strumenti sono buoni e il tuo uso finale lo garantisce].

— Greg
fonte

4

Anche se sono d'accordo sul fatto che 17 cifre siano troppe, suggerisco che 6 sia troppo poco se i dati verranno post-elaborati. Quando si eseguono operazioni come una query relativa al raggio ("Funzioni di risposta entro un raggio di 0,5 miglia da questo punto"), gli errori, incluso il troncamento, vengono ingranditi. Se hai bisogno di 6 cifre decimali sull'output di una query di questo tipo, l' input dovrebbe iniziare con molto di più. Il nostro negozio tende a utilizzare DECIMAL (18,15). Il nostro obiettivo è garantire che il db non sia il fattore limitante nell'accuratezza dei calcoli spaziali.

— Tom Stambaugh,

Andare oltre le 6 cifre decimali va oltre la precisione disponibile degli odierni satelliti GPS. La post-elaborazione non introdurrà una quantità significativa di errori. DECIMAL(18,15)richiede 9 byte.

— Rick James

11

La distanza tra ogni grado di latitudine varia a causa della forma della terra e la distanza tra ogni grado di longitudine si riduce man mano che ci si avvicina ai poli. Parliamo quindi dell'equatore, dove la distanza tra ogni grado è 110,574km per la latitudine e 111,320km per la longitudine.

50 piedi sono 0,01524 km, quindi:

0,01524 / 110,574 = 1/7255 di un grado di latitudine
0,01524 / 111,320 = 1/7304 di un grado di longitudine

Occorrono quattro cifre della scala, sufficienti per scendere a decimillesimi di grado, con un totale di sette cifre di precisione.

DECIMAL(7,4) dovrebbe essere sufficiente per le tue esigenze.

— Bill Karwin
fonte

5

Tenendo conto delle varie parti di una sfera e di una distanza diagonale, ecco una tabella delle precisioni disponibili:

   Datatype           Bytes       resolution
   ------------------ -----  --------------------------------
   Deg*100 (SMALLINT)     4  1570 m    1.0 mi  Cities
   DECIMAL(4,2)/(5,2)     5  1570 m    1.0 mi  Cities
   SMALLINT scaled        4   682 m    0.4 mi  Cities
   Deg*10000 (MEDIUMINT)  6    16 m     52 ft  Houses/Businesses
   DECIMAL(6,4)/(7,4)     7    16 m     52 ft  Houses/Businesses
   MEDIUMINT scaled       6   2.7 m    8.8 ft
   FLOAT                  8   1.7 m    5.6 ft
   DECIMAL(8,6)/(9,6)     9    16cm    1/2 ft  Friends in a mall
   Deg*10000000 (INT)     8    16mm    5/8 in  Marbles
   DOUBLE                16   3.5nm     ...    Fleas on a dog

- http://mysql.rjweb.org/doc.php/latlng#representation_choices

— Rick James
fonte

3

Non memorizzare valori in virgola mobile. Anche se potresti presumere che siano accurati, non lo sono. Sono un'approssimazione. E risulta che lingue diverse hanno metodi diversi per "analizzare" le informazioni in virgola mobile. E diversi database hanno metodi diversi per implementare le approssimazioni dei valori.

Usa invece un Geohash . Questo video introduce e spiega visivamente il Geohash in meno di 5 minuti. Il Geohash è di gran lunga il modo migliore per codificare / decodificare le informazioni di longitudine / latitudine in modo coerente. Non "serializzando" mai i valori in virgola mobile approssimati di una longitudine / latitudine nelle colonne del database e invece, utilizzando un Geohash, si otterranno le stesse desiderabili garanzie di consistenza di andata e ritorno che si ottengono con i valori String. Questo sito web è ottimo per aiutarti a giocare con un Geohash.

— caotico3equilibrio
fonte

FLOATe DOUBLE, in questo contesto , non soffre di alcuni dei problemi che descrivi.

— Rick James

@RickJames Non hai specificato sufficientemente "questo contesto". Se intendi rigorosamente nella memorizzazione di un valore in due colonne DB, allora forse. Tuttavia, i valori dati non si trovano solo nelle colonne del database inutilizzate, il presupposto implicito che ci saranno query (di prossimità) scritte su questi valori. E mantenere questo assunto abbastanza pragmatico significa che tutte le questioni relative al fatto che sia un'approssimazione inaffidabile continuano a valere.

— caotic3quilibrium

1

Se un FLOATvalore e il valore "successivo" sono così vicini tra loro da non poter distinguere una città (o un veicolo o una persona o una pulce) da un'altra, gli errori di arrotondamento e di rappresentazione non contano. Nel frattempo, è quasi sempre una follia confrontare due FLOATs( DOUBLEso approssimativi DECIMALs) con "=".

— Rick James

Sembra che ti manchi il punto. Qualsiasi tentativo di query utilizzerà implicitamente uguale, se non esplicitamente. E questo presume che tu non stia attraversando altri livelli e linguaggi con i valori, rimanendo rigorosamente all'interno di SQL Server. Ecco una risposta ufficiale di Microsoft a questo per SQL Server: blogs.msdn.microsoft.com/qingsongyao/2009/11/14/…

— caotic3quilibrium

Mi dispiace, pensavo che la domanda fosse taggata [mysql], non SQL Server.

— Rick James

2

Se fai clic su posizioni su Google Maps, ottieni latitudine e longitudine con 7 cifre decimali

— Selvaggio
fonte