タグ付けされた質問 「coordinate-system」

私は世界地図のシェープファイルを持っていて、2つの結果しか得られないようです。どちらも正しい結果です。 1つ目は、EPSG：3857のような投影法を使用して、ロシアの東端を切り取っていないが、地球全体に流れている奇妙なバーが含まれているマップを取得します。 別の予測では、これはわかりますが、ロシアが途切れる問題（少し奇妙に見えると思います）で： これは、使用するShapefileに関係なく複製されるようです。そのため、これは投影法でしょうか。

8 qgis  coordinate-system 

投影の中心を太平洋にシフトするために、陸のポリゴンを分割しています。22子午線上の元のポリゴンをうまく切り取ることができました。カスタムCRSでオンザフライ再投影を実行すると、問題なく見えます。 しかし、実際に同じCRSでポリゴンを保存すると、少しシフトしているように見えます。 私のCRSはこのproj4文字列を使用しています。 +proj=eqc +lon_0=-158 +datum=WGS84 +units=m +no_defs +lon_wrap=-158 これを引き起こしている可能性があるものについてのアイデアはありますか？

8 qgis  coordinate-system  proj 

LeafletのNorth Polar Stereographicプロジェクション（EPSG3995）でWMSレイヤーをサポートしようとしていますが、機能させることができません。 私はProj4Leafletを使用し、GeoServerによって指定された解像度で投影を作成しました（WMSレイヤーはGeoServerによって提供されます。結合された画像を参照してください）。 次のjsfiddleで：https ://jsfiddle.net/gaubert/Lyojcrzo/ 私はそれを実装しようとしましたが、リーフレットマップをズームすると、タイルが適切に配置されていないことがわかりますか？ それを機能させるには何が欠けていますか？変換またはプロジェクトメソッドを実装する必要がありますか？

8 geoserver  coordinate-system  leaflet  wms  proj4js 

1.質問 RのラスターパッケージでprojectRaster（）関数を使用して警告が発生しました。完全に再現可能な例を以下に貼り付けます。 Warning message: In rgdal::rawTransform(projto_int, projfrom, nrow(xy), xy[, 1], : 33940 projected point(s) not finite 私の質問は次のとおりです。このデータは、地上データで作業している場合に修正する必要がある問題ですか？つまり、データは「失われた」ということです。もしそうなら、これは私にとって大きな問題になるでしょう。もしそうなら、私がそれを修正できる方法があるかどうか知っていますか？ 私はこの問題の解決策をオンラインで検索したところ、ここ、ここ、およびここにいくつかの言及が見つかりましたが、この問題に対する適切な答えを提供するものはないと思います。 2.ラスターライブラリを読み込む library(raster) 3.まず、各グリッドセルに定数を使用して、世界の（長緯度）マップを作成します 各グリッドセルに定数を配置して、警告がデータに影響する可能性がある場合の問題を診断できるかどうかを確認しています。 rastertest.longlat<-raster(ncol=360, nrow=180) values(rastertest.longlat)<-c(rep(1,n=180*360)) 4.（長緯度）マップを等面積グリッドに再投影すると、警告メッセージが表示されます rastertest.eck4<-projectRaster(rastertest.longlat, res=c(100000,100000), crs="+proj=eck4",method="ngb", over=T) Warning message: In rgdal::rawTransform(projto_int, projfrom, nrow(xy), xy[, 1], : 33940 projected point(s) not finite このメッセージは基本的に、一部のグリッドセルで再投影が失敗したことを示していると思います。 5.しかし、2つのマップをプロットした場合、この警告はデータに問題を引き起こすようには見えません つまり、プロットされたデータに白いギャップはありません。私の推測では、失われた細胞は非地球上の細胞であり、世界の最上部と最果てです。何か案は？ par(mfrow=c(2,1)) plot(rastertest.longlat, col="blue") …

8 raster  r  coordinate-system  sp  rgdal 

私はTileStacheを使用して、postgisデータソースを使用して独自のベクタータイルを提供しています。まず、ArcMap（Webメルカトル（補助球）に再投影）を使用していたシェイプファイルを再投影し、shp2pgsql（SRID：900913）を使用してそれらをPostgresにロードしました。 この構成ファイルを使用してタイルを生成できます： { "キャッシュ"： { "名前"： "テスト"、 "パス"： "/ tmp / stache"、 "umask"： "0000" }、 「レイヤー」： { 「tpl」： { "許可され​​たオリジン"： "*"、 "投影"： "球状メルカトル"、 「プロバイダー」： { "クラス"： "TileStache.Goodies.VecTiles：Provider"、 "kwargs"：{ 「dbinfo」： { "ホスト"： "ローカルホスト"、 "ユーザー"： "postgres"、 "パスワード"： "postgres"、 "データベース"： "tpl" }、 「クエリ」： { "7"： "SELECT geom AS __geometry __、name、priority FROM isl_roads_sm WHERE …

8 coordinate-system  overlay  tilestache  vector-tiles 

私はインターネット上で、NAD83とWGS84は事実上同等（わずかな楕円体の違いはある）であると主張しています。ただし、測地（WGS84）-> ECEF->測地（NAD83）変換を行い、WGS84およびGRS80楕円体パラメーターのみを使用し、ヘルマート変換を使用しない場合、このような政府支援のオンラインコンバーターの結果を複製できません。私の測地/ ecef変換はEPSGノート7.2に従って行われ、正確性について厳密にテストされています。 したがって、私の質問は次のとおりです。 WGS84をNAD83に変換するためにHelmert変換が必要ですか？ そうするための正規または公式の係数値はありますか？時間の経過とともにNAD83とWGS84のバリアントがあることはわかっていますが、今日使用される係数に興味があります（これはNAD83（2011）とWGS 84（G1674）を意味すると思いますか？）

8 coordinate-system  convert  wgs84  nad83 

私はGISの世界全体に少し慣れていないので、Bing Mapsでポリゴンなどを描画する優れた前進方法を作っていますが、現在は行き詰まっています。私たちのSQL空間データでは、すべての座標値が非常に大きな数値（10進数の前の緯度と経度の6桁と7桁）であるMULTIPOLYGONデータに出くわしました。マルチポリゴンをいくつかのポリゴンに分解するSQLメソッドを見つけましたが、これらの大きな値はBing MapsでもGoogleマップでも機能しません。そこで私は、これらの大きな数値を、45.19167 -93.58328（オンラインマップで機能する）などの通常の緯度/経度の数値として認識されている数値に変換するアルゴリズムを探していました。 そうは言っても、631456.83、3816200.79をオンラインで使用できるものに変換する方法を学ぶために、誰かが私を見せるか、私に大きな方向性を示してくれますか？座標はアリゾナのどこかにあることを知っています。

8 coordinate-system  spatial-database  latitude-longitude 

極地投影を使用して極地（北極または南極）に焦点を当てたWebマップの例を探しています。 このようなWebマッピングアプリケーションに使用できる極座標投影とタイルスキーマは何ですか？

8 coordinate-system  web-mapping  antarctica  arctic 

SRIDが異なる2つのPostgresテーブルがあります。4326と900913です。後者を4326に変換します。最初にSRIDを変更しました。 Select UpdateGeometrySRID('table', 'geomcolumn', 4326). 次に、以下を使用して参照データを変換しました。 update table set geomcolumn = ST_Transform (geomcolumn, 4326). これはうまくいったようです。しかし、TileMillの関連レイヤーのSRS設定をWGS84に変更すると、次のエラーが発生します。 地理的範囲を超えて検出されました。 おそらく変換は機能しませんでしたが、その理由は明らかではありません。

8 postgis  postgresql  coordinate-system 

オーストラリアが北極にある次の例のように、「傾斜した地球」の地図を作成したいと思います。 http://i1048.photobucket.com/albums/s379/laskaris_mods/tilted_earth.jpg 私が使用しているソフトウェア、Geocart 3を使用して、このような.jpegなどの画像形式でマップを再投影できます。ただし、標高データセットをこの方法でnetcdf形式（ETOPO .grdデータ）に再投影するだけです。 「傾斜した地球」の正確な標高データがあります。 これを行うことができるGISソフトウェアはありますか？

8 coordinate-system 

私は、アメリカのシカゴを中心として、正距方位図法として投影される世界の国々のシェープファイルを持っています。英国のエジンバラを中心に予測を変えたい。これは、座標系パラメータの2つの数値を変更するのと同じくらい簡単なはずだと思います... 私が経験しているように見える問題は、QGISが、特定のシェープファイルの座標系パラメーターの完全なproj4コードを表示することを不可能ではないにしても困難にすることです。 これは私がこれまでに試したことです： シカゴを中心とする正距方位図法として投影された世界の国々のシェープファイルを追加 開いたプロパティ、メタデータタブ、proj4パラメーターコードのコピー 設定、カスタムプロジェクション、proj4コードの貼り付けに行って、緯度と経度をシカゴのものからエジンバラのものに変更しました 世界の国の保存されたシェープファイル、新しいカスタムプロジェクションを指定し、マップする新しいファイルを追加 私の新しいファイルはパンゲアの地図のように見え、大陸がすべて押し寄せています。 メタデータタブのproj4コードに表示されているもの以外にも、他のパラメーターが必要だと思います。proj4コードで変更しているのはマップの中心だけですが、私が目にしている変更はそれ以上のものです。私の観察は、複数の独立変数が変化していることを示唆しています。 私のシェープファイルを、それを使って遊んでみたいと思っている人なら誰にでも送りたいです。 おかげで、 ダニエルウルフ環境/地理空間愛好家

8 qgis  coordinate-system 

最近、ogr / gdalに付属するOGRプロジェクションクラスを使用していますが、pyprojが推奨されたので、試してみようと思いました。切り替えるかどうかを判断するために、速度テストを行いました。以下は、2つをテストするために思いついた小さな（ほとんど）再現可能な例です。このテストが完全に公正であるかどうかはわかりませんので、コメントや推奨事項を歓迎します！ 最初にインポートして、平等なプレイフィールドから始めることを確認します。 from pandas import Series # This is what our geometries are stored in from shapely import wkb import functools from shapely.geometry import shape from osgeo import ogr # The following two imports are the important ones from pyproj import Proj, transform from osgeo.osr import SpatialReference, CoordinateTransformation …

8 python  coordinate-system  ogr  testing 

ArcGIS 10でオーバーレイしたい100〜200枚のフィールドグラウンドショット写真があり、写真測量式を使用して何らかの形で開発する必要がある空間情報がありません。カメラは、RTK GPSポールの地上2メートルに取り付けられました。GPSポイントと写真の1対1の関係。精度は大きな問題ではありませんが、少なくとも1メートル以内にある必要があります（これは各写真の視野です）。目的は、使用している座標系での各画像のフットプリントサイズを知ることができるため、スクリプトまたはモデルを使用して各画像を自動ジオリファレンスする方法を開発することです。 私が使用する必要があるもの： 100-200 +グラウンドショットフィールド写真： -camera height 1.228 meters (from tip of gps) -camera angle ~90 degrees -camera focal length 0.006 meters -North orientation GPSポイントシェープファイル（100-200 +レコード; 1レコード= 1ポイント= 1写真）： -XY location for each photo(approximately the centroid of photo) -NAD83 UTM Zone 14N (meters) 個々の写真をジオリファレンスするのに大量の時間を費やすことなく達成するための頭の上の基本的な手順： * 1）いずれかの写真の寸法（メートル単位）を決定します。写真のスケール（PS = f / …

8 arcgis-desktop  coordinate-system  gps  georeferencing  image 

gadmでロシアの地図をプロットしてRいるときに、180度の子午線で問題が発生しました。ロシア地域の一部が個別にプロットされています。次のコードを使用して、プロット上でそれを見ることができます（それは左端であり、部分は右です）。誰でもこの問題を回避する方法を提案できますか？ これが私の質問のコードの短いバージョンです： require(sp) rus<-url("http://www.gadm.org/data/rda/RUS_adm1.RData") print(load(rus)) gadm$regions = as.factor(1:88) spplot(gadm,"regions")

8 cartography  coordinate-system  r 

WGS84にたくさんのポイントがあるデータベースがあります。現在、KDtreeを使用して、NNと範囲クエリのポイントを実行するキャッシュを構築しています。重要な点は、検索半径はメートル単位で提供されることと、緯度/経度はこれらの幾何学的クエリに適したSRSではないことです。 全世界に適用でき、距離を維持できる幾何学的なSRSを探しています。10分の2メートルの誤差は気にしません。

8 coordinate-system  distance  nearest-neighbor