ST_AZIMUTH

Compute the initial azimuth in radians from one point to another on a spherical Earth.

Category: geospatialReturns: DOUBLEDialect: Standard

Syntax

ST_AZIMUTH(lat1, lng1, lat2, lng2)

Description

## Overview Returns the initial azimuth in radians from a starting point to a destination point, measured clockwise from true north on a spherical Earth model. The result is in the range (-PI, PI] as produced by atan2; add 2*PI to negative values if you need a non-negative radian range. Multiply by 180/PI and normalize into [0, 360) to produce a compass-degree value. Azimuth is the direction you would face at the start of a great-circle path when pointing toward the destination. Because great-circle paths curve on a sphere, the azimuth at the destination (the final bearing) is generally different from this initial azimuth. Use ST_FINAL_BEARING for the direction at the destination. ## When to use ST_AZIMUTH vs. alternatives - **ST_AZIMUTH** (this function): initial heading at the origin, in radians. The raw trigonometric form; useful when you want to feed the value directly into other trigonometric SQL functions without unit conversion. - **ST_BEARING**: same initial-heading computation but returned in compass degrees in [0, 360). Prefer ST_BEARING when the downstream consumer expects compass degrees. - **ST_FINAL_BEARING**: heading at the destination, in compass degrees. Differs from the initial heading on long great-circle paths. - **ST_DISTANCE_HAVERSINE**: complementary distance measure; typically called alongside ST_AZIMUTH to describe a great-circle route. ## Behavior - The result is in radians, measured clockwise from true north. - Uses a spherical Earth model with mean radius 6,371,008.8 meters, matching ST_DISTANCE_HAVERSINE. - Arguments are ordered (lat, lng), not (lng, lat), for consistency with the distance functions. - Returns NULL if any argument is NULL. - Returns 0 when the two points are identical because the bearing is undefined; callers that need to distinguish this case should test for equal coordinates explicitly. - Near the poles, small longitude differences produce large azimuth swings. Expect numerical sensitivity when either point is within a few meters of a pole. - The antimeridian (longitude wrapping from +180 to -180) is handled correctly; you do not need to normalize longitudes before calling. ## Accuracy and performance - Spherical accuracy is sufficient for navigation, map rendering, and sector filtering. For geodetic surveying use an ellipsoidal bearing function. - Pure arithmetic with a single atan2 call; performance is comparable to ST_DISTANCE_HAVERSINE. - Azimuth changes along the great-circle path. If you need the midpoint direction, sample the bearing from an intermediate point rather than averaging the endpoints. ## Compatibility - Matches the initial-bearing formula used by most geospatial libraries built on WGS 84 inputs. - Returns radians rather than compass degrees to match the convention of other trigonometric SQL functions. Use ST_BEARING for the degrees form.

Parameters

Name	Type	Description
`lat1`		Specifies the WGS 84 latitude of the starting point in decimal degrees, in the range -90 to 90.
`lng1`		Specifies the WGS 84 longitude of the starting point in decimal degrees, in the range -180 to 180.
`lat2`		Specifies the WGS 84 latitude of the destination point in decimal degrees, in the range -90 to 90.
`lng2`		Specifies the WGS 84 longitude of the destination point in decimal degrees, in the range -180 to 180.

Examples

-- Result is in radians, measured clockwise from true north.
-- 0 is north, PI/2 is east, PI is south, 3*PI/2 is west.
SELECT ST_AZIMUTH(51.5074, -0.1278, 48.8566, 2.3522) AS azimuth_rad;

-- Multiply by 180/PI and normalize into [0, 360) to compare against compass headings.
SELECT (ST_AZIMUTH(51.5074, -0.1278, 48.8566, 2.3522) * 180.0 / 3.141592653589793 + 360.0) % 360.0 AS azimuth_deg;

-- Group outbound routes by the radian direction they head toward.
SELECT route_id,
       ST_AZIMUTH(origin_lat, origin_lng, dest_lat, dest_lng) AS azimuth_rad
FROM logistics.catalog.routes
ORDER BY azimuth_rad;

-- Keep shipments heading roughly north (azimuth within +-15 degrees of 0 radians).
SELECT shipment_id
FROM logistics.catalog.shipments
WHERE ABS(ST_AZIMUTH(origin_lat, origin_lng, dest_lat, dest_lng)) < 0.2618;

-- Return both distance and bearing for each origin-destination pair.
SELECT origin_id, dest_id,
       ST_DISTANCE_HAVERSINE(o_lat, o_lng, d_lat, d_lng) AS distance_m,
       ST_AZIMUTH(o_lat, o_lng, d_lat, d_lng) AS azimuth_rad
FROM logistics.catalog.od_pairs;

-- ST_AZIMUTH returns radians; ST_BEARING returns compass degrees in [0, 360).
SELECT
  ST_AZIMUTH(51.5074, -0.1278, 48.8566, 2.3522) AS azimuth_rad,
  ST_BEARING(51.5074, -0.1278, 48.8566, 2.3522) AS bearing_deg;

Pitfalls

The result is in radians, not compass degrees. Comparing against a compass-degree literal like 90 will silently filter out almost every row; convert explicitly with (azimuth * 180 / PI + 360) mod 360.
ST_AZIMUTH returns radians but the sibling function ST_BEARING returns compass degrees. Mixing the two in the same expression without converting units produces nonsense; pick one and stay consistent.
Arguments are ordered (lat, lng), not (lng, lat). Swapping the order returns a bearing that is wrong by up to PI radians because latitude and longitude occupy overlapping ranges.
ST_AZIMUTH is the initial bearing at the origin. On long paths it differs noticeably from the final bearing at the destination; use ST_FINAL_BEARING when you need the arrival direction.
Identical origin and destination return 0 rather than NULL because the bearing is undefined. Filter out zero-distance pairs upstream if a deterministic result matters.
Near the poles the formula is numerically sensitive; small coordinate noise in the input produces large jumps in the output. Consider clamping latitudes away from exact +-90 before calling.