我正在使用Bing Maps AJAX API和SQL Server 2008开发一个映射服务 . 我应该使用地理数据或几何数据类型来解决这个问题 . 我研究了很多但是doesen'T找到了一个满意的答案 . 以下是有关该主题的一些链接：
如果我比较两种类型，我会看到以下几点 .
亲地理
-
世界各地的一致距离计算（时间线！）
-
数据库的坐标系与使用Bing Maps API（WGS84）将数据添加到 Map 的坐标系相同
-
精确
反对地理
-
高计算成本
-
数据大小限制在一个半球
-
缺少函数（STConvexHull（），STRelate（），...）
pro几何
-
更快的计算
-
无约束的数据大小
反对地理
- 度数的距离单位（如果我们使用WGS84坐标）
对我来说问题是我不需要快速框架，覆盖范围广（全世界）和高功能 . 所以我更喜欢几何类型 . 几何类型的问题是，我必须将我的数据转换为平面投影（Bing Map使用SRID = 3875），这样我才能获得计算的米 . 但是当我在数据库中使用Bing Maps投影（3875）时，如果我不在 Map 中显示它，我必须将我的数据转换回WGS84 .
我希望每个人都能理解我的问题和英语 .
我将不胜感激任何建议 .
1 回答
你已经对这两种类型之间的差异提供了很好的总结，并且你已经正确地确定了两种明智的选择，无论是地理（4326）还是几何（3857），所以我不太清楚还有什么更多信息 . 可以提供 - 您只需根据您可获得的信息自行做出决定 .
我会说，虽然几何数据类型可能比地理数据类型稍微快一些（因为它依赖于更简单的平面计算，并且可以受益于所讨论区域上的紧密边界框），但这种性能的提高将更多然而，由于您必须取消投影回WGS84纬度/经度以便传回Bing Map ，因此重新投影是一个昂贵的过程 .
您当然可以使用几何数据类型存储WGS84角度坐标，但这实际上是一个黑客，不推荐 - 您几乎肯定会遇到困难 .
所以，我建议使用geography数据类型和WGS84 . 通过仔细的索引调整，您甚至可以获得甚至大型数据集的大多数查询的亚秒级响应时间 . 顺便提一下，SQL Denali中的geography数据类型中的“半球内”规则被取消，因此如果要进行升级，则限制会消失 .