为什么多边形在 ST_WITHIN 上可以拥有的点数有限制？
Why is there a limitation on the number of points a polygon can have on ST_WITHIN?
我们正处于十字路口，我们需要决定是否将我们的 GeoSpatial 数据存储在 DocumentDB 或 SQL Azure 中。根据this article，查询中ST_WITHIN函数的多边形参数最多可以包含256个点。当我们绘制大陆、国家、states/provinces 等地图时，我们的数据可能包含具有数百万个点的多边形。我们需要能够对所有这些多边形使用 ST_WITHIN。文章还提到我们可以通过联系 Azure 支持来调整该限制。
为什么首先要有这个限制？如果支持确实取消了限制，我们是否会降低 DocumentDB 的分数？
对您的问题的简短回答是肯定的，他们担心您会使 DocumentDB 下降超过 256 分。以前只限16分，最近改成了256分。也许他们将来会再次提出来。我们 运行 遇到了类似的问题，多边形具有超过 1,000 个点。最后，我们决定使用 Sql Server 进行多边形搜索，然后使用从 Sql Server 提炼的数据从 DocumentDB 中拉取相关数据。
问题在于 DocumentDB 资源在客户之间共享，因此您 运行 针对 DocumentDB 的所有操作都必须由请求单元管理。这样一来，任何客户都无法通过大量查询使系统崩溃。我不知道如何通过在数百万个点上使用 ST_WITHIN 来计算请求单位，但我的猜测是即使在 S3 层上，它也可能会突破允许的 2500 个请求单位的限制。因此，即使他们将 256 点提高到 100 万点，您的查询也可能无法完成，因为它太昂贵了。所以我建议您使用 Sql Azure。这就是我们的决定，而且效果很好。
如果您想在 DocumentDB 中完成所有操作（而不是添加 SQL Azure 之类的东西），您可以使用 ST_DISTANCE 来缩小列表范围以获取候选者和然后 运行 相当于 ST_WITHIN 客户端（光线投射算法简单快速）。该技巧涉及存储关于每个多边形的非规范化元数据，即中心点（中心点的精度不重要）和使用该中心点的最大半径。然后，如果您的点与中心之间的距离减去最大半径小于零，则它在候选列表中。它工作起来很有魅力，并且通过一些精心设计的索引设计表现出色。
需要担心的一件事是多边形与自身相交的情况。您将相交的 space 视为多边形外部还是内部？我们有一个讨厌的错误，花了很长时间才弄清楚，它归结为一个自相交的多边形。无论是自己实现算法还是使用数据库自带的"within"函数都存在这个问题。
我们正处于十字路口，我们需要决定是否将我们的 GeoSpatial 数据存储在 DocumentDB 或 SQL Azure 中。根据this article，查询中ST_WITHIN函数的多边形参数最多可以包含256个点。当我们绘制大陆、国家、states/provinces 等地图时，我们的数据可能包含具有数百万个点的多边形。我们需要能够对所有这些多边形使用 ST_WITHIN。文章还提到我们可以通过联系 Azure 支持来调整该限制。
为什么首先要有这个限制？如果支持确实取消了限制，我们是否会降低 DocumentDB 的分数？
对您的问题的简短回答是肯定的，他们担心您会使 DocumentDB 下降超过 256 分。以前只限16分，最近改成了256分。也许他们将来会再次提出来。我们 运行 遇到了类似的问题，多边形具有超过 1,000 个点。最后，我们决定使用 Sql Server 进行多边形搜索，然后使用从 Sql Server 提炼的数据从 DocumentDB 中拉取相关数据。
问题在于 DocumentDB 资源在客户之间共享，因此您 运行 针对 DocumentDB 的所有操作都必须由请求单元管理。这样一来，任何客户都无法通过大量查询使系统崩溃。我不知道如何通过在数百万个点上使用 ST_WITHIN 来计算请求单位，但我的猜测是即使在 S3 层上，它也可能会突破允许的 2500 个请求单位的限制。因此，即使他们将 256 点提高到 100 万点，您的查询也可能无法完成，因为它太昂贵了。所以我建议您使用 Sql Azure。这就是我们的决定，而且效果很好。
如果您想在 DocumentDB 中完成所有操作（而不是添加 SQL Azure 之类的东西），您可以使用 ST_DISTANCE 来缩小列表范围以获取候选者和然后 运行 相当于 ST_WITHIN 客户端（光线投射算法简单快速）。该技巧涉及存储关于每个多边形的非规范化元数据，即中心点（中心点的精度不重要）和使用该中心点的最大半径。然后，如果您的点与中心之间的距离减去最大半径小于零，则它在候选列表中。它工作起来很有魅力，并且通过一些精心设计的索引设计表现出色。
需要担心的一件事是多边形与自身相交的情况。您将相交的 space 视为多边形外部还是内部？我们有一个讨厌的错误，花了很长时间才弄清楚，它归结为一个自相交的多边形。无论是自己实现算法还是使用数据库自带的"within"函数都存在这个问题。