Bagaimana cara mendapatkan profil elevasi untuk trek gps?

Saya ingin mendapatkan profil ketinggian yang cukup akurat untuk trek yang direkam dengan GPS (yang sering memiliki data ketinggian yang sangat tidak dapat diandalkan dan kadang-kadang tidak ada sama sekali, tergantung pada modelnya.)

Adakah yang punya petunjuk tentang cara termudah untuk melakukan ini. Dua teknik yang saya pertimbangkan sejauh ini adalah:

• Menggunakan Google Elevation API

  API ini relatif mudah digunakan, tetapi masih memerlukan beberapa langkah yang tidak sepele karena pembatasan penggunaannya: maks 512 sampel yang dikembalikan per permintaan, dan jumlah titik di sepanjang jalur juga terbatas (menurut panjang URL).

  Saya berharap filter penyederhanaan gpsbabel dapat dibuat untuk mengurangi trek ke sejumlah titik yang sesuai (tidak ada titik di dalamnya yang lebih dekat dari 100m atau lebih bersamaan karena resolusi data ketinggian), tetapi kemudian masalahnya adalah bagaimana memetakan trek yang disederhanakan ini kembali ke jalur asli, karena panjangnya akan berbeda.

  Atau, jika ini tidak cocok untuk otomasi, pendekatan terbaik adalah membiarkan pengguna memilih titik transek pada peta secara manual.

• Mengunduh data Misi Topografi Radar Shuttle (SRTM) dan melakukan kueri secara lokal.

  Ini adalah sesuatu yang saya tidak punya pengalaman dengan, jadi saran tentang seberapa layak ini disambut. Seberapa besar set data? Perangkat lunak SIG apa yang diperlukan, dan dapatkah dituliskan dengan cara yang sesuai? Saya lebih suka tidak harus menulis algoritma sampling dan interpolasi, yang terdengar seperti rasa sakit . Bagaimana kinerja dari pendekatan semacam itu? (Saya perlu cukup cepat dan berjalan di server VPS terbatas memori ...)

Beberapa perincian lebih lanjut untuk menyempurnakan jawaban @ MerseyViking sedang mengunduh data dari http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp :

Ada 72 x 24 ubin, masing-masing sekitar file zip 20mb yang didekompresi menjadi file TIF 16,1mb 16bit (6001x6001 piksel).

Itu ~ 120 gb, lebih dari yang bisa saya simpan. Membiarkannya terkompresi dan mengabaikan lautan akan menguranginya hingga mungkin 10GB, yang masih agak terlalu besar. Memuat data berdasarkan permintaan akan secara dramatis mengurangi ruang penyimpanan yang dibutuhkan, tetapi situs sumbernya lambat (saya hanya mendapatkan 10kb / dtk) menjadikannya sangat tidak praktis.

Untuk solusi lokal, GRASS dapat diarsipkan untuk melakukan ini:

# extract raster values at our points
# use cubic convolution for interpolation between DEM locations
v.drape in=my_pts out=pts_srtm_elev type=point rast=srtm_dem method=cubic

Saya menjalankan versi yang diperluas untuk salah satu kasus penggunaan saya dan kinerja v.drape tidak ada masalah sama sekali.

gpsvisualizer.com akan melakukan ini untuk Anda. Saya percaya ini menggunakan GPSBabel dan Google API di latar belakang.

Sepertinya Anda memerlukan ini sebagai solusi umum, yaitu memiliki semua data elevasi dunia tersedia untuk Anda untuk trek apa pun yang ingin Anda proses, karenanya tidak ingin menyimpan semua data CGIAR secara lokal; gpsvisualizer.com yang disebutkan di atas (@Llaves) mungkin merupakan taruhan terbaik Anda.

Jika Anda tidak memerlukan resolusi tinggi, itu set data GTOPO (kisi 1 km) hanya ~ 300MB untuk seluruh planet; jika tidak, set data ASTER GDEM (30m) dan SRTM (90m) asli tersedia tetapi, seperti yang Anda tunjukkan, banyak data. (Ukuran data ASTER dapat dikurangi setelah mengunduh dengan menghapus file PDF yang dibundel yang seringkali lebih besar dari data elevasi aktual - dataset Afrika berkurang hingga 40% ketika saya melakukan ini!).

Di R, Anda dapat mengekstrak profil elevasi dari salah satu set data ini dengan cukup cepat - meskipun memuat raster mungkin menghabiskan sebagian besar waktu. Ini menggunakan fungsi readGPX kecil dan gpsbabel untuk memproses data GPX:

#Load elevation model and process track:
dem <- raster("E020N40.DEM")
track <- readGPXt("trackfile.gpx")
coordinates(track) <- ~Longitude+Latitude
proj4string(track) <- "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs"
#Overlay (extract) the elevation data for the track points:
track$profile <- extract(dem, track)
track <- as.data.frame(track)

'track' sekarang merupakan tabel titik-titik GPS dengan lat / lon, data GPX standar lainnya (kecepatan, ketinggian gps, dll), dan kolom 'profil' yang menunjukkan ketinggian pada titik itu.

Data SRTM mudah diunduh untuk area tertentu, saya pernah menggunakan situs ini . File-file tersebut tidak besar, dan Anda bisa mendapatkannya sebagai TIFF yang di-georeferensi. Mengunduh seluruh dunia mungkin memakan waktu cukup lama, tetapi beberapa ubin mencakup area yang cukup besar. Masalah yang mungkin Anda miliki adalah dengan resolusi horizontal, yaitu sekitar 90 meter untuk sebagian besar dunia, dan kesalahan vertikal bisa sangat besar, dengan lonjakan dan bidang data yang hilang.

Dataset ASEM GDEM adalah survei resolusi lebih baru dan lebih tinggi pada ~ 30m resolusi horizontal, tetapi kualitasnya sering lebih rendah daripada data SRTM yang sesuai.

Saya tidak tahu apa resolusi data elevasi Google, tapi saya tidak akan terkejut jika didasarkan pada SRTM, jadi menggunakan Google API dapat memberikan hasil yang mirip dengan menggunakan proses lokal.

Sebagai lanjutan dari jawaban oleh @underdark, jika ini adalah sistem berbasis web yang sederhana, GRASS GIS mungkin adalah cara yang harus ditempuh. Saya telah menggunakan r.profile untuk melakukan plot intervisibilitas sederhana dengan beberapa keberhasilan tetapi saya tidak yakin apa metode interpolasi yang digunakannya; mungkin tetangga terdekat saja. Edit : Melihat kode sumber ,r.profile apakah menggunakan tetangga terdekat, sehingga Anda mungkin mendapatkan beberapa artefak tangga-loncatan.

Pilihan lain mungkin untuk menulis skrip Python, menggunakan GDAL dan NumPy , yang mungkin sedikit lebih berhasil, tetapi akan membuat solusi kustom yang bagus.

Pertama, Anda harus menentukan apa presisi horizontal / vertikal Anda akan puas dengan.

Tapi mari kita lihat ini dari perspektif praktis:

• Setiap ubin SRTM3 memiliki sel 1200x1200 , setiap sel adalah nilai integer dua byte yang mewakili ketinggian dalam meter. Itu sekitar 2,75 MB data mentah terkompresi.
• Ada 14042 ubin SRTM3. Itu cca. 38 GB data mentah.
• Apakah Anda benar-benar perlu menutupi seluruh dunia? Saya membayangkan tidak ada banyak minat untuk menampilkan profil ketinggian trek GPS di tengah Sahara, Gobi Desert, atau Siberia, jadi tidak layak secara ekonomi bagi Anda untuk menutupnya jika Anda kekurangan uang (BTW: SRTM3 tidak mencakup seluruh dunia , jadi Anda tidak perlu khawatir tentang tempat-tempat seperti Greenland dan Antartika;)).
• Dengan beberapa kompresi cerdas dan penyandian data Anda dapat mengurangi ukuran dataset secara dramatis. Nilai ketinggian adalah dari 0 hingga 8848 sehingga dua bit yang tersisa tidak digunakan. Anda juga bisa menyandikan ketinggian melalui kompresi delta untuk menguranginya lebih jauh. Anda juga bisa melepaskan beberapa ketelitian vertikal (untuk, katakanlah, 2m yang kemudian menghemat satu bit ekstra untuk setiap sel.
• Bergantung pada jenis trek GPS apa yang akan digunakan untuk (berjalan, bersepeda, mengemudi ...) Anda harus menyimpan data ke ubin yang lebih kecil (katakanlah 0,25x0,25 derajat) sebagai file pada disk atau baris dalam tabel database.
• Gunakan beberapa cache memori pintar untuk ubin sehingga Anda tidak perlu memuat ulang yang sering digunakan.
• Menghitung peningkatan dari sel adalah bagian mudah dari seluruh bisnis ini.