Recently, while working on WebGIS and trajectory processing, I encountered a classic problem once again: I have a WGS84 latitude/longitude point and need to shift it a few hundred meters due east and due north to obtain new coordinates. One approach is to use the Haversine formula to calculate the distance between two points and then reverse the process to find a new point given a distance and bearing, but is there a lighter-weight alternative? I’d like to briefly summarize a few methods today.
First, understand a basic concept: latitude and longitude are angles on a sphere, measured in degrees, while the offset is in meters. The two cannot be computed directly. Below are several approaches, ordered from easiest to hardest to implement. You can choose based on your scenario.
The 111,111 Planar Approximation
This is my most recommended everyday solution. Along the latitude direction, approximately 111,111 meters equals 1 degree; along the longitude direction at a given latitude, approximately 111,111 × cos(latitude) meters equals 1 degree.
PS: The origin of this number is quite interesting. When France defined the meter, the distance from the equator to the North Pole along the Paris meridian was exactly 10^7 meters. Therefore, 10^7 divided by 90 equals approximately 111,111.1, which corresponds to 1 degree of latitude. The longitude circle narrows with latitude, so we multiply by cos(latitude). The formulas are:
new_lat = lat + dn / 111111
new_lon = lon + de / (111111 × cos(lat))For offsets up to a few kilometers and not near the poles, the error is usually around 10 meters. This is sufficient for embedded systems and front-end real-time calculations.
Earth Radius Conversion
This is essentially the same as the 111,111 method, but replaces the constant with the WGS84 semi-major axis R = 6,378,137 m. First convert the meter offset to radians, then add back to degrees. At low latitudes the difference between the two approaches is very small; either works. Python implementation:
from math import cos, radians, pi
R = 6378137
d_lat = dn / R
d_lon = de / (R * cos(radians(lat)))
new_lat = lat + d_lat * 180 / pi
new_lon = lon + d_lon * 180 / piThe 111,111 constant essentially merges R and the radians-to-degrees conversion into an easy-to-remember integer, saving computation. The Earth-radius version makes the physical meaning more intuitive, which is good for projects that need to align with ellipsoid parameters.
UTM Projection Offset
When the offset is larger and you want rigorous planar addition/subtraction, you can project first and then offset. The idea: convert the latitude/longitude to the local UTM zone, add x,y offsets in meters in the projected plane, and then transform back to latitude/longitude. This can be done with projection toolchains in QGIS, PostGIS, PROJ, or ArcGIS.
The advantage is that a metric offset in the projection plane is a true Cartesian operation, giving a clear sense of direction. The disadvantage is that you must be careful when crossing UTM zone boundaries, otherwise the point can jump dramatically. This is suitable for engineering scenarios where the work area is known and the offset stays within a single zone.
Vincenty Direct Solution
When ellipsoid-level accuracy is needed, the Vincenty direct formula is a rigorous geodetic solution that computes the destination point from a starting point, an azimuth, and a distance on the WGS84 ellipsoid. It is more accurate than the planar approximation and simple spherical formulas, but the implementation is complex, requiring iteration and handling rare non-convergent cases.
For surveying-grade results, this method is recommended. You can use PROJ, GeographicLib, or built-in algorithms in various GIS software.
PostGIS ST_Project
The easiest approach on the database side. PostGIS provides the ST_Project function: pass in the starting geometry, an azimuth, and a distance, and it directly returns the new point. This is ideal when your data is already in PostGIS and the offset logic needs to be written in SQL or stored procedures. Under the hood it still uses spherical or ellipsoidal calculations; accuracy and parameters depend on the PostGIS version and function options.
High-Precision Polynomial Meters-per-Degree
In 2024 someone in the community posted a more refined meters-per-degree formula that breaks down the effect of latitude on the longitude circle radius into multiple cosine terms, further reducing longitude-direction error. This is a good compromise for those who find the approximate constant insufficient but don't want to implement the full Vincenty solution.
In my opinion, for offsets under 1 kilometer, the 111,111 method already introduces less error than the coordinate noise in many applications. Don't overcomplicate things too early. I previously wrote about this in "How Many Decimal Places Are Enough for Latitude and Longitude?", where I mentioned that coordinate accuracy itself has physical limits.
Summary
For small ranges where speed is key, prefer the 111,111 planar approximation or the Earth-radius conversion. For a well-defined region and larger offsets, use the UTM projection. For azimuth/distance requirements or high accuracy, use spherical formulas, Vincenty, or PostGIS.
If you have a more convenient implementation or lessons learned, feel free to leave a comment.