Seberapa akurat saya harus menyimpan lintang dan bujur?

103

Saya membaca pertanyaan ini di sini:

Jenis data apa yang digunakan saat menyimpan data lintang dan bujur dalam database SQL?

Dan tampaknya konsensus umum adalah bahwa menggunakan Desimal (9,6) adalah cara yang tepat. Pertanyaan bagi saya adalah, seberapa akurat saya membutuhkan ini?

Misalnya, API Google mengembalikan hasil seperti:

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

Dari -122.0841430, berapa digit yang saya butuhkan? Saya telah membaca beberapa panduan tetapi saya tidak cukup memahami mereka untuk mencari tahu.

Lebih tepatnya dalam pertanyaan saya: Jika saya ingin akurat dalam jarak 50 kaki dari lokasi yang tepat, berapa banyak titik desimal yang perlu saya simpan?

Mungkin pertanyaan yang lebih baik sebenarnya adalah pertanyaan non-pemrograman, tetapi itu adalah: seberapa akurat setiap titik desimal yang diberikan?

Apakah sesederhana ini?

Daftar barang
x00 = 6000 mil
xx0 = 600 mil
xxx = 60 mil
xxx.x = 6 mil
xxx.xx = 0,6 mil
dll?

mysql geolocation

— Warganegara
sumber

7

Keakuratan koordinat bergantung pada DI MANA koordinat tersebut berada, karena permukaan planet bukanlah bola yang sempurna dan jarak dari kutub juga merupakan faktor UTAMA UTAMA. Rata-rata 3 tempat desimal berukuran sekitar 120 meter / 400 kaki. 4 desimal akan menjadi 12 meter / 40 kaki, dll ...

— Marc B

1

Lihat pertanyaan ini di GIS stackexchange

— Flimm

1

kemungkinan duplikat dari Apa tipe data yang ideal untuk digunakan saat menyimpan lintang / bujur dalam database MySQL?

— Gajus

191

Akurasi versus tempat desimal di ekuator

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

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

— Noushad
sumber

4

Jika ini berada di ekuator, apakah itu berarti ini adalah kesalahan kasus terburuk?

— Liath

6

Sebenarnya, ekuator adalah kasus terbaik. Satu derajat lintang dan satu derajat bujur memiliki ukuran yang sama di khatulistiwa (69 mil), tetapi satu derajat bujur menyusut menjadi nol saat mendekati salah satu kutub. Berikut penjelasan yang sangat bagus: nationalatlas.gov/articles/mapping/a_latlong.html#four

— codingoutloud

11

@codingoutloud Yang akan membuat kesalahan kasus terburuk ini. Atau lebih tepatnya, ini adalah kasus kesalahan terburuk untuk menggunakan lintang / bujur di permukaan laut. Pada ketinggian 6.378 m, kesalahan meningkat 0,1%.

— Scott B

@codingoutload: Tautan itu tampaknya sudah tidak ada lagi :(

— Tom Stambaugh

1

@Tom Stambaugh: Ada web.archive.org untuk itu: web.archive.org/web/20070810120810/http://nationalatlas.gov/…

— Stefan Steiger

19

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

Jika Anda ingin presisi 50 kaki (15 m), gunakan 4 digit. Begitudecimal(9,6)

— Gustav
sumber

9

Jika Anda menggunakan SQL Server ... Perlu dicatat bahwa presisi 1-9 menggunakan 5 byte. Jadi Anda mungkin sebaiknya menggunakan desimal (9,6) daripada desimal (7,4) dan memanfaatkan akurasi yang lebih tinggi karena keduanya menempati jumlah ruang yang sama.

— Theo

Untuk lintang, gunakan (8,6)(atau (6,4)untuk menyimpan satu byte (di MySQL).

— Rick James

15

Saya merancang database dan telah mempelajari pertanyaan ini selama beberapa waktu. Kami menggunakan aplikasi di luar rak dengan backend Oracle di mana bidang data ditentukan untuk memungkinkan 17 tempat desimal. Konyol! Itu dalam seperseribu inci. Tidak ada instrumen GPS di dunia yang seakurat itu. Jadi mari kita sisihkan 17 tempat desimal dan berurusan dengan praktik. Pemerintah menjamin sistem mereka baik untuk akurasi "kasus terburuk" pseudorange 7,8 meter pada tingkat kepercayaan 95% "tetapi kemudian melanjutkan dengan mengatakan FAA aktual (menggunakan instrumen berkualitas tinggi) telah menunjukkan pembacaan GPS biasanya baik untuk dalam satu meter.

Jadi, Anda harus bertanya pada diri sendiri dua pertanyaan: 1) Apa sumber dari nilai-nilai Anda? 2) Untuk apa data tersebut akan digunakan?

Ponsel tidak terlalu akurat, dan pembacaan Google / MapQuest mungkin hanya cocok untuk 4 atau 5 desimal. Instrumen GPS berkualitas tinggi mungkin memberi Anda 6 (di Amerika Serikat). Tapi menangkap lebih dari itu hanya membuang-buang ruang pengetikan dan penyimpanan. Selain itu, jika ada pencarian yang dilakukan pada nilai-nilai tersebut, akan menyenangkan bagi pengguna untuk mengetahui bahwa 6 adalah yang paling harus dia cari (jelas semua nilai pencarian yang dimasukkan pertama-tama harus dibulatkan ke akurasi yang sama dengan nilai data yang dicari ).

Selain itu, jika Anda hanya ingin melihat lokasi di Google Maps atau memasukkannya ke GPS untuk sampai ke sana, empat atau lima sudah cukup.

Saya harus menertawakan orang-orang di sekitar sini yang memasukkan semua angka itu. Dan di mana tepatnya mereka melakukan pengukuran itu? Kenop pintu depan? Kotak surat di depan? Pusat bangunan? Puncak menara seluler? DAN ... apakah setiap orang secara konsisten mengambilnya di tempat yang sama?

Sebagai desain database yang baik, saya akan menerima nilai dari pengguna mungkin beberapa lebih dari lima digit desimal, kemudian membulatkan dan menangkap hanya lima untuk konsistensi [mungkin enam jika instrumen Anda bagus dan penggunaan akhir Anda menjaminnya].

— Greg
sumber

4

Meskipun saya setuju bahwa 17 digit terlalu banyak, saya menyarankan 6 terlalu sedikit jika data akan diproses pasca. Saat melakukan hal-hal seperti kueri radius ("Fitur jawaban dalam radius 0,5 mil dari titik ini"), kesalahan - termasuk pemotongan - diperbesar. Jika Anda memerlukan 6 digit desimal pada keluaran kueri semacam itu, masukan harus dimulai dengan lebih banyak. Toko kami cenderung menggunakan DECIMAL (18,15). Tujuan kami adalah memastikan bahwa db bukanlah faktor pembatas dalam keakuratan penghitungan spasial.

— Tom Stambaugh

Melampaui 6 tempat desimal berarti melampaui ketepatan yang tersedia dari satelit GPS saat ini. Pemrosesan pasca tidak akan menyebabkan sejumlah besar kesalahan. DECIMAL(18,15)membutuhkan 9 byte.

— Rick James

11

Jarak antara setiap derajat garis lintang bervariasi karena bentuk bumi dan jarak antara setiap derajat garis bujur semakin kecil jika semakin dekat dengan kutub. Jadi mari kita bicara tentang ekuator, di mana jarak antara setiap derajat adalah 110.574 km untuk lintang dan 111.320 km untuk bujur.

50ft adalah 0,01524km, jadi:

0,01524 / 110,574 = 1/7255 derajat garis lintang
0,01524 / 111,320 = 1/7304 dari derajat bujur

Anda memerlukan empat digit skala, cukup untuk turun ke sepuluh per seribu derajat, dengan total ketepatan tujuh digit.

DECIMAL(7,4) harus cukup untuk kebutuhan Anda.

— Bill Karwin
sumber

5

Dengan mempertimbangkan berbagai bagian bola dan jarak diagonal, berikut adalah tabel presisi yang tersedia:

   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
sumber

3

Jangan simpan nilai floating point. Meskipun Anda mungkin menganggapnya akurat, sebenarnya tidak. Mereka adalah perkiraan. Dan ternyata bahasa yang berbeda memiliki metode yang berbeda untuk "mengurai" informasi floating point. Dan database yang berbeda memiliki metode yang berbeda untuk menerapkan perkiraan nilai.

Sebagai gantinya, gunakan Geohash . Video ini memperkenalkan dan menjelaskan Geohash secara visual dalam waktu kurang dari 5 menit. Geohash JAUH merupakan cara terbaik untuk menyandikan / mendekode informasi bujur / lintang dengan cara yang konsisten. Dengan tidak pernah "membuat serial" perkiraan nilai floating point dari bujur / lintang ke dalam kolom database dan sebaliknya, menggunakan Geohash, Anda akan mendapatkan jaminan konsistensi perjalanan pulang pergi yang sama seperti yang Anda dapatkan dengan nilai String. Situs web ini bagus untuk membantu Anda bermain dengan Geohash.

— chaotic3quilibrium
sumber

FLOATdan DOUBLE, dalam konteks ini , tidak mengalami beberapa masalah yang Anda gambarkan.

— Rick James

@RickJames Anda tidak cukup menentukan "konteks ini". Jika maksud Anda, secara ketat dalam penyimpanan nilai dalam dua kolom DB, maka mungkin. Namun, nilai yang diberikan tidak hanya duduk di kolom DB yang tidak digunakan, asumsi implisit bahwa akan ada kueri (kedekatan) yang ditulis terhadap nilai ini. Dan memegang asumsi yang cukup pragmatis ini berarti semua masalah tentang perkiraan yang tidak dapat diandalkan terus berlanjut.

— chaotic3quilibrium

1

Jika satu FLOATnilai dan nilai 'berikutnya' sangat dekat satu sama lain sehingga Anda tidak dapat membedakan satu kota (atau kendaraan atau orang atau loak) dari yang lain, kesalahan pembulatan dan representasi tidak menjadi masalah. Sementara itu, membandingkan dua FLOATs(atau DOUBLEsatau perkiraan DECIMALs) dengan '=' hampir selalu merupakan hal yang bodoh .

— Rick James

Anda tampaknya kehilangan intinya. Setiap percobaan kueri akan secara implisit menggunakan sama dengan, jika tidak secara eksplisit. Dan ini mengasumsikan Anda tidak melalui lapisan dan bahasa lain dengan nilai, tetap berada di dalam SQL Server. Berikut ini adalah respon Microsoft resmi ini untuk SQL Server: blogs.msdn.microsoft.com/qingsongyao/2009/11/14/...

— chaotic3quilibrium

Maaf, saya pikir pertanyaan itu diberi tag [mysql], bukan SQL Server.

— Rick James

2

Jika Anda mengklik lokasi di Google Maps, Anda mendapatkan lintang dan bujur dengan 7 tempat desimal

— Kejam
sumber