回答:
地理フィーチャは、PostGIS 2.2より前のWGS84に常に保存されます。それ以降、lon / latベースの空間参照システムを使用できます。地理的特徴に基づく測定はCRS単位ではなくメートル単位で行われ、PostGISは平面形状ではなく測地計算を使用します。
すべての関数がジオメトリをサポートしているわけではありませんが、ジオメトリとジオグラフィの間でキャストできます。現在の関数リストについては、https：//postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctionsをご覧ください。
大規模なデータベースでは、地理またはジオメトリのいずれかを推奨することは不可能だと思います。それはあなたがあなたのデータで何をしているかに依存します。球体の計算はより複雑なので、地理的特徴の分析は遅くなると思います。また、地理を使用するには、すべてのデータをWGS84に変換する必要があります。
多くの測定を行い、たとえば大きなポリゴンのサイズを比較する必要がある場合、ジオメトリではなく地理を使用するのが理にかなっています。
次の情報が役に立ちました：http : //postgis.net/workshops/postgis-intro/geography.html
このトピックは、「PostGIS in Action」（ISBN：9781935182269）でも説明されています。
私は直感的な「経験則」を使用します...これは迅速な決定に役立ちます。
データベースについて：フィーチャおよび/または空間分析が大陸規模であり、精度（深刻なアプリケーション）が必要な場合は、geographyを使用します。それ以外の場合は、ジオメトリを使用します。すべてのデータベースがほぼ同じ（都市スケール）地域である場合、または精度が必要ない場合など、ジオメトリのみが必要です。@underdarkの推奨講義で
同様のルールを参照してください。
パフォーマンス/精度の バランスに関するニーズについて：ジオメトリは高速です。パフォーマンスが必要で、地理を使用する場合は、最初にベンチマークを実行します。
このページでは、いくつかのキーワードと、精度、パフォーマンス、柔軟性/商品のようなものなどの概念に焦点を当てています。
他の人が記憶しているように、ストアと計算の違いは、地理での球体と幾何学での平面の使用です。
おそらく2020年には、すべてのGISデータベースが同じ標準SRID / EPSG（WGS84の現在の4326コードに相当）に設定されるでしょう。今日、パフォーマンスと機能の制限のため、地理はデフォルトの選択ではありません。
私の意見では、それは「ベストプラクティス」の問題であり、深い技術的/理論的な問題ではありません。
データのエラーを推定した後、テストを行い、結果を比較します。地理の精度の向上はデータのエラーよりも高いですか？ST_Distanceの（持つ関数MAXとAVGアグリゲータは）実験のこの種の主な基準です。
〜100km2（直径〜11km）の都市部におけるベンチマークの例。すべて平面UTM座標系のジオメトリとして格納されています。注：頻繁に使用されるジオメトリ/地理変換から開始します—いくつかの関数が存在せず、ST_BufferやST_Intersectionなどの他の関数は内部的に変換を行うため、頻繁に使用されます。
ベンチ＃1：都市区画を表す〜87000ポリゴンのテーブルで、それぞれに（avg）〜13ポイントのポリゴンがあり、
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS
SELECT gid, the_geom FROM urbanlots; ROLLBACK;
-- time 2080 ms ~ 2.0 s
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS
SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog
FROM urbanlots; ROLLBACK;
-- time 12374 ms ~ 12.4 s ~ 6 * geometry.したがって、geography_time = 6 * geometry_time。
ベンチ＃2：都市ブロックを表す〜3500個のポリゴンがあり、それぞれに（avg）〜50ポイントのポリゴンがあるテーブル：0.6秒対2.7秒、geography_time = 4.5 * geometry_time。
ベンチ＃3：都市通りを表す〜10000行で、それぞれ〜5ポイント。〜0.87s対〜0.36s、geography_time = 2.4 * geometry_time。
ベンチ＃2に戻り、テーブルの作成とクエリの実行、
EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom)
FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
-- time 182 ms ~ 0.2 s
EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog)
FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
-- time 58657 ms ~ 59 s ~ 300*geometry
-- curioselly for only distances, geography=4*geometry結論：小さなタスクと優れたハードウェアの場合、時間は「許容可能な時間」に収束しますが、大きなタスクの場合、考慮すべきパフォーマンス評価があります。
ベンチマークでは、ポイント数を（byごとに）チェックする日々のタスクを実行しますST_NPoints...これは、地理には存在しない操作の例であり、キャストが必要です。「地理/幾何学のキャスト」は、プログラマー、マスターなどにとって厄介なタスクです。
SQLおよびPL / pgSQL関数のライブラリを再利用する場合、地理には適応が必要です。また、コードを最適化する場合、または多くの中間変換での精度の問題を回避する場合は、地理的な機能を備えた組み込み関数の完全なセットがないことが別の問題です。地理学のためのプログラムは、簡単な作業ではありません。
Mapserverのような集中的なユーザーがいない通常でない需要の場合、唯一の（PostGIS）作業が入力データを処理し、処理されたデータをいつでも（数時間または数日）返す場合、経験則は「地理を使用する快適です！」（上記の「柔軟性/商品」を参照）。そうでない場合は、通常のルールを確認してください。
注：もちろん、（通常ではない）タスクがPostGISからMapserverにデータを表示するだけで、入力データと同じ（ジオメトリまたは地理）を保持するためにプロセスを必要としない場合は、より適切な決定です。
コンテキストに：私は、データの一元化が地理が優れている別のタスクであると信じ多様性 ...入力フォーマットと参照系のはいつもある、など地理によって強制されるような標準の使用は、有益である設定より規約があります集中化とデータ交換がビジネスの焦点である場合の良い原則です（Googleマップをご覧ください！）。
ST_GeomFrom*、変換機能ST_As*は非常に便利なようです。
最も大きな違いは、地理タイプでは、幾何タイプのフィーチャで行われる計算で使用される平面ではなく、地球を表す球で計算が行われることだと思います。
ドキュメントはかなり良いです：http : //postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography
ジオグラフィタイプが最近追加されたため、サポート/実装される機能が少なくなりました。
たぶん、この機能と答えは役に立たないかもしれませんが、ジオメトリを操作する利点の1つは、空間参照なしで作業できることです（つまり、SRIDを-1に設定）。
現在、私は空中LiDARデータをフィルタリングするアプリケーションで作業しています。そのデータソースにはPostGISデータベースがあり、ファーストクラスの空間インデックス（RTree over GiST）を提供し、大量のデータを問題なく処理します。そのアプリケーションは、地理的特徴の操作または分析を必要としないため、SRIDは必要ありません。そのため、オーバーヘッドを回避できます。