PostGIS地理和几何类型的优缺点是什么？

#1 楼

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

#2 楼

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


关于您的数据库：如果要素和/或空间分析具有大陆规模，并且需要精确（严重的应用程序）使用地理。否则使用几何：当所有数据库都处于相同（城市规模）区域时，或者您不需要精度等时，则仅需要几何。在@underdark的建议演讲中，请参见类似的规则。如果您需要性能并考虑使用地理位置，请先进行基准测试。



键概念
在此页面上，我们看到一些关键字和专注于一些概念：精度，性能以及诸如使用的灵活性/商品性。
正如其他人所记住的，存储和计算的区别在于在地理上使用球体和在几何上使用平面：

范围（地理）更好，更精确。请参阅洛杉矶/巴黎的示例。
地理的演变：正如@DavidF所说，“地理类型是最近添加的，因此支持/实现的功能较少”。到2020年，所有GIS数据库都将设置为相同的标准SRID / EPSG（相当于WGS84的当今4326代码）。
由于性能和功能限制，今天的地理不是默认选择。 br />我认为这是“最佳实践”的问题，而不是深层次的技术/理论问题。
精度
估计数据误差后，进行测试并比较结果：精度地理收益高于数据误差？ ST_Distance函数（带有MAX和AVG聚合器）是此类实验的主要参考。
性能
在平面UTM坐标系中，约100 km2（直径约11 km）的城市中的基准示例（全部以几何形式存储）。注意：从经常使用的几何/地理转换开始-频繁发生是因为某些功能不存在，而另一些功能（例如ST_Buffer和ST_Intersection）则在内部进行转换。含（平均）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个代表城市街区的多边形的表格，每个多边形具有（平均）〜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！）。

#3 楼

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

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

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

#4 楼

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

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