Petualangan dalam Pemrograman dan Pengembangan GPS: Tutorial Geospasial

Ini semua dimulai pada perjalanan hiking ke Zbevnica lebih dari 10 tahun yang lalu. Saya membawa GPS baru saya dan seorang teman saya memiliki GPS yang terhubung ke telepon Windows ME. Pendakiannya bagus, tetapi ketika kami kembali ke mobil kami, kami terkejut melihat bahwa satu GPS mengklaim kami telah berjalan 6,2 km, sementara yang lain melaporkan 6,7 km. Satu mengklaim kenaikan ketinggian kami (yaitu, jumlah semua bagian menanjak dari pendakian kami) adalah 300m, sementara yang lain melaporkannya sebagai 500m.

Menjadi seorang programmer (dan akhirnya seorang programmer GIS), saya langsung tertarik dengan masalah tersebut. Saya berkata pada diri sendiri, "ini seharusnya tidak terlalu sulit untuk diperbaiki dengan skrip sederhana." Lagi pula, trek GPS hanyalah daftar tupel dalam bentuk (lintang, bujur, ketinggian) , bukan?

Yah, tidak juga.

Dan dengan demikian memulai perjalanan saya ke dunia trek GPS yang menarik, kesalahan pelacakan, dan, lebih umum, pemrograman GIS.

Sistem Informasi Geospasial (GIS) adalah domain yang sangat besar dan kompleks, mencakup proyeksi peta dan datum geodetik), pemrosesan data raste dan vecto, dan penginderaan jauh. Pengantar komprehensif untuk domain ini akan berada di luar cakupan artikel ini. Dan karena berfokus pada masalah tertentu seringkali dapat menjadi cara yang berguna untuk memperkenalkan diri ke domain baru, saya akan menyajikan beberapa tantangan GIS spesifik yang saya temui dan beberapa solusi yang mungkin; yaitu:

• Cara mengenali, memahami, dan mengoreksi kesalahan pelacakan GPS secara terprogram
• Cara menghitung dan mendapatkan informasi tambahan yang berguna dari trek GPS

Sebagai permulaan, trek GPS bukan hanya serangkaian tupel (lintang, bujur, ketinggian) . Banyak perangkat berkemampuan GPS juga akan menyediakan metadata seperti waktu, detak jantung, dan sebagainya. Beberapa perangkat GPS bahkan akan memberikan informasi seberapa akurat data tersebut; alias, "pengenceran presisi". Namun, sayangnya, sebagian besar perangkat GPS – terutama yang kelas bawah yang mendominasi pasar – tidak akan memberikan informasi ini dan kami dihadapkan pada tantangan untuk menyimpulkan sendiri keakuratan perangkat (dan idealnya mengoreksi dengan tepat, jika memungkinkan ).

Mari kita mulai dengan satu algoritme yang memungkinkan untuk mendeteksi perangkat GPS kelas bawah (seperti kebanyakan ponsel cerdas) yang biasanya memiliki data GPS berkualitas rendah.

Kesalahan ketinggian dan keanehan

Jika Anda tinggal di bagian dunia tertentu, Anda mungkin telah memperhatikan sesuatu yang aneh tentang akurasi ketinggian GPS saat Anda merekam trek dengan ponsel cerdas Anda. Ketika Anda memeriksa elevasi mereka secara konsisten dicatat sebagai lebih tinggi atau lebih rendah (dengan nilai konstan) daripada elevasi yang tepat. Misalnya, saya tinggal di Višnjan (Kroasia) dan Android saya terus memberi tahu saya bahwa saya kira-kira 35-40 meter di atas ketinggian sebenarnya.

Sebagai contoh, berikut adalah grafik ketinggian GPS dari pendakian singkat yang saya ambil beberapa bulan yang lalu:

Dua hal yang perlu diperhatikan di sini.

Pertama, "bukit" di bagian pertama dari data GPS yang direkam sepenuhnya dibuat oleh perangkat . Padahal grafiknya sepertinya menunjukkan bahwa titik tertinggi dalam pendakian kami hanya beberapa ratus meter dari awal, pada kenyataannya itu sekitar 4 km kemudian.

Kedua, apa yang mungkin lebih penting (dan tidak terlihat pada grafik) adalah bahwa seluruh grafik tidak akurat . Nilai ketinggian secara konsisten dilaporkan sekitar 30-40 meter lebih tinggi daripada yang sebenarnya, seperti yang akan kita bahas lebih detail di artikel ini.

Ini adalah hal-hal yang dapat terjadi dengan perangkat GPS murah. Dan ketika kami dapat mendeteksi bahwa trek memiliki kesalahan ini, kami dapat menyimpulkan bahwa perangkat tersebut mungkin adalah GPS berkualitas rendah yang oleh karena itu dapat diperkirakan memiliki kesalahan lain juga – bukan hanya kesalahan ketinggian – yang umum terjadi pada perangkat tersebut.

Kesalahan ketinggian startup

Pada dasarnya ada dua teknik yang digunakan perangkat GPS untuk menentukan ketinggian: "Ketinggian GPS" (seperti yang dilaporkan ke perangkat oleh sistem satelit GPS) dan "ketinggian barometrik" (dihitung oleh perangkat berdasarkan pembacaan tekanan udara). Tidak ada yang sempurna.

Nilai ketinggian GPS dapat memiliki banyak kesalahan kecil (biasanya dalam kisaran +/- 10m), yang dapat menjadi masalah jika nanti kita memutuskan untuk menghitung perolehan elevasi kumulatif. Ketinggian barometrik, di sisi lain, sensitif tidak hanya terhadap ketinggian tetapi juga terhadap kondisi cuaca, yang dapat menimbulkan ketidakakuratan tersendiri.

Oleh karena itu, beberapa perangkat menggunakan pendekatan hibrida, menggunakan pembacaan barometrik untuk merekam ketinggian tetapi menggunakan pembacaan GPS untuk membantu (mengkalibrasi ulang) nilai-nilai tersebut, untuk membantu memperhitungkan perubahan cuaca (tekanan) dan seterusnya. Dengan perangkat seperti itu, saat memulai trek, ketinggian barometrik bisa sepenuhnya salah, tetapi kemudian dengan mengkalibrasi ulang dengan lebih banyak data satelit GPS, data ketinggian menjadi lebih andal. Oleh karena itu, tidak jarang perangkat tersebut menemukan jenis kesalahan startup "bukit palsu" yang kami amati sebelumnya pada grafik elevasi kami.

Ketidakakuratan ketinggian GPS yang sedang berlangsung

Untuk menjelaskan kesalahan yang konsisten dalam pelaporan ketinggian, kita perlu kembali ke geografi sekolah dasar kita. Guru geografi biasanya menjelaskan bahwa Bumi bukanlah bola melainkan ellipsoid. Jika ini benar-benar benar, ketinggian akan mudah dihitung secara matematis. Tapi tidak. Bumi tidak teratur; pada kenyataannya, ini lebih mirip kentang yang menyerupai ellipsoid daripada ellipsoid yang sempurna, yang berarti untuk pengembangan GIS Anda memerlukan dataset ketinggian yang mendetail untuk hampir setiap titik di bumi. Dalam geodesi, ellipsoid referensi ini (alias datum) adalah permukaan yang ditentukan secara matematis yang mendekati geoid, sosok Bumi yang "lebih benar".

Selain itu, penting untuk diketahui bahwa bahkan datum-datum ini hanyalah perkiraan dari bentuk permukaan bumi yang sebenarnya. Beberapa bekerja lebih baik di bagian dunia tertentu, dan yang lain bekerja lebih baik di bagian lain. Sebagai contoh, gambar di bawah ini (dihasilkan menggunakan perpustakaan Ruby saya) menunjukkan bagaimana Earth berbeda dari salah satu model ellipsoid yang paling umum digunakan (datum WGS84). Bagian hitam mewakili bagian Bumi di atas, dan putih mewakili bagian Bumi di bawah, ellipsoid ideal (kontur benua dan pulau ditunjukkan dengan warna merah).

Anda dapat melihat bahwa India berada di bawah ellipsoid WGS84 dengan bagian selatan menjadi minimum absolut (hampir -100 meter!) dan Eropa berada di atasnya.

Karena perangkat GPS berkualitas rendah tidak menggunakan datum seperti itu, mereka benar-benar hanya menghitung ketinggian dengan asumsi ellipsoid yang sempurna. Oleh karena itu, ketidakakuratan mereka yang konsisten.

Mendeteksi dan mengoreksi kesalahan ketinggian GPS

Dalam pengembangan aplikasi GPS, mendeteksi bahwa perangkat yang merekam lintasan kami memiliki jenis kesalahan ini dapat dilakukan dengan menggunakan kumpulan data Model Gravitasi Bumi EGM2008, yang terkadang juga disebut sebagai kumpulan data "geoid undulasi". Dengan EGM2008, kita dapat memperkirakan perbedaan antara permukaan bumi yang sebenarnya dan ellipsoid yang ideal.

Tetapi untuk mengetahui apakah trek GPS kami memiliki kesalahan ini, kami memerlukan satu hal lagi – ketinggian sebenarnya . Database publik yang dapat membantu untuk tujuan ini adalah Shuttle Radar Topography Mission (SRTM). SRTM adalah database berbasis raster yang menyediakan nilai ketinggian pada resolusi kira-kira setiap 30m (di khatulistiwa) untuk AS dan setiap 90m untuk seluruh dunia. Misalnya, saat menghitung nilai SRTM untuk titik di trek di atas, grafik yang berbeda (garis biru) muncul:

Gangguan kecil di sini adalah tepi kasar grafik, tetapi ini mudah dihaluskan. Perhatikan bahwa dengan menghaluskan kita kehilangan sedikit (jika ada) presisi, karena SRTM sendiri hanya menyediakan titik-titik diskrit pada posisi yang berjarak sama, di antaranya kita perlu melakukan interpolasi dalam hal apa pun. Berikut adalah versi grafik sebelumnya dengan hamparan garis merah yang mewakili data SRTM yang dihaluskan:

Semua ini dapat dilakukan dengan mudah, kebetulan, menggunakan perpustakaan Python GPS saya:

• srtm.py: pengurai python untuk data elevasi Misi Topografi Shuttle Radar (SRTM)
• gpxpy: pustaka python sederhana untuk menguraikan dan memanipulasi file GPX (GPX, GPS Exchange Format, adalah format data XML ringan untuk data GPS)

Untuk pengguna Ruby, ada juga perpustakaan parser Geoelevations.rb saya untuk undulasi SRTM dan EGM2008.

Setelah mendeteksi anomali ini, tergantung pada jenis perangkat lunak yang kami gunakan, kami dapat (a) mengoreksi sendiri kesalahan tersebut secara otomatis atau (b) memberi tahu pengguna bahwa ketidakakuratan telah terdeteksi dalam data elevasi mereka.

Selain itu, karena ada algoritme berbeda yang dapat digunakan untuk mengoreksi kesalahan elevasi GPS ini secara terprogram, kami mungkin ingin memberi pengguna opsi untuk memilih algoritme mana yang akan digunakan (misalnya, apakah pengguna ingin kami menggunakan data SRTM yang dihaluskan saja "sebagaimana adanya" atau apakah pengguna ingin kami menggunakan data SRTM untuk membantu memperbaiki ketinggian yang dilaporkan oleh perangkat).

Menghaluskan trek dan menghilangkan outlier

Jika seorang pemain sepak bola memakai perangkat GPS dan merekam permainan, trek yang dihasilkan akan berantakan. Lapangan permainan akan dipenuhi dengan trek yang terdiri dari banyak tikungan tajam, akselerasi, dan deselerasi.

Untungnya, sebagian besar kasus di mana orang menggunakan GPS tidak akan memiliki pola yang sama – garis lintasan GPS (dan akselerasi) akan relatif mulus. Dalam kasus seperti itu, titik-titik yang tidak menentu di trek kami dapat dianggap disebabkan oleh kesalahan dan oleh karena itu outlier semacam itu dapat dihilangkan secara wajar dengan fungsi pemulusan.

Sebagai pengembang GIS, pemulusan paling sering dicapai dengan iterasi melalui titik-titik dan mengubah koordinat berdasarkan nilai koordinat tetangga. Misalnya, kita dapat mengubah setiap garis lintang dan garis bujur dengan algoritma seperti berikut:

 points[n].latitude = points[n-1].latitude * 0.3 + points[n].latitude * .4 + points[n+1].latitude * .3 points[n].longitude = points[n-1].longitude * 0.3 + points[n].longitude * .4 + points[n+1].longitude * .3

Semakin besar koefisien, semakin besar dampak dari titik tetangga yang sesuai o lokasi yang dimodifikasi dari titik saat ini. Koefisien yang saya gunakan dalam contoh ini (0,3, 0,4, 0,3) agak berubah-ubah, tetapi dalam banyak kasus Anda ingin jumlahnya sama dengan 1,0. (Pendekatan yang lebih canggih, misalnya, akan menggunakan jarak antara titik dan kemudian, semakin dekat titik, semakin besar koefisien yang sesuai.)

Berikut adalah contoh trek dengan banyak kesalahan acak:

Perhatikan bagaimana trek tidak mengikuti jalur dengan baik, memiliki banyak tikungan tajam dan bergerigi, dan terkadang membelok sepenuhnya dari jalur yang diharapkan.

Setelah beberapa iterasi "memperhalus", trek yang sama ini diubah menjadi:

Meskipun itu jauh lebih baik, itu masih diakui tidak sempurna. Perhatikan bahwa masih ada tempat (terutama di dekat tengah jalan) di mana trek masih membelok dari jalan.

Ada hal lain yang bisa Anda coba. Di wilayah tertentu, dan untuk aplikasi GPS tertentu, Anda juga dapat menggunakan data OpenStreetMap (OSM) untuk mencoba menebak jalur yang benar dan kemudian “menjepret” titik ke jalur baru ini. Meskipun hal ini sering dapat membantu, hal ini juga dapat menjadi tidak sempurna, seperti dalam kasus di mana data OSM berisi dua garis paralel (misalnya jalan raya dan jalan terdekat) atau banyak jalur yang berdekatan.

Dalam kasus seperti itu, solusi yang mungkin adalah mencoba mendeteksi jenis aktivitas, menggunakan beberapa teknik yang dibahas lebih lanjut dalam artikel ini. Jika kita dapat menyimpulkan, misalnya, bahwa trek tersebut adalah trek hiking dan memiliki opsi untuk berbelok ke jalan raya atau jalur terdekat, kita dapat dengan aman berasumsi bahwa kenaikan itu berada di sepanjang jalur dan bukan jalan raya.

Perhatikan juga bahwa, meskipun contoh ini menunjukkan pemulusan koordinat permukaan (yaitu, bujur/lintang), pemulusan dapat menjadi teknik yang sama validnya untuk menghilangkan penyimpangan dalam data elevasi atau temporal, atau bahkan dalam data detak jantung dan irama sepeda.

Contoh manfaat tambahan dan penggunaan smoothing dapat mencakup:

• Menghitung perolehan elevasi total. Untuk menghitung perolehan elevasi total dalam lintasan, tidak cukup hanya menjumlahkan semua “loncatan” kecil menanjak karena sering kali mengandung kesalahan kecil. Menghaluskan ketinggian sebelum melakukan penjumlahan seringkali dapat membantu meringankan masalah ini.
• Penghapusan outlier. Setelah “smoothing”, titik yang terlalu jauh dari lintasan bisa lebih mudah dideteksi. Ini sering kemudian dapat dianggap sebagai outlier dan pengguna dapat diminta untuk menanyakan apakah mereka harus dihapus.

Ada satu jenis masalah di mana algoritme ini gagal: dalam beberapa kasus GPS akan merekam jalur yang mulus, tetapi jalur akan "digeser" oleh perbedaan konstan di beberapa arah. Dalam kasus seperti itu, pemulusan lebih lanjut dapat menghaluskan garis tetapi tidak akan memperbaiki kesalahan pergeseran ini.

Masalah tambahan yang kurang jelas, namun signifikan, dengan teknik pemulusan sederhana yang telah kami jelaskan adalah bahwa transformasi memodifikasi semua (atau hampir semua) titik di jalur, bahkan titik yang mungkin tidak salah. Meskipun pendekatan yang lebih sederhana ini cenderung menjadi solusi yang masuk akal untuk rata-rata pengguna GPS, algoritma smoothing yang lebih canggih tentu dapat diterapkan dalam pemrograman GIS. Dalam beberapa kasus, bahkan mungkin lebih baik untuk menghapus outlier tanpa melakukan perataan apapun tergantung pada pengguna, perangkat, dan aplikasi.

Mendeteksi kecepatan maksimum

Mendeteksi kecepatan maksimum trek cukup sederhana jika kita memiliki koordinat dan stempel waktu semua titik pada rute. Hitung saja kecepatan antar titik dan temukan nilai tertinggi. Tampaknya langsung.

Tapi ingat, kita berurusan dengan perangkat GPS kelas bawah dan kita tidak sepenuhnya mempercayai data, yang dapat memiliki konsekuensi yang signifikan untuk perhitungan kita. Jika perangkat merekam lokasi setiap 5 meter dan pada satu titik membuat kesalahan dengan salah menempatkan titik sejauh 10 meter, maka bagian trek itu mungkin tampak 3x lebih cepat dari sebelumnya!

Salah satu pendekatan umum dalam dunia pengembangan GIS adalah mengekstrak semua kecepatan antar titik, dan kemudian menghapus 5% teratas (yaitu menggunakan persentil ke-95) dengan harapan 5% yang dihilangkan mewakili sebagian besar kesalahan. Tapi ini diakui tidak ilmiah dan tidak menjamin hasil yang benar. Dalam eksperimen saya dengan teknik ini, saya mencoba nilai yang berbeda untuk persentil dan menemukan bahwa beberapa bekerja dengan baik untuk satu perangkat GPS beberapa bekerja dengan baik untuk yang lain. Beberapa bekerja dengan baik untuk hiking dan lainnya untuk bersepeda. Tetapi dalam banyak kasus, hasilnya tidak terasa benar bagi saya.

Setelah mencoba banyak algoritme, yang berhasil bagi saya adalah sederhana: menambahkan filter lain untuk menghilangkan ekstrem, tidak hanya berdasarkan kecepatan, tetapi juga jarak, sebagai berikut:

1. Urutkan poin berdasarkan jarak antara tetangga dan hapus 5% teratas.
2. (Opsional:) Menghaluskan trek (secara horizontal dan/atau vertikal).
3. Urutkan poin berdasarkan kecepatan antara tetangga dan hapus 5% teratas.

Dari pengalaman saya, algoritma ini memberikan hasil yang cukup kredibel, bahkan untuk trek dari perangkat GPS murah dengan kesalahan acak.

Deduksi jenis aktivitas

Dalam banyak kasus, kecepatan rata-rata cukup untuk menentukan jenis aktivitas. Jika kecepatan rata-rata 5kmh, misalnya, itu mungkin trek berjalan / hiking, sedangkan jika kecepatan rata-rata 30kmh, itu mungkin trek bersepeda, dan seterusnya.

Namun jika kecepatan rata-rata 12kmh, Anda tidak dapat memastikan apakah pengguna tersebut bersepeda gunung atau berlari. Dalam kasus seperti itu, kecepatan maksimum terkadang dapat membantu membedakan kedua jenis aktivitas tersebut. Secara khusus, kita dapat menggunakan fakta bahwa pelari jarang mencapai kecepatan lebih dari dua kali rata-rata mereka, sementara pengendara sepeda melakukannya secara teratur (misalnya, saat menuruni bukit di jalur yang tidak terlalu menantang).

Dengan demikian, trek dengan kecepatan rata-rata 12kmh dan kecepatan maksimum 18kmh mungkin direkam saat berlari, sedangkan trek dengan kecepatan rata-rata 12kmh dan kecepatan maksimum 30kmh mungkin direkam saat bersepeda gunung. (Tentu saja, kita harus yakin bahwa kecepatan maksimum yang kita hitung sudah benar, agar ini bekerja dengan andal.)

Persentase langit yang terlihat: Proksi pintar untuk deteksi kesalahan GPS

Ketepatan setiap pengukuran GPS (yaitu lintang, bujur, dan ketinggian) sangat tergantung pada jumlah satelit yang terlihat pada saat perekaman. Jadi, jika kita entah bagaimana dapat menentukan berapa banyak satelit yang "terlihat" pada saat setiap perekaman, kita dapat menggunakannya sebagai cara untuk memperkirakan keakuratan perekaman itu. Jika kita entah bagaimana tahu, misalnya, bahwa semua satelit GPS yang diperlukan ada dalam pandangan, kita dapat mengasumsikan tingkat akurasi yang tinggi untuk data GPS yang sesuai. Sebaliknya, jika kita entah bagaimana mengetahui bahwa tidak ada satelit GPS yang terlihat, kita dapat menganggap data tersebut rawan kesalahan.

Tetapi sebelum Anda terlalu bersemangat, pertimbangkan kerumitan dalam mencoba memecahkan masalah GIS seperti itu. Pertama-tama, Anda perlu mengetahui sistem satelit GPS mana yang dapat digunakan perangkat Anda untuk berkomunikasi. Ada Sistem Pemosisian Global yang berbasis di AS, Gallileo Eropa, dan sistem GLONASS Rusia. Beberapa perangkat berfungsi dengan semua jenis satelit ini, tetapi banyak yang tidak. Dan banyak perangkat bahkan tidak melaporkan sistem mana yang mereka gunakan.

Namun ada cara cerdas untuk menghindari kerumitan ini dan mencapai perkiraan kasar jumlah satelit yang terlihat: gunakan persentase langit yang terlihat sebagai proksi untuk jumlah satelit yang terlihat . Langit yang kurang terlihat berarti GPS kita dapat “melihat” (atau dilihat) oleh lebih sedikit satelit. Tapi bagaimana kita bisa menghitung persentase langit yang terlihat di setiap titik di Bumi? Solusinya sebenarnya cukup sederhana: kita dapat menghitung garis horizon di sekitar kita menggunakan data SRTM yang telah dibahas sebelumnya.

Misalnya, ini adalah cakrawala jika Anda berada di lembah di bawah Triglav (puncak tertinggi Slovenia) seperti yang dihitung menggunakan SRTM:

(Bagi yang tertarik, kode saya untuk membuat gambar ini dapat ditemukan di sini.)

Gambar ini pada dasarnya terbuat dari lapisan grafik elevasi yang berjarak sama seperti yang terlihat dari titik pusat. Semakin gelap area biru, semakin jauh lapisan elevasi; semakin terang area biru, semakin dekat lapisan elevasi. Titik tertinggi yang ditarik mewakili garis horizon. Jika satelit GPS berada di bawah garis ini di langit, perangkat kita mungkin tidak dapat melihat (atau terlihat) olehnya. (Namun, perhatikan bahwa meskipun gambar digambar sebagai persegi panjang yang diratakan, pada kenyataannya Anda memerlukan pengetahuan dasar tentang geometri bola untuk menghitung area di bawah cakrawala dengan benar.)

Hal lain yang perlu diingat adalah bahwa ini bukan peluru perak untuk mendeteksi kesalahan ketinggian GPS. Pertama-tama, sebagian besar Bumi tidak bergunung-gunung dan, bahkan jika memang demikian, dalam psikologi kitalah untuk melebih-lebihkan ketinggian; persentase sebenarnya dari langit yang terlihat lebih besar dari 75% di sebagian besar wilayah yang berpenghuni . Namun demikian, metode ini dapat membantu dalam situasi tertentu, seperti mendaki gunung di mana Anda dapat beralih dari berada di ngarai yang dalam (dengan penerimaan GPS yang buruk) menjadi berada di punggungan gunung (di mana penerimaan satelit mungkin jauh lebih baik). Meskipun metode ini bukan ukuran absolut dari berapa banyak kesalahan yang dimiliki trek, ini bisa menjadi indikator yang berguna tentang bagian mana dari trek Anda yang mungkin lebih rawan kesalahan daripada yang lain.

Bungkus

Kami telah membahas beberapa jenis kesalahan pelacakan GPS yang lebih umum terjadi pada perangkat GPS kelas bawah. Kami telah memberikan pemahaman tentang apa yang menyebabkannya serta beberapa teknik pemrograman GIS untuk memperbaikinya.

Dalam beberapa kasus, kami dapat memperbaiki trek dengan tingkat kepercayaan yang tinggi. Dalam kasus lain, kami setidaknya dapat mengingatkan pengguna pada bagian trek yang tampak meragukan. Dalam kasus di mana kami tidak yakin, selalu ada opsi untuk memungkinkan pengguna memperbaiki trek sendiri, dibantu oleh citra udara dan peta. Tebakan probabilistik kami dapat membantu menyorot bagian trek yang kemungkinan kesalahannya lebih tinggi.

Dalam banyak kasus, teknik yang telah kami uraikan dapat menjadi "solusi 80%" yang memuaskan, menyediakan pengguna perangkat GPS kelas bawah dengan tingkat peningkatan otomatis yang wajar untuk akurasi trek GPS mereka.