Menghitung jalan nyata secara statistik dari set trek GPS?

Saya berpartisipasi dalam klub bersepeda jarak jauh, dan kami mulai mengumpulkan data GPS secara rutin dari pengendara kami.

Ketertarikan saya adalah menghitung "lintasan nyata" untuk acara mendatang berdasarkan akumulasi data GPS di jalan yang sama. Pada dasarnya, ini berarti melewatkan beberapa trek yang dipilih sebelumnya ke suatu algoritma, dan algoritma tersebut akan menghasilkan titik pada laju sampel yang sesuai (jarak yang sesuai satu sama lain tergantung pada kurva jalan). Saya akan membuang cap waktu, dengan hanya memperhitungkan informasi trek spasial.

Algoritme / metode statistik mana yang dapat saya gunakan? Saya tidak menggunakan paket GIS dan saya berencana untuk mengimplementasikannya dengan Python.

Di bawah ini, beberapa set lintasan sampel:

masukkan deskripsi gambar di sini

gps spatial-statistics tracklog heltonbiker
sumber

Proyek menarik - sangat mirip dengan algoritma inspeksi yang saya tulis tahun lalu. Karena saya malas, saya hanya bisa memberikan beberapa petunjuk. Faktor terpenting adalah arah perjalanan, kualitas sinyal, dan kecepatan Anda (mis. Jika Anda hanya berdiri saja, itu bukan jalan). Yang terbaik adalah menyisihkan poin yang terlalu jauh. Selain itu, saya akan menerapkan algoritma perataan (coba DP) kemudian rata-rata garis.

nagytech

DP = Pemrograman Dinamis bukan? Wikipedia memberi saya bacaan panjang untuk pekerjaan rumah untuk malam ini ... Terima kasih untuk sekarang!

heltonbiker

Pertanyaan yang menarik dan terkait adalah ini: gis.stackexchange.com/questions/42224/…

heltonbiker

Sesuatu yang benar-benar layak untuk diperiksa adalah pengaturan GPS Anda - beberapa unit GPS "pasang" posisi Anda ke jalan terdekat dalam basis data GPS, bahkan jika jalan sebenarnya 10 + m ke samping.

Simbamangu

@Simbamangu itu akan menjadi hal yang sangat menyenangkan untuk dimiliki. Saya percaya perangkat lunak yang saya gunakan hari ini di ponsel android tidak memilikinya. Tapi bagaimanapun, sebagian besar jejak saya dikumpulkan oleh orang lain dalam beberapa bulan terakhir. Terima kasih atas tipnya!

heltonbiker

Jawaban:

Chris Brunsdon memberikan makalah tentang masalah ini pada konferensi GeoComputation 2008 - lihat http://www.geocomputation.org/2007/1B-Algorithms_and_Architecture1/1B2.pdf

Dalam makalah ia membahas bagaimana menerapkan Analisis Kurva Kepala (Hastie dan Stuetzle 1989) dan membuat beberapa saran tentang cara meningkatkan kekokohan metode ini. Pencarian lebih lanjut mengarah ke diskusi tentang alat OSM yang disebut osm-makeroads yang mungkin dapat memecahkan masalah Anda (atau setidaknya membantu Anda memulai).

Ian Turton
sumber

Ayo lihat dan berikan umpan balik segera! Terima kasih untuk sekarang!

heltonbiker

+1 Referensi yang bagus. Ini perlu diperbaiki, karena mengabaikan masalah mendasar dengan jejak GPS: kesalahan tidak terpisah dari satu titik ke titik berikutnya. Sebagai gantinya, kesalahan GPS yang dibuat pada satu titik akan cenderung sangat mirip dengan kesalahan yang dibuat pada titik berikutnya pada jejak yang sama. Anda dapat melihat ini dalam ilustrasi Brunsdon: poin-poin yang bermasalah (terpencil) jelas terletak pada satu atau dua jejak luar biasa; mereka tidak sporadis atau acak. Dengan demikian ada potensi besar untuk perbaikan dengan memodelkan autokorelasi ini dan menyesuaikannya dalam algoritma.

whuber

@whuber setuju. Sesuatu yang sebagian besar algoritma gagal pertimbangkan (Kurva Utama menjadi salah satunya, seperti yang sudah saya ketahui), adalah set trek GPS bukan awan titik, melainkan awan "linestring". Mereka memang vektor yang terhubung atau semacamnya. Mempertimbangkan poin saja akan menimbulkan bias terhadap trek dengan laju sampel lebih tinggi, alih-alih wilayah tempat LINES dari trek berbeda lebih padat ...

heltonbiker

Percakapan ini dilanjutkan di utas terkait di stats.stackexchange.com/questions/69329 .

whuber

@whuber Dalam jawaban ini saya telah menuliskan sebuah ide, yang muncul di benak saya, untuk melakukan ini dengan bantuan peta panas. Saya menghargai setiap saran.

Stefan