为什么多边形在ST_WITHIN上的点数有限制？

Question

我们正处于交叉路口，我们需要决定是否要将我们的GeoSpatial数据存储在DocumentDB或SQL Azure中。根据{{​​3}}，查询中ST_WITHIN函数的polygon参数最多可包含256个点。我们的数据可能包含数百万个点的多边形，因为我们正在映射大陆，国家，州/省等。我们需要能够对所有这些多边形使用ST_WITHIN。该文章还提到我们可以通过联系Azure支持来调整该限制。

为什么这个限制首先出现？如果支持确实消除了限制，那么我们是否会将DocumentDB降低到这么多分数？

Answer 1

如果您想在DocumentDB中完成所有操作（而不是添加类似SQL Azure的内容），您可以使用ST_DISTANCE缩小列表的方法来获取候选项，然后运行等效于ST_WITHIN客户端（ray铸造算法简单快速）。技巧涉及存储关于每个多边形的非规范化元数据，即中心点（中心点的准确性不严格）和使用该中心点的最大半径。然后，如果您的点与中心之间的距离减去最大半径小于零，则它位于候选列表中。它的工作方式就像一个魅力，并且具有一些细致的索引设计。

要担心的是多边形与自身相交的条件。您是否将交叉空间视为多边形外部或其内部？我们有一个令人讨厌的错误，需要永远弄明白，它归结为一个自相交的多边形。无论您是实现自己的算法还是使用数据库的本机“内部”函数，都存在此问题。

Answer 2

对你的问题的简短回答是肯定的，他们担心你会使DocumentDB下降超过256分。过去仅限于16分，但最近他们将其改为256分。也许他们将来会再次提出它。我们遇到了类似的问题，多边形超过1,000点。最后，我们决定使用Sql Server进行多边形搜索，然后使用从Sql Server中精炼的数据从DocumentDB中提取相关数据。

问题是DocumentDB资源是在客户之间共享的，因此您针对DocumentDB运行的所有操作都必须由请求单元管理。这样，没有一个客户可以通过大量查询来关闭系统。我不知道如何计算在数百万点上使用ST_WITHIN的请求单位，但我的猜测是，即使在S3层，它也可能会推动允许的2500个请求单位的限制。因此，即使他们将256点提升到100万点，您的查询也可能无法完成，因为它太昂贵了。所以我建议你选择Sql Azure。这就是我们所确定的并且表现出色。