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

現在、OpenLayersマッピングサイトを開発しています。測定は、ラインツールとエリアツールを使用して行うことができます。現在、これらの両方は、OpenLayers APIで概説されている測地線測定値を計算するように設定されています。 ユーザーのテスト中に、人々がツールの測定値に既に知っている距離（町間の運転など）を疑問視したため、平面測定ではなく測地線測定を使用します。 サイトの新機能は、ユーザーが設定された半径の地図上に円を描くことができることです。OpenLayersでは、平面距離を使用した円の描画のみが許可されているため、ユーザーが測地線測定ツールで円を測定すると、値が一致しません。下の画像では、円の平面半径は10kmですが、直径の測地線の測定値は12kmです。 これにより、ユーザー（と私）はどちらが正しいのか疑問に思うようになります。 この答えを見ると、ほとんどのデスクトップGISシステムはこの問題を「無視」し、平面測定値と距離を返しているようです。では、平面および測地線の測定を処理するためのユーザーインターフェイスと精度の観点から、ベストプラクティスは何でしょうか。 更新 半径とメルカトル図法の問題を示すこのGoogleの例を見つけました。 http://maps.forum.nu/gm_sensitive_circle2.html 円を描くJavaScriptコードは次のとおりです。 var lat1 = (PI/180)* center.lat(); // radians var lng1 = (PI/180)* center.lng(); // radians for (var a = 0 ; a < 361 ; a++ ) { var tc = (PI/180)*a; var y = asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc)); var dlng = atan2(sin(tc)*sin(d)*cos(lat1),cos(d)-sin(lat1)*sin(y)); var …

15 openlayers-2  geodesic  measurements 

線がシェープファイル形式で頂点を接続する方法についての定義はありますか？ 最も単純な場合、標準のWGS84地理座標系を使用して、40、-118から40、-112までの2つのポイント（米国ではどこかランダム）のラインを想像してください。.prjファイルの内容は次のとおりです。 GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] ポイントは、ラインの40.1、-116北または南ですか？ 線が緯度の長い空間で直線的に補間されると考えると、それは40度の平行（小さな円）に従い、点は線の北になります。 線が地球表面上の最短経路であると考える場合、それは線の中央で最大緯度が40.1度を超える測地線（大円）です。その後、ポイントはラインの南になります。 それとも、単に未定義ですか？シェープファイル形式には曲線の概念はないため、直線を結ぶ直線セグメントのみがあります。この答えを明確にするには、ラインを高密度化する必要があります（ラインに沿ってポイントを追加）。 QGISでこのようなシナリオを作成すると、線は40度の平行線をたどり、答えは1であるとわかります。しかし、これを明確な答えとして受け取らず、より堅実な答えを聞きたいと思います。

13 shapefile  great-circle  geodesic 

で測地線バッファリングの理解、Esriのジオプロセシング開発チームは、ユークリッドと測地線バッファリングを区別します。「投影されたフィーチャクラスで実行されるユークリッドバッファリングは、誤解を招く技術的に不正確なバッファを生成する可能性があります。ただし、測地線バッファは、投影座標系によって導入される歪みの影響を受けないため、常に地理的に正確な結果を生成します。」 ポイントグローバルデータセットを使用する必要があり、座標は投影されません（+proj=longlat +ellps=WGS84 +datum=WGS84）。メートル単位で幅が指定されている場合、Rに測地線バッファーを作成する関数はありますか？パッケージgBufferから承知しておりrgeosます。この関数は、使用される空間オブジェクト（例）の単位でバッファーを作成するため、座標を投影して、目的のX kmのバッファーを作成できるようにする必要があります。投影してから、gBuffer実際にユークリッドバッファーを作成する手段を適用します。以下は、私の懸念を示すためのコードです。 require(rgeos) require(sp) require(plotKML) # Generate a random grid-points for a (almost) global bounding box b.box <- as(raster::extent(120, -120, -60, 60), "SpatialPolygons") proj4string(b.box) <- "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs" set.seed(2017) pts <- sp::spsample(b.box, n=100, type="regular") plot(pts@coords) # Project to Mollweide to be able to apply buffer with …

9 coordinate-system  r  buffer  rgeos  geodesic 

基本的なポイント、ライン、ポリゴンのプリミティブを使用して、「プロジェクションフリー」の地理的コードベースを考察（およびプロトタイプコーディング）しています。 ただし、平面への投影に伴うすべての犠牲を処理するのではなく、楕円体の表面で直接機能するアルゴリズムを作成しています。 潜在的な問題の1つは、さまざまな種類の「ライン」が存在することです。 （円弧）大円：2点間の（一定の標高）サーフェスに沿った最短距離。見通し線に正確に対応する必要があります。 横線：2つのポイントを一定の方向のパスで接続します。たとえば、州の境界の一部は緯度の線（大圏ではありません）に従います。 曲線：円弧（特定の中心点から一定距離のパス）。ベジェ（曲面のコンテキストでの正しい再解釈については不明）など さまざまな種類のパス（見逃したパスを含む）のうち、「正確な」表現を持つのに十分重要であるか、またはより単純なパスの短いセグメント（たとえば、短い測地線弧セグメント）によってエラー境界内を表すのか？ 明確化の編集：上記の「正確」とは、パラメトリックを意味します。言い換えると、インポート時の高密度化ステップなしで、任意の精度で計算できます。 後に引用を追加するための編集は、地理プリミティブとしての3D単位ベクトルの使用に関する私自身の考えとほぼ同じです。非特異水平位置表現（altリンク）。最良の部分？自分ですべて書く必要はありませんでした！

8 coordinate-system  distance  representation  ellipsoid  geodesic