QGISが.prjファイルからCRSを検出しないのはなぜですか?


9

私は米国のさまざまな郡をカバーする1 kmの六角形グリッドをpostgreSQL / postGISデータベースに多数持っています。各グリッドにはCRS EPSG:3857があり、countiesレイヤーにはEPSG:3857があります。QGISで郡のグリッドを表示すると、すべてが壮大に見えます。

しかし...これらのグリッドを同僚と共有するために、ogr2ogrを使用してそれらをシェープファイルにエクスポートする必要がありました。これらをQGISで表示すると、各グリッドは約20 kmほどナッジされたように見え、QGISは自動的にCRSをEPSG:3395(プロジェクトのCRSではない)に設定します。

QGISから postGISテーブルをシェープファイルとしてエクスポートすると、.prjファイルはogr2ogrエクスポートされたシェープファイルとまったく同じに見えますが、postGISエクスポートされたテーブルは正しく表示されます。QGIS からシェープファイルをエクスポートすると、QGISが.qpjファイルを作成することに気付いたので、QGISが.prjを無視し、代わりに.qpjを探しているという結論に達しました。.qpjがないと.prjを読み取れないのはなぜですか?他のシェープファイル(米国国勢調査のものなど)には.qpjがありませんが、QGISはこれらを正しく表示します。

default.qpjを保存し、ogr2ogrを使用してエクスポートするすべてのファイルに対してこれから新しい.qpjを作成することで回避策を考え出しましたが、EPSG:3857でしか機能しないため、これは煩雑で、再現性がないようです。

補足:QGIS 2.0.1を使用しています。

編集:

これが私が使用したogr2ogrコマンドです。

ogr2ogr -f "ESRI Shapefile" /home/matt/data/hex_grid_1 PG:'dbname=mydb user=matt' hex_grid_1

.prjの内容:

PROJCS ["WGS_84_Pseudo_Mercator"、GEOGCS ["GCS_WGS_1984"、DATUM ["D_WGS_1984"、SPHEROID ["WGS_1984"、6378137,298.257223563]]、PRIMEM ["Greenwich"、0]、UNIT ["Degree"、0.01745329251994J3TION] ["メルカトル"]、PARAMETER ["central_meridian"、0]、PARAMETER ["false_easting"、0]、PARAMETER ["false_northing"、0]、UNIT ["Meter"、1]、PARAMETER ["standard_parallel_1"、0.0] ]

.qpjの内容:

PROJCS ["WGS 84 /疑似メルカトル"、GEOGCS ["WGS 84"、DATUM ["WGS_1984"、SPHEROID ["WGS 84"、6378137,298.257223563、AUTHORITY ["EPSG"、 "7030"]]、AUTHORITY [" EPSG "、" 6326 "]]、PRIMEM ["グリニッジ "、0、AUTHORITY [" EPSG "、" 8901 "]]、UNIT [" degree "、0.0174532925199433、AUTHORITY [" EPSG "、" 9122 "]]、AUTHORITY ["EPSG"、 "4326"]]、PROJECTION ["Mercator_1SP"]、PARAMETER ["central_meridian"、0]、PARAMETER ["scale_factor"、1]、PARAMETER ["false_easting"、0]、PARAMETER ["false_northing" 、0]、UNIT ["メートル"、1、AUTHORITY ["EPSG"、 "9001"]]、AXIS ["X"、EAST]、AXIS ["Y"、NORTH]、EXTENSION ["PROJ4"、 "+ proj = merc + a = 6378137 + b = 6378137 + lat_ts = 0.0 + lon_0 = 0。0 + x_0 = 0.0 + y_0 = 0 + k = 1.0 + units = m + nadgrids = @ null + wktext + no_defs "]、AUTHORITY [" EPSG "、" 3857 "]]

編集

この問題は、すべてのスクリプトでEPSG:3857をEPSG:2163に変換することで解決しました。グリッドが元々postgreSQLテーブル(EPSG:3857)からロードされたときにQGISで正しく表示されたため、問題が何であるかはまだわかりません。

同僚がArcGISでファイルを使用できず、.prjまたは.qpjを適切に読み取れなかったため、私の回避策は思ったように大雑把であることがわかりました。


ogr2ogrコマンドを追加できますか?
alphabetasoup

.prjファイルと.qpjファイルの両方の内容も投稿できますか?
mkennedy 2016年

1
その「補助球上のWGS84 Webメルカトル図法」en.wikipedia.org/wiki/Web_Mercatorに制限された機能があるかもしれません。球面投影に対するデータム地理座標。
huckfinn 2016年

@huckfinnスクリプトですべてのEPSG:3857をEPSG:2163に変更しました。これで問題が解決しました。EPSG:3857を使用してpostgreSQLテーブルからロードしたときにグリッドがすべて正しく表示されるため、これがなぜかはまだわかりません。先端をありがとう。
2016年

回答:


4

このEPSG:3857定義は、Googleが最新のGISソフトウェアに発明した予測を取得するための汚いハックです。「通常の」投影では使用されない球と楕円体の組み合わせです。残念ながら、すべてのソフトウェアはそれを適応させるために別の方法を使用しています。

QGISは.qpjファイル、ARCGISは.prjファイルのWKT、GDALはproj.4定義を使用します。.qpjファイルは、proj.4定義をWKT定義に組み込みます。

このような問題に対処する最も安全な方法は、Googleメルカトルを回避することです。ローカルのState Plane、UTM、または一部の大陸全体のLambertまたはAlbersの予測をより適切に使用できます。


知ってよかった。ご回答有難うございます。ただし、ogr2ogrを使用してEPSG 2163でシェープファイルをエクスポートすると、.qpjは作成されませんが、QGISはそれを適切に読み取ります。したがって、.qpjがない場合、QGISが.prjから情報を読み取ると想定しています。また、状態平面の投影は1つの状態でのみ動作する場合はうまく機能しますが、私のスクリプトは多くの州から郡のfipsコードを取得するため、私の場合は状態平面は実用的ではありません。
2016年

1
QGISは通常、.prjファイルで問題なく機能しますが、他のソフトウェアからのWorld Merctaor投影ファイルでは機能しません。最適なCRSは常に調査領域のサイズに依存します。EPSG 2163はあなたのタスクに問題ないはずです。
AndreJ 2016年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.