タグ付けされた質問 「trajectory」

この冬、GPSを使用してダウンヒルスキー/スノーボードを追跡する予定です。私のライディングのほとんどは同じリゾートで行われます。特定の領域で実行した実行の量を示す一種の「ヒートマップ」を作成できるようにしたいと思います。データベースにGPSトレースをますます追加するので、私の目標は、最も移動したエリアの一種の線形ヒートマップを表示することです。ダウンヒルスキーの性質を考えると、上り坂のチェアリフトラインは何度も何度も訪れる唯一の場所であるため、「最も暑い」場所になることが予想されます。 1）私のトラックは毎回同じではないこと、2）1回の「走行」でカバーされるエリアは数百フィートの幅があることを考えると、この「線形」データを分析してソートを作成する最良の方法は何でしょうかヒートマップの？私の考えは、ラインをバッファリングし、次にポリを交差させて、一種のベン図を作成することでした。私の好みは、オープンソース技術を使用することです。QGISとPostGISをロードして使用可能にしました。 更新：@ blah238の応答に関して、あるエリアを通るパス（「ラン」）の数を「収集」し、カウントでシンボル化できるものを考えていました。概念的には、これはArcGISの「イベントの収集」（ただし、ポイントではなくラインの場合）または二重線を中心線に折りたたむ（ただし、ほぼ同じ領域の複数のラインの場合）ことに似ています。 同様の概念のより視覚的な例としては、交通量の多い地図が挙げられます。交通量の多いエリアは、「非常に移動しやすい」スキーラン/エリアに相当します。 私はいくつかのアイデアを与えるかもしれない次の質問を読みましたが、彼らは私が達成しようとしていることを実際に扱っていません： 軌跡のクラスタリング（（x、y）ポイントのGPSデータ）およびデータのマイニング GPSルートのエラー管理（理論的枠組み？）

30 gps  clustering  gpx  heat-map  trajectory 

グライダーパイロットからは、一定の間隔でGPSを修正するという形で多くのフライトデータを取得しています。飛行経路を分析し、グライダーのパイロットがサーマルを見つけたときに行う「旋回」の開始と終了を検出したいと思います。 理想的には、アルゴリズムは線上の開始点と終了点を与え、1つの「円」を定義します。これらのポイントは、GPS修正の1つと等しくなる可能性があり、補間する必要はありません。 飛行経路に沿って歩き、回転数を確認し、グライダーが旋回しているかどうかを判断するための基準を設定することができました。 PostGIS拡張機能を備えたPostgreSQLを使用しているため、この問題に対するより良いアプローチがあるかどうか興味がありました。私はすでに2つの線分の角度を計算する手順を持っています： CREATE OR REPLACE FUNCTION angle_between( _p1 GEOMETRY(PointZ,4326), _p2 GEOMETRY(PointZ,4326), _p3 GEOMETRY(PointZ,4326) ) RETURNS DECIMAL AS $$ DECLARE az1 FLOAT; az3 FLOAT; BEGIN az1 = st_azimuth(_p2,_p1); az3 = st_azimuth(_p2,_p3); IF az3 > az1 THEN RETURN ( degrees(az3 - az1)::decimal - 180 ); ELSE RETURN ( degrees(az3 - …

24 postgis  postgresql  algorithm  trajectory 

GPSトラックとウェイポイント（主に速度、グレード、いくつかの簡単な統計などのメトリックの保存、表示、計算）を処理するソフトウェアを書くことを考えています。 トラックポイントに関して最も概念的に堅牢なデータモデルはどうあるべきかと思いますが、ここにいくつかの「候補」があります。 トラックをトラックポイントのシーケンスとして考える： 1.1。地図投影は2Dであるため、トラックは「2D」と見なされます。トラックポイントには標高がある場合とない場合、タイムスタンプがある場合とない場合があります。高度とタイムスタンプは「追加」、「オプション」とみなされます。地上アプリケーションの場合、標高は緯度/経度の直接関数です（DEMで取得可能）。 1.2。地理空間は確かに3Dであり、受信機の軌跡は3Dであるため、トラックは「3D」と見なされます（したがって、2D投影はデータ削減の形式です）。タイムスタンプが存在する場合と存在しない場合があります（トラックは手で描いた可能性があります）。 1.3。トラックは「4D」（3空間+時間）と見なされます。したがって、手描きのマップは、標高とタイムスタンプがnull存在する、または存在しない特別なケースですが、Trackpointプロパティは常に「そこ」にあります。 トラックは、すべてのストリームの長さが等しいストリームの辞書と見なされます。緯度のリスト、経度のリスト、標高のリスト、タイムスタンプの1つなどがあります。これにより、各プロパティの統計を簡単に計算でき、トラックポイントの概念はある意味で「仮想」になります。多くのストリームの断面。 正しく理解できれば、GPX形式は1.1を採用し、KMLは1.2を採用します。（タイムスタンプのサポートなし）、およびStrava APIは2（JSON形式）を採用しますが、最終的にはこれらはシリアル化とストレージ用の単なるFILE形式であり、必ずしもモデリング、計算表現、および数値計算用ではありません。 オブジェクト指向の意味で、好ましい形式はありますか？その理由は？（厳密な型付けと賢明なモデリングは、少なくとも意味をなさない操作を回避すると信じています）。 編集：いくつかの「興味深い」追加の質問： 手描きのトラックは、デバイスで記録されたトラックログと概念的に同じものですか？それらは異なるデータ型であるべきですか？ KMLがnullの標高をゼロとして保存することは「正しい」と見なされるべきですか？ゼロは標高であり、標高がわからない場合は、数値のゼロを割り当てるべきではありませんか？ 標高のあるトラックで、標高がDEMデータ（「オフライン」）またはGPSデータまたは気圧データ（「現場」）から抽出される場合、それは重要ですか？Trackオブジェクトでこれにフラグを立てる必要がありますか？別のトラックポイントプロパティに保存しますか？無視？それらは異なるコレクションデータ型であるべきですか？ デバイスに記録されたトラックをマップエディターで編集（ポイントの追加、移動、削除）したり、異なる日付のトラックを結合したりする場合、トラックポイントのタイムスタンプはどのように処理する必要がありますか？nullに「リセット」する必要がありますか？以前のオブジェクトとは異なるタイプのオブジェクト（トラックポイントコレクション）を作成する必要がありますか？

17 data  representation  data-model  trajectory 

私の最後の学術研究のために、GPS軌跡の圧縮アルゴリズムを開発しました。圧縮された軌跡と元の軌跡との間の同期ユークリッド距離（SED）を計算することにより、時空間圧縮の品質を推定し、既知の圧縮アルゴリズムに対するアルゴリズムのパフォーマンスを評価できます。 私のような時空間アルゴリズムは、可能な限り多くの時間情報を維持しようとする軌跡を減らします。空間アルゴリズム（ダグラスピーカーアルゴリズムなど）は、空間特性のみを参照して圧縮を実現します。 今、何が起きた？時空間的な側面を考慮すると、私のアルゴリズムはDPよりも優れています。SED測定でこれを保証できます。3つの軌道（オリジナル、地雷、DP圧縮）をプロットすると、DPで圧縮された軌道は、元の軌道との適合性が高くなります。目だけの測定は私のニーズを満たしていません。確かに、DPアルゴリズムが空間的にマイニングよりも優れていることを数値で示すエラーメトリックが必要です。 したがって、「時空間係数を参照すると、DPのSED係数よりもSED係数が小さいため、私のアルゴリズムはDPよりも優れています。ああ、単純な空間係数は、その（新しいメトリックの名前）私のものよりも優れています。」 私は垂直ユークリッド距離を考えていましたが、これが役に立つかどうか本当にわかりません。ダイナミックタイムワーピング？これにはどのメトリックを使用できますか？

10 algorithm  analysis  comparison  trajectory