![画像](https://habrastorage.org/getpro/habr/post_images/e9c/d26/c42/e9cd26c425c74b572d602bbd8f446bed.jpg)
2000年2月、11日間のシャトルEndeavorは、Spaceborne Imaging Radar-C / X-band Synthetic Aperture Radarを使用して地球のトポロジを撮影しました。 詳細はこちら
このプロジェクトの結果は、極域を除き、地球のトポロジに関するデータを含む公開データベースです。
完全なデータ配列は巨大であり、PC上でそれを操作することは非常に問題があります。 幸いなことに、 空間情報コンソーシアムプロジェクトサイトでは、関心のある分野のトポロジファイルをダウンロードできます。
データは、単純なDEMであるESRI GRID(ARC ASCII)形式で利用できます。 各マトリックスセルの緯度と経度は同じです。 このファイルは、メタ情報と、6001行と6001列の高さのマトリックスで構成されています。
最も可能性が高いのは、Mathlabがこの問題を解決するのに最も適したツールですが、それがないため、利用可能なツールを使用しました。MSSQL、Dapper、および.Netのコンソールアプリケーションです。
その結果、タスクは次の手順に分割されます。
- ファイルから、高さ、元のマトリックスの行番号と列番号、および高さを含むテーブルにデータをアップロードします。
- SQLクエリを実行して、高さの差が検索条件に適合する隣接フラグメントを選択します。
- 手順2で取得したフラグメントからチェーンを検索するクエリを起動します。
- 目的の長さのチェーンをKMLにエクスポートします。
データの読み込みが終日かかるのを防ぐために、バッチローダー-SqlClient.SqlBulkCopyを使用しました。
ステップ2が最もリソースを消費することが判明しました最初のアイデアは、ほぼ次の方法でテーブル自体を結合することでした
select * from Points p1 JOIN Points p2 ON p1.row<>p2.row and p1.[Column]<>p2.[Column] AND p2.row between p1.row-1 and p1.Row+1 and p2.[Column] between p1.[Column]-1 and p1.[Column]+1
ただし、36,000,000レコードのテーブルでは、このようなクエリは耐えられないほど遅い-何時間も何時間もかかります。 インデックスを使用したさまざまな実験では、パフォーマンスは大幅に向上しませんでした。
いつものように-最も単純な解決策が最も効果的であることが判明しました:カウンター付きのフィールドをポイント付きのテーブルに追加すると、各行の列数がわかっている場合、プレートをペイントして隣接IDを検索できます:
ID-6002 | ID-6001 | ID-6000 |
ID-1 | ID | ID + 1 |
ID + 6000 | ID + 6001 | ID + 6002 |
これにより、JOINを大幅に簡素化できます。
select * from Points p1 join Points p2 on (p2.id in (p1.id-6000-2,p1.id-6000-1,p1.id-6000,p1.id-1,p1.id+1,p1.id+6000 ,p1.id+6000+1,p1.id+6000+2)) WHERE p1.Elevation-p2.Elevation>X
IDフィールドにインデックスがある場合、そのようなリクエストは非常に効果的であり、15分以内に完了することができます。
以前に見つかったフラグメントのチェーンを構築するための最も効果的な再帰CTE要求は、おおよそ次のタイプでした。
with chains (id,id1,id2,level,parentID,alt) AS ( select c1.id,c1.id1,c1.id2,0 as level,c1.id as parentID, c1.alt1 as alt from candidates c1 where not exists (select * from candidates c2 where c2.id2=c1.id1) and exists(select * from candidates c2 where c2.id1=c1.id2) UNION ALL select c1.id,c1.id1,c1.id2, level+1 as level,c2.id as parentID,c1.alt2 as alt from candidates c1 join chains c2 on c1.id1=c2.id2 ) select distinct p.*,level,ParentID from chains c1 join candidates c2 on c1.id=c2.id join Points p on p.ID=c2.id1 or p.id=c2.id2
SharpKmlライブラリを使用したKMLへのエクスポートは非常に簡単です。 以前に計算された座標と高さを含むLineStringオブジェクトを組み込むPlacemarkオブジェクトが作成されます。
検索語
スキーやボードが雪に引っかかるだけでなく、どこかに行くためには、スロープは少なくとも10〜12度でなければなりません。そのため、少なくとも200〜300メートルのスロープの長さにある程度の関心を払う必要があります。
一方、35度以上の傾斜はリラックスした乗り心地を意味するものではありません。そのような急勾配を専門家に任せましょう。
例として、 サイトから同じそろちゃんの特徴を引用することができます 。
- トラックの長さ:500から1000メートル。
- トラックの幅:30から70メートル。
- 高度差:70から90メートル。
- 高度:230メートル。
- 平均勾配:10〜12度。
- 最大勾配:25度。
結果
モスクワ地域の最高地点-317メートルは、駅エリア147 kmにあります。 モジャイスク方向( 地図 )。 最低地点は-75メートル( 地図 )で、ヴォルガ川河床のルイビンスクの範囲内にあります。
最大の落差が60 mで長さが250 mの斜面は、トヴェリ州チュカヴィーノの村の近くのヴォルガ川のほとりにあります( 地図 )。
残念ながら、このスロープは、他のほとんどの良好なドロップとスロープと同様に、川岸に沿って位置し、森林で覆われていますが、理論的に適切ないくつかの適切なオプションを見つけることができました:
落とす | 斜面の長さ | 座標 | 解説 |
---|---|---|---|
51 | 300 | 56°16'4.70''C; 38°20'34.20'' | 滝「ガラガラヘビ」はとても美しい場所です |
43 | 200 | 56°26'22.08''C; 37°50'37.35'' | ドミトロフスキー地区スタロヴォ村 |
51 | 200 | 55°38'21.04''C; 37°51'37.99''B | ジェルジンスキー採石場 |
42 | 200 | 56°28'55.13''C; 38°11'55.16''B | ザゴルスクPSPの反対側。 D.ヴィプクロヴォ |
59 | 250 | 55°17'28.08''C; 38°43'5.33'' | ホワイトマウンテン。 ヴォスクレセンスク |
もちろん、有名なスキーリゾートはサンプルに含まれています。
リゾート | 高さ、m | 斜面の長さ、m |
---|---|---|
無料です | 42 | 200 |
細断 | 40 | 200 |
チョルコヴォ | 46 | 200 |
つる | 42 | 200 |
パラモノボ | 50 | 250 |
示された数値はデータの離散性のために不正確であることを考慮する必要があります。DEMの各「正方形」の辺は92.7 mです。
POCとして、ドミトロフスキー地区のスタロヴォ村の近くの斜面を選びました。
地元の祖母は、ここで、エンドウ豆の王の時代に、スキーリフトが働いたと言いました。 傾斜は緩やかですが、かなり長く、下流に低木が生い茂っています。 ここ、ウィキマピアによると、村にはハンググライダーの基地があります。
この斜面をテストしたビデオはこちらでご覧いただけます 。
→ githubのプロジェクトアドレス
→ 生成されたKMLファイルの例
→ インストーラー