SQL Server GEOGRAPHY_GRID x & y 范围

发布于 2024-10-04 10:23:19 字数 466 浏览 1 评论 0原文

我有一张表需要记录全世界的地理点(经度、纬度)。输入数据是传统的纵向和纵向数据。纬度(-180、-90、180、90)。

我创建了一个地理专栏并想为其建立索引。然而,有很多选择,MSDN 并未指出最佳实践。我有以下问题:

  1. 我认为 GRIDS = (LEVEL_1 = HIGH, LEVEL_2 = HIGH, LEVEL_3 = HIGH, LEVEL_4 = HIGH) 最适合网格。这将在纬度 ≈ 611.5m 处产生最大可能的分辨率。我见过其他选项的例子。什么是最好的?
  2. 由于我只记录点,我认为 CELLS_PER_OBJECT = 1 是正确的吗?
  3. x 和 x 的最小到最大范围是多少? GEOGRAPHY_GRID 的y?参见#4。
  4. 参考上面的#3,我是否需要将传统的纵向和纵向转换为纬度(-180、-90、180、90)数据到 GEOGRAPHY_GRID 使用的任何范围以便正确使用网格?

I have a table that needs to record geographical points (long, lat) for the whole world. The input data is traditional longitudinal & latitudinal (-180, -90, 180, 90).

I created a geography column and want to index it. However, there are many options and MSDN doesn't indicate best practices. I have the following questions:

  1. I assume GRIDS = ( LEVEL_1 = HIGH, LEVEL_2 = HIGH, LEVEL_3 = HIGH, LEVEL_4 = HIGH) is best for grids. This would create the max possible resolution at latitude ≈ 611.5m. I have seen example with other options. What is best?
  2. Since I am recording only points, I assume CELLS_PER_OBJECT = 1 is correct?
  3. What is the min to max range for x & y of GEOGRAPHY_GRID? See #4.
  4. With reference to #3 above, would I need to convert the traditional longitudinal & latitudinal (-180, -90, 180, 90) data to whatever range GEOGRAPHY_GRID uses so as to properly use the grids?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

最偏执的依靠 2024-10-11 10:23:19

1.) 和 2.) 需要记住的重要一点是,相同的网格不仅用于对创建索引的列中的数据进行细分,还用于您用来测试的任何查询参数该数据反对。
考虑以下查询:

SELECT * FROM Table WHERE GeomColumn.STIntersects(@MyPoly) = 1

假设您已在 GeomColumn 上创建了空间索引,则相同的网格将应用于 @MyPoly,以便对结果。因此,您不仅可以根据表中的内容选择网格设置,还可以选择将针对该数据运行的查询示例的类型。实际上,根据您的数据,“最佳”是非常主观的。我总是建议您从“中”、“中”、“中”、“中”开始,然后尝试从那里调整它,看看根据经验测试是否可以获得更好的性能。

3.) 和 4.) 您没有为地理数据类型设置边界框 - 所有地理索引都隐式假定覆盖整个地球。这就是几何通常是比地理执行速度更快的数据类型的原因之一,因为几何索引的单元格可以在有限的地理区域内提供更高分辨率。

1.) and 2.) The important thing to bear in mind is that the same grid is used not only for tessellating the data in the column on which the index is created, but also for whatever the query parameter you're using to test that data against.
Consider the following query:

SELECT * FROM Table WHERE GeomColumn.STIntersects(@MyPoly) = 1

Assuming that you've created a spatial index on GeomColumn, then the same grid will be applied to @MyPoly in order to perform a primary filter of the results. So, you don't just choose a grid setting based on what's in your table, but also the sort of query sample that you'll be running against that data. In practice, what is "best" is very subjective based on your data. I'd always recommend you start at MEDIUM, MEDIUM, MEDIUM, MEDIUM, and then try adjusting it from there to see if you get better performance based on empirical tests.

3.) and 4.) You don't set a bounding box for the geography datatype - all geography indexes are implicitly assumed to cover the entire globe. That's one of the reasons that geometry is generally a faster-performing datatype than geography, because the cells of a geometry index can provide higher resolution over a limited geographic area.

阳光下的泡沫是彩色的 2024-10-11 10:23:19

我找到了 3、4 的答案:SRID 4326 是 (-180.0000, -90.0000, 180.0000, 90.0000)

I found the answer to 3, 4: SRID 4326 is (-180.0000, -90.0000, 180.0000, 90.0000)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文