I’m developing a Mapping Service with Bing Maps AJAX API and SQL Server 2008. The question which appears to me is should I use the geography or geometry data type. I researched a lot but doesn’t found a satisfactory answer. Here are some links about the topic:
- SQL 2008 geography & geometry – which to use?
- http://www.mssqltips.com/tip.asp?tip=1847
- https://alastaira.wordpress.com/2011/01/23/the-google-maps-bing-maps-spherical-mercator-projection/
If I compare the two types I see the following points.
pro geography
- consistent distance calculation around the world (time line!)
- the coordinate system of the database is the same as the one which is used to add data to a map with the Bing Maps API (WGS84)
- precise
contra geography
- high computational costs
- data size constrained to one hemisphere
- missing functions (STConvexHull(), STRelate(),…)
pro geometry
- faster computation
- unconstrained data size
contra geography
- distance units in degree (if we use WGS84 coordinates)
The problem for me is that I don’t need a fast framework, a great coverage (the whole world) and high functionality. So I would prefer the geometry type.
The problem with the geometry type is, that I have to transform my data into a flat projection (Bing Map use SRID=3875), so that I get meters for the calculation. But when I use the Bing Maps projection (3875) in the database I have to transform my data back to WGS84 if I won’t to display it in the map.
You’ve provided quite a good summary of the differences between the two types, and you’ve correctly identified the two sensible alternatives to be either geography(4326) or geometry(3857), so I’m not quite sure what more information anyone can provide – you just need to make the decision yourself based on the information available to you.
I would say that, although the geometry datatype is likely to be slightly quicker than the geography datatype (since it relies on simpler planar calculations, and can benefit from a tight bounding box over the area in question), this increase in performance will be more than offset by the fact that you’ll then have to unproject back to WGS84 lat/long in order to pass back to Bing Maps – reprojection is an expensive process.
You could of course store WGS84 angular coordinates using the geometry datatype, but this is really a hack and not recommended – you are almost certain to run into difficulties further down the line.
So, I’d recommend using the geography datatype and WGS84. With careful index tuning, you should still be able to get sub-second response time for most queries of even large datasets. Incidentally, the “within a hemisphere” rule is lifted for the geography datatype in SQL Denali, so that limitation goes away if you were to upgrade.