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

私は米国のさまざまな郡をカバーする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を適切に読み取れなかったため、私の回避策は思ったように大雑把であることがわかりました。

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

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

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