Lompat ke konten
belajarmenolak ngantorSystem Design
18 menit bacamateri 79 dari 96

Representasikan lokasi

Koordinat itu cuma dua angka. Yang bikin pencarian lokasi benar adalah model jarak, jumlah digit yang jujur, dan pengakuan bahwa posisi GPS selalu punya ketidakpastian.

Ditinjau 26 Oktober 2026

Pertanyaan

Bagaimana menyimpan dan membandingkan lokasi supaya jarak yang kamu hitung masuk akal, dan seberapa yakin kamu pada angka koordinat itu?

Setelah baca ini, kamu bisa memilih model jarak (haversine atau pendekatan datar), menentukan jumlah digit koordinat yang layak disimpan, dan menyebut ketidakpastian posisi sebagai bagian dari data, bukan catatan kaki.

Prasyarat dan contoh

Kamu sudah paham indeks basis data (M04) dan tahu kenapa satu kolom saja gampang diindeks tapi dua kolom yang saling terkait nggak. Nggak perlu pernah pakai peta atau PostGIS.

Aplikasi pesan antar punya tabel drivers(id, lat, lon). Pelanggan di Bundaran HI (-6,1951; 106,8231) dan Monas ada di (-6,1754; 106,8272). Berapa jauh jaraknya? Kalau kamu hitung sqrt(Δlat² + Δlon²) dalam derajat, dapat 0,0201. Angka itu bukan kilometer, bukan meter, dan nilainya nggak punya satuan fisik yang tetap. Jarak sebenarnya sekitar 2,24 km.

Lokasi yang kelihatan sepele ini sudah punya tiga keputusan tersembunyi: satuan, model bumi, dan seberapa percaya pada angkanya.

Mekanisme

1. Koordinat adalah sudut, bukan jarak. Lintang (latitude) dan bujur (longitude) mengukur sudut terhadap pusat bumi. Satu derajat lintang selalu sekitar 111,3 km. Satu derajat bujur menyusut mengikuti cos(lintang):

km per derajat bujur ≈ 111,32 × cos(lintang)
di Jakarta (-6,2°): 111,32 × 0,994 ≈ 110,7 km
di lintang 60°:     111,32 × 0,5   ≈ 55,7 km

Di dekat khatulistiwa selisih ini kecil, jadi bug-nya sering baru ketahuan setelah ekspansi ke lintang tinggi.

2. Pilih model jarak sesuai skala. Tiga pilihan umum:

  • Haversine: jarak lingkaran besar di bola berjari-jari 6.371 km. Akurat sampai kira-kira 0,3% dibanding model elipsoid, cukup untuk hampir semua pencarian terdekat.
  • Pendekatan datar (equirectangular): dx = Δlon × cos(lat) × 111,32, dy = Δlat × 111,32. Lebih murah dari haversine dan akurat untuk jarak di bawah puluhan kilometer. Cocok untuk memfilter ratusan ribu kandidat.
  • Elipsoid (Vincenty, Karney): untuk survei dan pemetaan. Jarang perlu untuk matching.

Semua jarak di atas adalah jarak garis lurus. Jarak tempuh lewat jalan adalah masalah lain, dan biasanya dikerjakan setelah kandidat dipersempit (lihat pelajaran tentang pencocokan).

3. Presisi koordinat. Jumlah digit desimal menentukan resolusi:

| Desimal | Resolusi sekitar | | ------- | ---------------- | | 3 | 111 m | | 4 | 11 m | | 5 | 1,1 m | | 6 | 0,11 m |

GPS ponsel biasanya meleset 5 sampai 20 m di ruang terbuka. Menyimpan 7 desimal (1 cm) memberi kesan presisi yang nggak ada. Kebalikannya juga salah: membulatkan ke 3 desimal membuat dua motor di ujung gang yang sama kadang dianggap satu titik.

4. Ketidakpastian itu data. Pembacaan GPS yang jujur membawa tiga hal: posisi, radius akurasi (misalnya 18 m), dan waktu pembacaan. Simpan ketiganya. Dengan itu kamu bisa menolak pembacaan dengan akurasi 800 m (sering terjadi di dalam gedung) dan tahu bahwa posisi berumur 40 detik nggak sama dengan posisi sekarang.

Saat rancangan ini gagal

  • Jarak Euclid dalam derajat. Di lintang tinggi, urutan "terdekat" bisa terbalik. Titik 0,01° ke timur (557 m di lintang 60°) dianggap lebih jauh dari titik 0,006° ke utara (668 m), padahal sebaliknya.
  • Tertukar urutan lat dan lon. GeoJSON memakai [lon, lat], sebagian besar API peta memakai lat, lon. Titik di Jakarta yang tertukar mendarat di Samudra Hindia dan nggak ada error apa pun. Beri nama kolom, jangan pakai array tanpa label.
  • Presisi palsu. Dua pembacaan driver yang sama-sama diam bisa beda 12 m. Kalau logikamu bilang "pindah jika koordinat berubah", kamu menulis ulang lokasi tiap detik tanpa ada gerakan nyata.
  • Mengabaikan akurasi. Pembacaan dengan radius 800 m lalu dipakai untuk memilih driver di radius 500 m menghasilkan kecocokan yang acak.

Contoh tandingan: untuk memfilter kandidat dalam radius 3 km, pendekatan datar sudah cukup dan beberapa kali lebih murah dari haversine. Memakai Vincenty di jalur panas cuma membuang CPU, karena selisihnya (puluhan meter pada jarak ribuan kilometer) jauh di bawah ketidakpastian GPS.

Latihan

Sebuah layanan di lintang 60° menerima dua kandidat untuk satu pelanggan: kandidat A berada 0,010° di timur, kandidat B berada 0,006° di utara. Pembacaan masing-masing punya akurasi 15 m.

  1. Berapa jarak sebenarnya ke A dan B?
  2. Mana yang dipilih bila kamu memakai jarak Euclid dalam derajat?
  3. Apakah selisih jarak sebenarnya lebih besar dari ketidakpastian pembacaan?
Lihat pembahasan
A: 0,010 × 111,32 × cos(60°) = 0,010 × 55,66 ≈ 0,557 km = 557 m
B: 0,006 × 111,32            ≈ 0,668 km       = 668 m
  1. A berjarak sekitar 557 m, B sekitar 668 m. A lebih dekat.
  2. Jarak dalam derajat: A = 0,010, B = 0,006. B terlihat lebih dekat, jadi pilihan salah. Bug ini nggak muncul di data uji di Jakarta karena cos(6,2°) ≈ 0,994.
  3. Selisihnya 668 − 557 = 111 m. Dengan akurasi 15 m di tiap sisi, ketidakpastian gabungan paling buruk sekitar 30 m, jadi urutannya masih bisa dipercaya. Kalau selisihnya cuma 20 m, kamu nggak boleh berpura-pura tahu mana yang lebih dekat dan sebaiknya urutan diputuskan faktor lain, misalnya ETA jalan.

Terkait

  • M04 (pemodelan data dan indeks) menjelaskan kenapa indeks satu dimensi nggak otomatis membantu query dua dimensi.
  • Lanjut ke M14.02 Temukan kandidat terdekat.
  • Lab L14 dan rancangan D17 belum tersedia.

Catatan

  • Asumsi: bumi dianggap bola 6.371 km untuk haversine, dan jarak garis lurus (bukan jalan).
  • Yang nggak dibahas: datum dan proyeksi peta (WGS84 vs lokal), ketinggian, dan kebocoran presisi lewat metadata foto.
  • Resolusi per desimal adalah perhitungan standar: 1° ≈ 111,32 km dibagi 10 per digit.
  • Terakhir ditinjau: 26 Oktober 2026.

Isi · System Design