Enlem ve boylamı ne kadar doğru saklamalıyım?

104

Bu soruyu burada okuyordum:

Enlem ve boylam verilerini SQL veritabanlarında depolarken hangi veri türü kullanılmalı?

Ve görünen o ki, genel fikir birliği, Decimal (9,6) kullanmanın yoludur. Benim için soru şu, buna gerçekten ne kadar ihtiyacım var?

Örneğin, Google'ın API'si aşağıdaki gibi bir sonuç döndürür:

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

-122.0841430 üzerinden kaç basamağa ihtiyacım var? Birkaç rehber okudum ama bunu anlamak için onlardan yeterince mantıklı gelemiyorum.

Sorumda daha kesin olmak gerekirse: Tam konumun 50 fit yakınında doğru olmak istiyorsam, kaç ondalık nokta saklamam gerekir?

Belki daha iyi bir soru aslında programlama olmayan bir soru olabilirdi, ama şu olurdu: Her ondalık nokta size ne kadar daha doğru verir?

Bu kadar basit mi

  1. Liste öğesi
  2. x00 = 6000 mil
  3. xx0 = 600 mil
  4. xxx = 60 mil
  5. xxx.x = 6 mil
  6. xxx.xx = 0,6 mil
  7. vb?
mysql  geolocation 
— Vatandaş
kaynak
7
Koordinatların doğruluğu, bu koordinatların NEREDE olduğuna bağlıdır, çünkü gezegenin yüzeyi mükemmel bir küre değildir ve kutuplardan uzaklık da BÜYÜK BÜYÜK faktördür. Ortalama 3 ondalık basamak yaklaşık 120 metre / 400 fittir. 4 ondalık, 12 metre / 40 fit, vb. Olacaktır ...
— Marc B
1
— Flimm
1
— Gajus

Yanıtlar:

193

Ekvatordaki ondalık hanelere karşı doğruluk

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
kaynak
4
Bunlar ekvatordaysa, bu, bunların en kötü durum hataları olduğu anlamına mı gelir?
— Liath
6
Aslında ekvator en iyi durumdur. Bir enlem ve bir boylam derecesi ekvatorda aynı boyuttadır (69 mil), ancak bir boylam derecesi, kutuplardan birine yaklaştıkça sıfıra düşer. İşte çok güzel bir açıklama: nationalatlas.gov/articles/mapping/a_latlong.html#four
— codingoutloud
11
@codingoutloud Hangisi bu en kötü durum hatalarını yapar. Ya da bilgiçlik taslamak gerekirse, bunlar deniz seviyesinde enlem / boylam kullanımı için en kötü durum hatalarıdır. 6,378 m yükseklikte hata% 0,1 artmaktadır.
— Scott B
@codingoutload: Görünüşe göre bu bağlantı artık mevcut değil :(
— Tom Stambaugh
1
@Tom Stambaugh: Bunun için web.archive.org var: web.archive.org/web/20070810120810/http://nationalatlas.gov/…
— Stefan Steiger
19 
+----------------+-------------+
|    Decimals    |  Precision  |
+----------------+-------------+
|    5           |  1m         |
|    4           |  11m        |
|    3           |  111m       |
+----------------+-------------+

50ft (15m) hassasiyet istiyorsanız 4 basamaklı gidin. Yanidecimal(9,6)

— Gustav
kaynak
9
SQL Server kullanıyorsanız ... 1-9 hassasiyetinde 5 bayt kullanıldığını belirtmek gerekir. Dolayısıyla, ondalık (7,4) yerine ondalık (9,6) kullanmış olabilirsiniz ve her ikisi de aynı miktarda yer kapladığı için daha yüksek doğruluktan yararlanabilirsiniz.
— Theo
Enlem için, kullanın (8,6)(veya (6,4)bir bayt kaydetmek için (MySQL'de) kaydedin.
— Rick James
15

Veritabanları tasarlıyorum ve bir süredir bu soru üzerinde çalışıyorum. Veri alanlarının 17 ondalık basamağa izin verecek şekilde tanımlandığı Oracle arka uçlu kullanıma hazır bir uygulama kullanıyoruz. Saçma! Bu, bir inçin binde biridir. Dünyadaki hiçbir GPS cihazı bu kadar doğru değildir. Öyleyse 17 ondalık basamağı bir kenara bırakalım ve pratik ile ilgilenelim. Hükümet, sistemlerinin "% 95 güven seviyesinde 7,8 metrelik" en kötü durum "sözde turuncu doğrulukta" iyi olduğunu garanti ediyor, ancak daha sonra gerçek FAA'nın (yüksek kaliteli cihazlarını kullanarak) GPS okumalarının genellikle iyi olduğunu gösterdiğini söylüyor. bir metre içinde.

Öyleyse kendinize iki soru sormalısınız: 1) Değerlerinizin kaynağı nedir? 2) Veriler ne için kullanılacak?

Cep telefonları özellikle doğru değildir ve Google / MapQuest okumaları muhtemelen sadece 4 veya 5 ondalık basamağa kadar iyidir. Yüksek kaliteli bir GPS cihazı size 6 (Birleşik Devletler içinde) ulaşabilir. Ancak bundan daha fazlasını yakalamak, yazma ve saklama alanı israfıdır. Ayrıca, değerler üzerinde herhangi bir arama yapılırsa, bir kullanıcının araması gereken en fazla 6 değerinin 6 olduğunu bilmesi güzeldir (açıkça girilen herhangi bir arama değeri, önce aranan veri değeriyle aynı doğruluğa yuvarlanmalıdır. ).

Ayrıca, yapacağınız tek şey Google Haritalar'da bir konumu görüntülemek veya oraya ulaşmak için bir GPS'e koymaksa, dört veya beş kişi yeterlidir.

Buradaki insanlara tüm bu rakamları girerek gülmem gerekiyor. Ve bu ölçümü tam olarak nerede alıyorlar? Ön kapı kolu? Posta kutusu önde mi? Binanın merkezi? Baz istasyonunun tepesi? VE ... herkes sürekli aynı yerde mi alıyor?

İyi bir veritabanı tasarımı olarak, bir kullanıcıdan beş ondalık basamağın bir kaçını kabul eder, sonra tutarlılık için yalnızca beşini yuvarlar ve yakalarım [enstrümanlarınız iyiyse ve son kullanımınız bunu garanti ediyorsa belki altı tane].

— Greg
kaynak
4
17 hanenin çok fazla olduğu konusunda hemfikir olsam da, veriler sonradan işlenecekse 6'nın çok az olduğunu öneririm. Bir yarıçap sorgusu gibi şeyler yaparken ("Bu noktanın 0,5 mil yarıçapındaki yanıt özellikleri"), hatalar - kesme dahil - büyütülür. Böyle bir sorgunun çıktısında 6 ondalık basamağa ihtiyacınız varsa, giriş önemli ölçüde daha fazla başlamalıdır. Mağazamız DECIMAL (18,15) kullanma eğilimindedir. Amacımız, mekansal hesaplamaların doğruluğunda db'nin sınırlayıcı faktör olmamasını sağlamaktır.
— Tom Stambaugh
6 ondalık basamağın ötesine geçmek, bugünün GPS uydularının mevcut hassasiyetinin ötesine geçiyor. Sonradan işleme önemli miktarda hata oluşturmayacaktır. DECIMAL(18,15)9 bayt alır.
— Rick James
11

Her enlem derecesi arasındaki mesafe dünyanın şekli nedeniyle değişir ve her bir boylam derecesi arasındaki mesafe, kutuplara yaklaştıkça küçülür. Öyleyse, her derece arasındaki mesafenin enlem için 110.574km ve boylam için 111.320km olduğu ekvatordan bahsedelim .

50ft 0.01524km'dir, bu nedenle:

  • 0.01524 / 110.574 = 1/7255 enlem derecesi
  • 0.01524 / 111.320 = 1/7304 boylam derecesi

Toplam yedi basamaklı bir hassasiyetle bir derecenin on binde birine inmeye yetecek dört basamaklı ölçeğe ihtiyacınız var.

DECIMAL(7,4) ihtiyaçlarınız için bol miktarda olmalıdır.

— Bill Karwin
kaynak
5

Bir kürenin çeşitli kısımlarını ve çapraz bir mesafeyi hesaba katarak, işte mevcut kesinliklerin bir tablosu:

   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
kaynak
3

Kayan nokta değerlerini saklamayın. Doğru olduklarını varsaysanız da, değillerdir. Bunlar yaklaşık değerlerdir. Ve farklı dillerin kayan nokta bilgilerini "ayrıştırmak" için farklı yöntemleri olduğu ortaya çıktı. Ve farklı veritabanları, değer tahminlerini uygulamak için farklı yöntemlere sahiptir.

Bunun yerine bir Geohash kullanın . Bu video Geohash'ı 5 dakikadan kısa bir sürede tanıtıyor ve görsel olarak açıklıyor. Geohash, FAR TARAFINDAN boylam / enlem bilgilerini tutarlı bir şekilde kodlamanın / çözümlemenin en iyi yoludur. Bir boylam / enlemin yaklaşık kayan nokta değerlerini asla veritabanı sütunlarına "serileştirmeden" ve bunun yerine bir Geohash kullanarak, String değerleri ile elde ettiğiniz aynı istenen gidiş-dönüş tutarlılığını elde edersiniz. Bu web sitesi bir Geohash ile oynamanıza yardımcı olmak için harika.

— Kaotik denge
kaynak
FLOATve DOUBLE, bu bağlamda , açıkladığınız sorunlardan bazıları muzdarip değildir.
— Rick James
@RickJames "Bu bağlamı" yeterince belirtmediniz. Bir değerin kesinlikle iki DB sütununda depolanmasını kastediyorsanız, o zaman belki. Bununla birlikte, verilen değerler yalnızca kullanılmayan DB sütunlarında yer almaz, bu değerlere karşı yazılan (yakınlık) sorguların olacağına dair örtük varsayım. Ve bu oldukça pragmatik varsayımı sürdürmek, güvenilmez bir yaklaşım olan tüm konuların geçerli olmaya devam ettiği anlamına gelir.
— chaotic3quilibrium
1
Bir FLOATdeğer ve 'sonraki' değer, bir şehri (veya aracı veya kişiyi veya pire) diğerinden ayıramayacak kadar değer olarak birbirine çok yakınsa, yuvarlama ve temsil hataları önemli değildir. Bu arada, ikisini FLOATs( DOUBLEsveya yaklaşık olarak DECIMALs) '=' ile karşılaştırmak neredeyse her zaman aptallıktır .
— Rick James
Görünüşe göre asıl noktayı kaçırıyorsun. Açıkça değilse, denenen herhangi bir sorgu örtük olarak eşittir kullanacaktır. Ve bu, değerlerle başka katmanlardan ve dillerden geçmediğinizi, kesinlikle SQL Server'ın içinde kaldığınızı varsayar. İşte SQL Server için buna resmi bir Microsoft yanıtı: blogs.msdn.microsoft.com/qingsongyao/2009/11/14/…
— chaotic3quilibrium
Üzgünüm, sorunun [mysql]SQL Server değil etiketlendiğini sanıyordum .
— Rick James
2

Google Haritalar'da konumları tıklarsanız, 7 ondalık basamakla enlem ve boylam elde edersiniz

— Savage
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.