Distance Calculator (Latitude/Longitude) for SQL Server

SQL Server Latitude/Longitude Distance Calculator

Calculate the distance between two geographical points using the Haversine formula, and learn how to implement the algorithm in SQL Server.

Distance Calculator

Latitude – Point 1

e.g., London: 51.5074

Longitude – Point 1

e.g., London: -0.1278

Latitude – Point 2

e.g., Paris: 48.8566

Longitude – Point 2

e.g., Paris: 2.3522

Unit of Distance

Copied!

343.51 Kilometers

Δ Latitude: -2.6508°

Δ Longitude: 2.4800°

Earth Radius: 6371 km

Visual Representation (Not to Scale)

A simplified 2D plot of the two coordinate points.

What is the Algorithm to Calculate Distance Using Latitude and Longitude in SQL Server?

The algorithm to calculate distance using latitude and longitude in SQL Server most commonly refers to implementing a geospatial formula to find the great-circle distance between two points on the Earth’s surface. While SQL Server (2008 and newer) has a built-in geography data type with a native STDistance() method, understanding the underlying mathematical formula, like the Haversine formula, is crucial for custom applications, compatibility with older systems, or when you need full control over the calculation logic. This process is essential for logistics, location-based services, and data analysis involving geographic data.

This calculator and article focus on the famous **Haversine formula**, a reliable method that treats the Earth as a sphere. The built-in STDistance() function in SQL Server is often more accurate as it can use more complex ellipsoidal models of the Earth, but Haversine is excellent for a wide range of applications where millimeter precision isn’t required. You can learn more about SQL Server spatial data types and their performance.

The Haversine Formula and SQL Implementation

The Haversine formula calculates the shortest distance over the Earth’s surface, delivering an ‘as-the-crow-flies’ distance between the points (ignoring any hills, valleys, or other obstacles). The formula is as follows:

a = sin²(Δφ/2) + cos(φ₁) * cos(φ₂) * sin²(Δλ/2)
c = 2 * atan2(√a, √(1−a))
d = R * c

This can be implemented as a user-defined function in SQL Server for reusability. Here is a sample T-SQL function demonstrating the algorithm to calculate distance using latitude and longitude in SQL Server.

CREATE FUNCTION dbo.HaversineDistance(
    @Lat1 FLOAT, @Lon1 FLOAT,
    @Lat2 FLOAT, @Lon2 FLOAT,
    @Unit VARCHAR(10)
)
RETURNS FLOAT
AS
BEGIN
    DECLARE @R FLOAT;
    -- Set Earth radius based on unit
    SET @R = CASE @Unit
                WHEN 'miles' THEN 3959
                WHEN 'nm' THEN 3440
                ELSE 6371 -- Default to kilometers
             END;

    DECLARE @dLat FLOAT = RADIANS(@Lat2 - @Lat1);
    DECLARE @dLon FLOAT = RADIANS(@Lon2 - @Lon1);

    DECLARE @a FLOAT = SIN(@dLat / 2) * SIN(@dLat / 2) +
                       COS(RADIANS(@Lat1)) * COS(RADIANS(@Lat2)) *
                       SIN(@dLon / 2) * SIN(@dLon / 2);

    DECLARE @c FLOAT = 2 * ATAN2(SQRT(@a), SQRT(1 - @a));
    DECLARE @distance FLOAT = @R * @c;

    RETURN @distance;
END

Variables Table

Variables used in the Haversine formula.
Variable	Meaning	Unit	Typical Range
φ₁, λ₁	Latitude and Longitude of Point 1	Degrees	-90 to +90 (Lat), -180 to +180 (Lon)
φ₂, λ₂	Latitude and Longitude of Point 2	Degrees	-90 to +90 (Lat), -180 to +180 (Lon)
Δφ, Δλ	Difference in latitude and longitude	Radians (in formula)	N/A
R	Radius of Earth	km, miles, or nm	~6371 km or ~3959 miles
d	Final calculated distance	Same as R	0 to ~20,000 km

Practical Examples

Example 1: New York City to Los Angeles

Let’s calculate the distance between JFK Airport in New York and LAX Airport in Los Angeles.

Point 1 (JFK): Latitude = 40.6413, Longitude = -73.7781
Point 2 (LAX): Latitude = 33.9416, Longitude = -118.4085
Units: Miles

Result: Using the Haversine algorithm, the distance is approximately **2,475 miles**. This is a great example for a cross-country logistics company planning routes.

Example 2: Using SQL Server’s Native `geography` Type

Since SQL Server 2008, you can use the built-in geography data type for a more straightforward and often more accurate calculation. This is the recommended approach for modern applications. The syntax is much simpler:

DECLARE @point1 geography = geography::Point(40.6413, -73.7781, 4326);
DECLARE @point2 geography = geography::Point(33.9416, -118.4085, 4326);

-- STDistance() returns the result in meters
SELECT (@point1.STDistance(@point2) / 1609.34) AS DistanceInMiles;

This query will return a result very close to the Haversine calculation, around **2,468 miles**. The small difference is due to the geography type using a more precise ellipsoidal model of the Earth (WGS 84) by default. For more information, read about the haversine formula in SQL.

How to Use This Latitude-Longitude Distance Calculator

This tool makes it easy to find the distance between two points without writing any code.

Enter Coordinates for Point 1: Input the latitude and longitude for your starting location into the “Point 1” fields.
Enter Coordinates for Point 2: Do the same for your ending location in the “Point 2” fields.
Select a Unit: Choose whether you want the result in Kilometers, Miles, or Nautical Miles from the dropdown menu.
Interpret the Results: The calculator automatically updates. The large number is the primary result (the great-circle distance). The intermediate values show the difference in coordinates and the Earth radius used for the calculation.

Key Factors That Affect Distance Calculations

While the Haversine formula is powerful, several factors can influence the accuracy and performance of your distance calculations in a real-world scenario, especially within SQL Server.

Earth Model (Sphere vs. Ellipsoid): The Haversine formula assumes a perfect sphere. For most cases, this is fine. However, the Earth is an oblate spheroid (slightly flattened at the poles). SQL Server’s geography data type uses more accurate ellipsoidal models (like WGS 84), which can lead to slightly different, more precise results.
Data Type Precision: The precision of your latitude and longitude columns (e.g., FLOAT vs. DECIMAL(9,6)) can impact accuracy. Using FLOAT is common, but be aware of potential rounding issues in rare cases.
SQL Server Version: The geography spatial data type was introduced in SQL Server 2008. If you are using an older version, you must implement a T-SQL function with the Haversine formula manually.
Spatial Indexes: When querying large datasets for records within a certain distance (e.g., “find all stores within 10 miles”), a spatial index is critical for performance. Without one, SQL Server must calculate the distance for every single row in the table, which is very slow. A spatial index allows for much faster lookups.
SRID (Spatial Reference Identifier): When using the geography type, you must use a Spatial Reference ID. For global latitude and longitude, 4326 (WGS 84) is the standard. Using incorrect or mismatched SRIDs will result in errors or NULL values.
Formula Choice: Besides Haversine, other formulas like Vincenty’s formulae exist, which are more complex but even more accurate on an ellipsoid. However, their computational cost is higher, and the Haversine formula is the best balance of simplicity and accuracy for the vast majority of non-navigational applications.

Frequently Asked Questions (FAQ)

1. Why is my SQL query for distance so slow?

Most likely because you are not using a spatial index. When you use a calculation like the Haversine formula or even `STDistance()` in a `WHERE` clause, SQL Server has to scan the entire table. A spatial index dramatically speeds up queries that look for data within a geographic area. For tips, see our guide on geospatial query optimization.
2. What is the difference between the Haversine formula and SQL Server’s STDistance()?

Haversine assumes the Earth is a perfect sphere. `STDistance()` on the `geography` type uses a more accurate ellipsoidal model (like WGS 84), which accounts for the Earth’s slight flattening. For most applications, the difference is negligible, but `STDistance()` is technically more accurate.
3. What does the `4326` mean in `geography::Point(lat, lon, 4326)`?

It’s the Spatial Reference Identifier (SRID). 4326 corresponds to the World Geodetic System 1984 (WGS 84), the standard for GPS and global coordinate systems. You must use the same SRID for all points in a calculation.
4. Can I calculate distance in miles instead of kilometers?

Yes. In the Haversine formula, you just change the Earth’s radius (R). Use approximately 3959 for miles or 6371 for kilometers. When using `STDistance()`, the result is in meters, so you need to convert it by dividing (e.g., divide by 1609.34 for miles).
5. Does this calculator account for elevation?

No, this is a 2D calculation for surface distance. It does not factor in altitude differences between the two points. Calculating 3D distance would require an extra step using the Pythagorean theorem with the altitude difference as the third dimension.
6. What is the most efficient way to find all points within a certain radius in SQL?

Use the native `geography` data type on a column with a spatial index. Then, use the `STDistance()` method in your `WHERE` clause. For example: `WHERE YourGeoColumn.STDistance(@centerPoint) <= @radiusInMeters`. This is highly optimized.
7. Why do I get a NULL result from STDistance()?

This usually happens if the SRIDs of the two `geography` instances do not match. Ensure both points are created with the same SRID (e.g., 4326). It can also occur with invalid or out-of-range latitude/longitude values.
8. Is there an alternative to a T-SQL function for this algorithm?

Yes, you could create a SQL CLR function. This allows you to write the function logic in a .NET language like C#. For complex calculations, this can sometimes offer better performance than T-SQL, though it adds complexity to your database deployment.