我的公司使用geometry（the_geom）数据类型存储地理空间数据。

我最近熟悉geography（the_geog）数据类型的概念，据我所知，它SRID与几何一起存储。

geography和之间geometry有什么区别，在大型数据库中使用其中之一有什么好处？

地理要素始终存储在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）中也介绍了该主题。

我使用直观的“经验法则” ...对于快速做出决定非常有用，

• 关于您的数据库：如果要素和/或空间分析具有大陆规模，并且需要精确（严重的应用程序），请使用地理。否则使用几何：当所有数据库都处于相同（城市规模）区域时，或者您不需要精度等，则仅需要几何。
  在@underdark的建议讲座中可以看到类似的规则。

• 关于性能/精度 平衡方面的需求：几何更快；如果您需要性能并考虑使用地理位置，请先进行基准测试。

关键概念

在此页面上，我们看到了一些关键词，并关注了一些概念：精度，性能以及诸如使用灵活性/商品性之类的东西。

正如其他人所记住的，区别在于存储和计算，是在地理上使用球体和在几何上使用平面：

• 球体（地理）更好，更精确。请参阅洛杉矶/巴黎示例。
• 地理的演变：正如@DavidF所说，“地理类型是最近添加的，因此支持/实现的功能较少”。

也许到2020年，所有GIS数据库都将设置为相同的标准SRID / EPSG（相当于WGS84的当今4326代码）。由于性能和功能限制，今天地理不是默认选择。

讨论区

我认为这是“最佳实践”的问题，而不是深层的技术/理论问题。

精确

在估计了数据上的误差之后，请进行测试并比较结果：地理精度所获得的精度要高于数据误差？的ST_Distance函数（MAX和AVG聚合）是在这样的实验的主要参考。

性能

在平面UTM坐标系中，约100 km2（直径约11 km）的城市中的基准示例（全部以几何形式存储）。注意：从经常使用的几何/地理转换开始-频繁发生是因为某些函数不存在，而另一些函数（例如ST_Buffer和ST_Intersection）在内部进行转换。

基准＃1：一张具有约87000个多边形的表格，这些多边形代表城市地段，每个多边形的平均点数为（平均）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。

Bench＃2：一张表，其中约有3500个代表城市街区的多边形，每个多边形的平均点数约为50分：0.6s与2.7s，geography_time = 4.5 * geometry_time。

基准＃3：代表城市街道的10000条线，每条都有5分。〜0.87s与〜0.36s，geography_time = 2.4 * geometry_time。

回到Bench＃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

结论：对于少量任务和良好的硬件，时间收敛于“可接受的相同时间”，但是对于大型任务，则需要考虑性能等级。

灵活性/商品

在基准测试中，我每天执行一项任务，检查点数（ST_NPoints...）。这是地理上不存在的操作示例，需要进行转换。“地理/几何转换”对于程序员，大师等而言是一项烦人的任务。

当重用SQL和PL / pgSQL函数库时，地理位置需要进行调整。而且，如果您想优化代码或避免大量中间转换带来的精度问题，那么缺少地理区域的完整内置函数是另一个问题。地理计划并非易事。

仅处理，数据交换等

对于非常规需求，没有像Mapserver这样的密集型用户，当您唯一的（PostGIS）工作是处理输入数据并在任何时间（例如几小时或几天）返回处理后的数据时，经验法则是“如果您需要很舒服！” （请参阅上面的“灵活性/商品”）。如果不是，请检查常规规则。
注意：当然，如果您的（非常规）任务只是显示从PostGIS到Mapserver的数据，而无需进行处理，以保持输入数据的相同（几何或地理），则是更好的决策。

我认为，数据大集中是另一个任务的地理范围是更好的：在上下文中在多元化的输入格式和参考系统往常一样，使用标准，如由地理强制执行的，是有益的...... 约定优于配置是集中化和数据交换是业务重点时的一个好原则（请参阅Google Maps！）。

我认为最显着的区别是，对于地理类型，计算是在代表地球的球体上进行的，而不是在对几何类型要素进行计算时所使用的平面。

该文档非常好：http : //postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography

地理类型是最近添加的，因此支持/实现的功能较少。

也许您发现此功能（并没有答案）没有用，但是使用几何图形的优点之一是您可以在没有任何空间参考的情况下进行工作（即SRID设置为-1）。

目前，我正在一个用于过滤机载LiDAR数据的应用程序中，该数据库的数据源包括一个PostGIS数据库，该数据库提供了一流的空间索引（RTree over GiST），并且可以处理大量数据而不会出现问题。由于该应用程序不需要操纵或分析地理特征，因此不需要SRID，从而避免了可能带来的开销。