Snap a latitude and longitude coordinate to a grid

Provide latitude, longitude, and the spacing between nodes in decimal degrees; optionally move the grid by choosing a custom origin. The result includes the snapped coordinate, integer grid indexes, and signed offsets from the original point. This makes coordinates easier to group, compare, cache, and use as compact spatial buckets without relying on a remote geocoding service or a heavyweight geographic information system.

Choose a grid that matches your indexing task

A regular geographic grid divides latitude and longitude into repeatable intervals. Start by supplying a coordinate and a positive spacing in decimal degrees. A smaller spacing creates more nodes and preserves more positional detail, while a larger spacing groups a wider area under the same snapped coordinate. The spacing applies independently to both axes, so the output is a rectangular grid in angular coordinates. This is useful for quantized spatial indexing, aggregation, cache keys, coarse deduplication, and privacy-aware reduction of coordinate precision. Remember that degrees are angular units: the ground distance represented by one degree of longitude becomes smaller toward the poles. If you need cells with a nearly constant size in meters over a broad region, project the data into a suitable planar coordinate reference system before applying a metric grid. For local or intentionally degree-based datasets, direct snapping is often the simplest and most transparent choice. The calculation does not infer a spacing or silently change units, so every result remains reproducible from the declared inputs.

Control alignment with the grid origin

By default, the grid is anchored at zero latitude and zero longitude. Every node is the origin plus an integer multiple of the chosen spacing on each axis. You can provide origin_lat and origin_lon when an existing tiling convention uses a different alignment. This matters because two grids with identical spacing but different origins produce different buckets. The returned latitude and longitude indexes identify the signed number of spacing steps from that origin, which makes a convenient compound key when the grid definition is stored alongside it. Snapping is performed independently on latitude and longitude, and an exact halfway tie is resolved away from index zero for a stable, documented result on both positive and negative coordinates. At the geographic limits, the calculation chooses the nearest node belonging to the declared grid that still lies within valid latitude and longitude bounds. It never emits a latitude beyond 90 degrees or a longitude beyond 180 degrees merely because an unconstrained arithmetic node would be closer.

Interpret the snapped coordinate and offsets

The response returns the snapped latitude and longitude as the primary result, together with lat_index and lon_index. It also reports signed changes in degrees. A positive latitude offset means the node lies north of the supplied point, while a negative longitude offset means it lies west of the supplied point. These offsets help you audit how much quantization was introduced or reject records whose displacement exceeds a policy defined by your application. Results are rounded to twelve decimal places to remove irrelevant binary floating-point noise while retaining detail well below the minimum accepted spacing. The operation is deterministic, uses no network, and keeps no state, so the same JSON input produces the same JSON output in a browser or through the API. One request processes one coordinate and costs $0.002 through the API. For batch workflows, call the capability for each item and retain the spacing and origin with stored indexes so future readers can reconstruct the exact grid definition rather than guessing it from the snapped values.