Bing Maps API - SQL - 几何与地理类型

Question

我正在使用Bing Maps AJAX API和SQL Server 2008开发一个映射服务.我应该使用地理数据或几何数据类型来解决这个问题.我研究了很多但是doesen'T找到了一个满意的答案.以下是有关该主题的一些链接:

• SQL 2008地理和几何 - 使用哪些？
• http://www.mssqltips.com/tip.asp?tip=1847
• https://alastaira.wordpress.com/2011/01/23/the-google-maps-bing-maps-spherical-mercator-projection/

如果我比较两种类型,我会看到以下几点.

亲地理

• 世界各地的一致距离计算(时间线!)
• 数据库的坐标系与使用Bing Maps API(WGS84)将数据添加到地图的坐标系相同
• 精确

反对地理

• 计算成本高
• 数据大小限制在一个半球
• 缺少函数(STConvexHull(),STRelate(),...)

专业几何

• 更快的计算
• 无约束的数据大小

反对地理

• 度数的距离单位(如果我们使用WGS84坐标)

对我来说问题是我不需要快速框架,覆盖范围广(全世界)和高功能.所以我更喜欢几何类型.几何类型的问题是,我必须将我的数据转换为平面投影(Bing Map使用SRID = 3875),这样我才能获得计算的米.但是当我在数据库中使用Bing Maps投影(3875)时,如果我不在地图中显示它,我必须将我的数据转换回WGS84.

我希望每个人都能理解我的问题和英语.
我将不胜感激任何建议.

Answer 1

您已经很好地总结了两种类型之间的差异，并且您已经正确识别了两个合理的替代方案：地理（4326）或几何（3857），所以我不太确定还有什么更多信息可以提供 - 您只需根据您可获得的信息自行做出决定。

我想说，虽然几何数据类型可能比地理数据类型稍微快一些（因为它依赖于更简单的平面计算，并且可以受益于相关区域上的紧密边界框），但性能的提高将更多然后，您必须取消投影回 WGS84 纬度/经度才能传回 Bing 地图 - 重新投影是一个昂贵的过程。

您当然可以使用几何数据类型存储 WGS84 角坐标，但这实际上是一种 hack，不推荐 - 您几乎肯定会遇到进一步的困难。

因此，我建议使用地理数据类型和 WGS84。通过仔细的索引调整，即使是大型数据集的大多数查询，您仍然应该能够获得亚秒级的响应时间。顺便说一句，SQL Denali 中的地理数据类型取消了“半球内”规则，因此如果您要升级，该限制就会消失。