PostGIS提供了哪些确切的功能，使其有必要作为PostgreSQL的扩展而存在？
为什么我们不都使用PostgreSQL的空间功能？
#1 楼
如果您将宇宙重新缠绕到2001年初，不仅让PostGIS的发明者看到未来，而且让PgSQL的PSC看到未来，那么PostGIS可能是PgSQL上的一系列补丁。但是至少，如果我们最初是作为内核的补丁开始的，那么我们会遇到的第一件事是：核心PgSQL区域不支持漏洞，但是GIS模型
核心PgSQL会说：“不，当然不是，区域具有现有的易于理解的语义，我们不能像这样进行向后不兼容的更改，例如那样。”
作为非核心开发人员，PostGIS能够淘汰多年的每月和每月6个版本，而PgSQL核心随年度和更长的版本而减少。由于我们在项目中拥有提交权限，因此我们还可以随时添加所需的任何功能，但是在PgSQL中获得提交权限需要很长时间。
在PostGIS展示足够的外部性能时PgSQL内核看重并自言自语的价值，“呵呵，作为一个附加功能可以很好地包含在内核中”，已经有太多的代码与PgSQL有如此不同的标准和样式（更不用说在不兼容的情况下了）许可），合并的想法实际上是不可能的。
相反，PostGIS已成为“真正的大型复杂扩展”的典范示例，该扩展帮助PgSQL保持模块化和可扩展性。当核心PgSQL评估某些更改时，经常会问到“这将对PostGIS产生什么影响”。这也是一件好事，也许还不如PostGIS作为核心的一部分那么好，但是足够好。
还有其他原因，例如PgSQL核心讨厌的一长串依赖关系，通常，他们本来希望不断改善的代码一致性和API清洁度较低。即使从概念上来说，PostGIS对于PgSQL来说也是一个巨大的障碍，无法一口吞下。
评论
另外... PostGIS是C ++。这将是PostgreSQL合并的最佳选择，无论是否应该如此。依赖关系也会完全阻止它-GDAL？哈！我什至不能让内核同意依赖Perl> 5.8.0。即使您拥有承诺权利，开发速度仍然很慢；提交者不仅可以免费获得树上所有推崇的东西，还必须经过代码审查，并在数月或数年之内获得重大更改。有一些代码质量上的好处，但它肯定不会很快发展。
–克雷格·林格（Craig Ringer）
17年1月6日4:45
核心Pg不断重塑事物是一个特别的问题，以避免依赖更多的外部库。因为这意味着在$ dead_architecture上带有$ weird_vendor_compiler的$ ancient_unix_42必须支持它，所以所有buildfarm成员都需要更新，等等。我想这是成熟和稳定的问题之一。
–克雷格·林格（Craig Ringer）
17年1月6日在4:48
@CraigRinger为什么您认为PostGIS是C ++？那是侮辱:-)
–尼克拉斯·阿文（NicklasAvén）
17年1月6日在8:52
是...不是吗？我可以发誓。但可以肯定的是，它看起来并不像它。我的错。无论如何，我实际上都喜欢（适度和克制）使用C ++。
–克雷格·林格（Craig Ringer）
17年1月6日在9:37
在一段时间内，PostGIS拥有一些C ++，以便与GEOS绑定。一旦GEOS添加了自己的C API，这些部分将被删除，而PostGIS成为“纯”C。
– Paul Ramsey
17年1月6日在13:13
#2 楼
事实并非如此，PostgreSQL不支持Spatial数据类型。它支持几何类型。这些对于某些事情来说是完美的，但是它们与现实世界的坐标系统完全分开。本机类型没有空间参考系统ID / SRSID。
永远不能重新投影。
即使是椭球体，它们提供的功能也非常有限。
它们不是标准化的。
它们不提供GIST索引。
更新
关于索引问题，它在常见问题解答
为什么不支持PostgreSQL R-Tree索引？
早期版本的PostGIS使用PostgreSQL R-Tree索引。但是，
自版本0.6起，PostgreSQL R-Trees已被完全丢弃，
，并且通过R-Tree-over-GiST方案提供了空间索引。
我们的测试表明原生R-Tree和GiST的搜索速度可与之媲美。本机PostgreSQL R-Tree有两个限制，这使它们不适合与GIS功能一起使用（请注意，这些
限制是由于当前的PostgreSQL本机R-Tree
实现，而不是R-一般的树概念）：
PostgreSQL中的R-Tree索引不能处理大于8K的特征。 GiST索引可以使用“有损”技巧代替要素本身的边界框。
PostgreSQL中的R-Tree索引不是“空安全的”，因此在包含空几何的几何列上建立索引将失败。 [GiST索引是空安全的]
评论
您能否扩展到最后一点-有关GiST索引的那一点？ PostgreSQL提供了R-Tree，现在通过GiST索引提供了R-Tree，所以我对此感到困惑。
–泽鲁诺
17年1月6日，0：47
已使用常见问题解答中的直接文字进行了更新。
–埃文·卡洛尔（Evan Carroll）
17年1月6日，0：49
GiST API是access / gist.h提供的PostgreSQL。您可以在此处查看它在PostGIS中的使用情况
–埃文·卡洛尔（Evan Carroll）
17年1月6日在2:22
尽管PostGIS确实具有自己的rtree-on-gist实施，但它与PgSQL所用的那种对图形对象的核心支持非常相似，原因很简单，最初我们复制了它们。
– Paul Ramsey
17年1月6日在4:31
@Zeruno，不，在PgSQL中修改rtree分隔符不会更改PostGIS的行为，因为我们在gserialized_gist_picksplit_2d（）中拥有自己的分隔符。您不会认为它与PgSQL并没有什么不同。
– Paul Ramsey
17年1月7日在23:35
#3 楼
PostGIS是PostgreSQL对象关系数据库的空间数据库扩展器。它增加了对
地理对象的支持，允许在SQL中运行位置查询。
SELECT superhero.name
FROM city, superhero
WHERE ST_Contains(city.geom, superhero.geom)
AND city.name = 'Gotham';
除了基本的位置识别功能外，PostGIS还提供了许多功能
在其他竞争性空间数据库（例如Oracle
Locator / Spatial和SQL Server）中很少发现。有关更多详细信息，请参见PostGIS功能列表。
PostGIS功能列表还扩展了这些功能：
PostGIS添加了其他类型（几何，地理，栅格等）到PostgreSQL数据库。它还添加了适用于这些空间类型的函数，运算符和索引增强功能。这些附加功能，运算符，索引绑定和类型增强了核心PostgreSQL DBMS的功能，使其成为一种快速，功能丰富且健壮的空间数据库管理系统。
功能列表
PostGIS 2+系列提供：
矢量和栅格数据的处理和分析功能，可用于拼接，切块，变形，重新分类和收集/去离子
SQL栅格地图代数用于细粒度栅格的强大功能
矢量和栅格数据的空间重投影SQL可调用函数支持通过命令行和GUI导入/导出ESRI shapefile矢量
数据打包的工具，并通过其他第三方开放源代码工具支持更多的
格式
打包的命令行，用于从许多标准格式导入栅格数据：GeoTiff，NetCDF，PNG，JPG
渲染和导入支持标准文本格式（例如KML，GML，使用SQL的GeoJSON，GeoHash和WKT
以各种标准格式呈现栅格数据GeoTIFF，PNG，JPG，
NetCDF，仅举几例使用SQL
无缝的栅格/矢量SQL可调用函数，用于按几何区域挤出像素值，按区域运行统计信息，按几何裁剪栅格，以及对栅格进行矢量化3D对象支持，空间索引和函数网络拓扑支持打包的Tiger
加载程序/ Geocoder /反向Geocoder /利用美国人口普查Tiger数据
此外，本文中已经提到的要点/部分。如PostGIS网站上所述，我将添加它的工作方式
由于PostGIS是C语言的，因此它可以利用C和
C ++中的其他库，并且这样做自由地。 PostGIS取决于：
GEOS用于许多几何处理算法
Proj.4用于坐标重投影功能
GDAL用于栅格处理和格式支持
用于XML解析的LibXML2
用于JSON解析的JSON-C
SFCGAL用于扩展的3D支持和附加的地理处理算法
评论
PostGIS提供了这些空间数据类型，运算符和索引...不，他在谈论本地PostgreSQL几何类型。
简短的答案是，PostGIS（现在）的功能是PgSQL类型的10倍。长答案涵盖了以下问题：“为什么要开发新类型，而不仅仅是改进已经存在的类型”。
Java Spring框架也发生了同样的事情。 Java具有缺陷/缺失功能。 Spring修复了许多Java缺陷并添加了有用的功能。 Java复制了Spring的修订+功能。人们然后问为什么春天存在...