Bagaimana model trek GPS terbaik untuk penyimpanan, visualisasi dan analisis?

Saya sedang berpikir tentang menulis perangkat lunak untuk berurusan dengan GPS Tracks dan Waypoints (kebanyakan menyimpan, menampilkan, dan menghitung metrik seperti kecepatan, tingkatan, dan beberapa statistik sederhana).

Saya bertanya-tanya apa yang harus menjadi model data yang paling kuat secara konseptual mengenai trackpoint, dan berikut adalah beberapa "kandidat":

Mempertimbangkan Tracks sebagai urutan Trackpoints:

1.1. Trek dianggap "2D", karena proyeksi peta adalah 2D. Trackpoint mungkin memiliki atau tidak memiliki ketinggian, mungkin atau tidak memiliki stempel waktu. Ketinggian dan stempel waktu dianggap "ekstra", "opsional". Untuk aplikasi terestrial, elevasi adalah fungsi langsung dari lat / lon (dapat diperoleh melalui DEM);

1.2. Trek dianggap "3D" karena ruang geografisnya memang 3D, dan lintasan penerima adalah 3D (dengan demikian, proyeksi 2D merupakan bentuk reduksi data). Stempel waktu mungkin atau tidak ada (trek bisa ditarik dengan tangan).

1.3. Trek dianggap "4D" (3 spasial + waktu). Dengan demikian, peta yang digambar tangan adalah kasus khusus di mana ketinggian dan cap waktu tidak ada nullatau tidak ada, tetapi properti Trackpoint selalu "ada".
Trek dianggap sebagai kamus aliran, di mana semua aliran memiliki panjang yang sama. Ada daftar garis lintang, daftar garis bujur, daftar ketinggian, salah satu stempel waktu, dll. Ini memudahkan untuk menghitung statistik setiap properti, dan konsep Trackpoint menjadi "virtual" dalam arti tertentu, karena merupakan penampang banyak aliran.

Jika saya mengerti benar, format GPX mengadopsi 1.1., KML mengadopsi 1.2. (tanpa dukungan untuk stempel waktu), dan Strava API mengadopsi 2. (dalam format JSON), tetapi pada akhirnya ini hanyalah format FILE untuk serialisasi dan penyimpanan, tidak harus untuk pemodelan, representasi komputasi, dan penjumlahan angka.

Apakah ada bentuk yang lebih disukai, dalam arti berorientasi objek, dan mengapa? (Saya percaya bahwa pengetikan yang kuat dan pemodelan yang masuk akal setidaknya akan menghindari operasi yang tidak masuk akal).

EDIT: beberapa pertanyaan tambahan "menarik":

Apakah trek yang digambar tangan SEPENUHNYA sama dengan tracklog yang direkam perangkat? Haruskah mereka dari tipe data yang berbeda?
Haruskah dianggap "benar" bahwa KML menyimpan elevasi nol sebagai nol? Nol ADALAH ketinggian, dan jika Anda tidak tahu ketinggian, Anda tidak harus menetapkan nol numerik untuk itu, bukan?
Apakah itu penting, di trek dengan ketinggian, jika ketinggian diekstraksi dari data DEM ("offline") atau dari data GPS atau data barometrik ("di lapangan")? Haruskah ini ditandai di objek Track? Disimpan ke properti Trackpoint yang berbeda? Diabaikan? Haruskah mereka tipe data koleksi yang berbeda?
Jika saya mengedit trek yang direkam perangkat dalam editor peta (menambah, memindahkan, dan menghapus titik), atau menggabungkan trek dari tanggal yang berbeda, bagaimana penanganan stempel waktu pada trackpoint? Haruskah mereka "dipindahkan" ke nol? Haruskah objek (koleksi trackpoint) dari jenis yang berbeda dibuat dari yang sebelumnya?

— heltonbiker
sumber

3. Trek adalah kumpulan poin dengan x, y, z, m [] dan atribut waktu. File CSV yang berisi 5 nilai ini untuk setiap titik yang ditangkap lebih dari cukup untuk model data yang kuat. Jika Anda membutuhkan hal-hal mewah seperti <>dan {}untuk membantu Anda mengatur data Anda - dan meta data - Anda salah melakukannya.

— nagytech

Saya setuju dengan CSV lama yang bagus, itu mewakili semua yang direkam GPS. Tapi, format GPX cukup umum untuk perangkat GPS. Tautan ini mungkin bernilai karena GPS dan KML adalah format data XML. stackoverflow.com/questions/1820129/…

— Pete

Meskipun XML 'hebat' dan semua (karena alasan dalam postingan terkait @ Pete) tidak satu pun dari poin itu relevan. Jika ada, overhead tidak memperlambat laju angka, dan mengasapi penyimpanan data dan metode transmisi Anda. Memang, jika Anda seorang ibu-n-pop operasi Anda tidak akan pernah memiliki cukup data untuk menghadapi masalah ini, dan angka Anda tidak akan menjadi intens. Either way, Anda tidak akan memiliki sumber daya untuk mempertahankan operasi sedekat ini logam - jadi XML pergi.

— nagytech

Perhatikan bahwa pertanyaan ini lebih banyak berkaitan dengan MODELING dan desain data (representasi esensi konseptualnya) daripada implementasi yang sebenarnya. Komentar sejauh ini fokus dalam format file, yaitu, dari apa yang saya pikirkan, namun lebih jauh, karena format file lebih tergantung pada media implementasi daripada sifat data itu sendiri.

— heltonbiker

Dalam istilah OO, saya telah menggunakan kelas Line yang dapat menampung poin (lat, lng, ele, waktu, kecepatan, bantalan, dll). Dan, dari sana Rute yang mewakili "trek" yang digambar tangan atau dimaksudkan dan Trek yang mewakili trek aktual dengan data waktu / kecepatan. Secara konseptual, saya TIDAK berpikir mereka berbeda (digambar tangan dan atau dipasok oleh kartografer, atau semacamnya, versus trek yang sebenarnya). Istilahnya hanya semantik, tentu saja, tetapi menggunakan tipe nyata telah membantu (bukan hanya menumbuk semuanya sebagai "Track"). Juga, ketika datang ke format serialisasi, saya akan mempertimbangkan GeoJSON: en.wikipedia.org/wiki/GeoJSON .

— Charlie Collins

Jawaban:

Saya tidak berpikir pertanyaan ini sebenarnya dapat dijawab secara pasti karena ada banyak, banyak cara untuk mendekati ini ..

Namun, pemikiran ini mungkin relevan:

Penyimpanan data relatif tidak penting. Apa pun mekanisme yang Anda gunakan, Database, JSON, KML, dll, itu masih "penyimpanan datar".

Yang penting adalah perangkat lunak yang Anda gunakan dan bagaimana Anda merepresentasikan data dalam Perangkat Lunak sehingga Anda dapat melakukan pemodelan Anda.

Kecepatan tersedia dua cara, jarak x waktu atau sebagai output dari perangkat GPS, yang merupakan asal Anda sumber data. Oleh karena itu waktu menjadi tidak relevan selain sebagai item informasi.

Selain itu, Anda juga dapat mempertimbangkan waktu dengan menggunakan offset dari awal trek. Jika Anda memiliki kecepatan dan jarak, maka Anda dapat menghitung waktu di titik. (jarak antara dua titik dapat ditentukan dengan sejumlah metode yang berbeda )

Ketinggian harus dianggap sebagai bagian dari Model Spasial, mereka relevan untuk menentukan sejumlah besar informasi menarik tentang trek itu sendiri, misalnya kelas dapat dihitung yang kemudian memungkinkan Anda untuk memahami variasi kecepatan di sepanjang trek. Jika tidak ada grade, penurunan atau peningkatan kecepatan apa pun mungkin disebabkan karena melepas kaki dari pedal gas.

Dalam hal menggabungkan trek dan trek yang digambar tangan, waktu kurang relevan. Anda dapat menerapkan kecepatan sewenang-wenang untuk menentukan waktu, misalnya, berapa lama untuk melintasi trek pada kecepatan tertentu. Jika Anda menggabungkan trek beberapa hari secara terpisah, maka data Anda tidak akan masuk akal sehingga Anda harus mengatur ulang bidang waktu, mungkin menggunakan offset dari awal lagu.

Jika ketinggian tidak diketahui, maka tidak diketahui, karena itu seharusnya tidak nol. Itu juga tidak boleh negatif, karena ketinggian negatif juga merupakan ketinggian yang valid. (Di lembah di bawah permukaan laut, lubang tambang, dll)

Ya, DEMS tersedia, Ya, Anda dapat mengekstraknya. Akankah ini cukup akurat? Tidak mungkin, kecuali keakuratannya tidak menjadi masalah. GPS atau barometrik yang disediakan Elevasi akan menjadi yang terbaik yang bisa Anda dapatkan.

Jadi untuk mencoba dan memberi Anda jawaban yang mendekati:

Simpan data dalam format datar apa pun yang Anda suka, tetapi saya akan merekomendasikan, PostGRES dengan PostGIS adalah pilihan yang baik, menangani 3D dengan baik. Anda kemudian dapat menggunakan fungsi spasial yang luas di PostGIS untuk memanipulasi / memodelkan data Anda.

Jika Anda menggunakan beberapa bentuk program kustom yang Anda kembangkan, gunakan pendekatan Berorientasi Objek daripada array. Jika Anda menggunakan array, Anda juga dapat menggunakan database.

— Mark Cupitt
sumber

Terima kasih banyak atas waktu dan minat Anda, saya menemukan jawaban Anda sangat menarik. Tetapi dengan satu hal saya "tidak bisa" setuju: bahwa kecepatan adalah variabel kanonik, sementara waktu tidak. Ini karena banyak alasan, tetapi terutama karena kecepatan adalah turunan jarak dari waktu ke waktu. Anda akan selalu mendapatkan kecepatan yang baik, dan kecepatan rata-rata yang baik khusus (yang saya temukan lebih berguna daripada kecepatan instan), jika Anda menurunkan jarak segmen dari waktu ke waktu segmen. Di sisi lain, jika Anda mengintegrasikan kecepatan, kesalahan integrasi akan memberikan hasil yang sangat salah setelah sejumlah kecil sampel.

— heltonbiker

Ya, saya bisa mengakui hal itu. Namun, penggunaan Trek GPS itu sendiri tunduk pada kesalahan posisi. Ini semua masalah akurasi apa yang bisa Anda dapatkan. Setuju, Waktu cukup akurat, tetapi Anda akan mendapatkan kesalahan saat menggunakannya juga karena kesalahan posisi GPS. Interval satu detik pada titik-titik lintasan hanya itu, satu detik, tetapi di dalam GPS, algoritmanya mungkin akan tetap diinterpolasi untuk sampai pada posisi yang diperkirakan. Jelas granularitas data akan berdampak besar pada metode analisis apa pun yang dipilih

— Mark Cupitt

Sangat bagus ... Itu sebabnya saya sudah menyerah merencanakan "kecepatan instan" sama sekali, pergi untuk semacam "kecepatan rata-rata sesaat", itu akan menjadi: "untuk setiap titik tertentu dalam lintasan, kecepatan rata-rata sesaat adalah rata-rata kecepatan N menit terakhir. " Plotnya sangat bagus, dan memberikan rasa variasi kecepatan yang sesuai sepanjang perjalanan. Tetapi perhitungan yang tepat bisa rumit dan kemungkinan besar sedikit intensif secara komputasi.

— heltonbiker

Seperti yang telah disebutkan dalam jawaban lain, ada banyak pendekatan berbeda. Karena saya meminta "model data yang kuat secara konseptual", setelah banyak penelitian saya menemukan dua kumpulan besar pengetahuan yang menyediakan dua pendekatan yang sangat berbeda untuk konsep "objek bergerak", dan memiliki banyak tumpang tindih (dalam arti yang baik):

Buku-buku dari Gennady dan Natalia Andrienko, diterbitkan oleh Springer Verlag, misalnya Visual Analytics of Movement yang sangat baik (antara lain dari penerbit yang sama). Sangat dianjurkan.
The Spesifikasi Abstrak (skema konseptual) dari ISO / OGC (ISO 191xx norma), khususnya ISO 19107 (Tata Ruang Skema), 19.108 (Temporal Skema), 19.111 (Tata Ruang Mengacu oleh Koordinat), 19.141 (Moving Fitur) dan 19.148 (Linear Mengacu)

— heltonbiker
sumber