2
ストレージ、視覚化、分析のためにGPSトラックを最適にモデル化する方法は？
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に「リセット」する必要がありますか？以前のオブジェクトとは異なるタイプのオブジェクト（トラックポイントコレクション）を作成する必要がありますか？