The Coordinate Isn’t Just an Address — It’s a Station-Selection Decision
Most developers treat lat and lon as a lookup key. You pass in a location, you get weather back. But the decimal places you send, and where you snap coordinates to, quietly determines which physical weather station backs that response — and those aren’t always equivalent choices.
Here’s the concrete version: a coordinate rounded to two decimal places has a worst-case horizontal error of roughly 1.1km at the equator. At four decimal places, that’s about 11 meters. For a city-center location surrounded by reporting stations, 1.1km probably doesn’t change anything. But near a coastline, an airport perimeter, or anywhere with a sharp elevation transition, the difference between 51.48 and 51.4832 can flip station selection entirely — from a coastal METAR to an inland synoptic station, or vice versa.
How Station Selection Actually Works
We don’t just find the nearest station and call it done. Our scoring weights distance alongside elevation difference and recent reporting consistency — but that scoring still starts with a bounding query against the coordinate you gave us. If your coordinate is imprecise, the candidate set of nearby stations shifts. The logic can only pick the best station from the candidates it sees. It can’t compensate for a coordinate that’s already a kilometer off in the wrong direction.
The elevation correction compounds this. We apply a standard atmospheric lapse rate — roughly 6.5°C per 1,000m, the same general figure NOAA and WMO use for standard atmosphere calculations — to adjust for elevation difference between the selected station and the requested point. If an imprecise coordinate caused us to select a station at the wrong elevation, that correction pulls in the wrong direction. You get a plausible-looking adjusted temperature that’s actually correcting away from reality rather than toward it.
This isn’t a theoretical edge case. It shows up in mountainous terrain and in coastal cities where a few hundred meters of coordinate slop separates a marine-influenced station from one that’s genuinely inland. The Pacific Northwest, the Scottish coast, Norwegian fjords, parts of the Canary Islands — anywhere terrain or water changes dramatically over short distances is where imprecision bites hardest.
Snapping to Grid vs. Passing Raw Coordinates
Some developers snap coordinates to a grid before calling any API — bucketing to 2 decimal places as a caching optimization. This is a real pattern and it’s not wrong for flat, station-dense regions. But it’s a trade-off worth being explicit about.
Snapping to 0.01° buckets means caching responses for an area roughly 1km × 1km. For most urban use cases, that’s fine. For anything involving real elevation change or a coastline, you’re accepting the possibility that the snapped coordinate selects a different representative station than the precise one would — and you might not notice, because the returned data will still look sensible. It won’t throw an error. It’ll just be quietly wrong.
Our own caching layer makes the same call. We run on infrastructure we manage ourselves on UpCloud rather than a managed cloud with unlimited cache tiers, so we’re not caching at infinite granularity either. But we snap at the response aggregation level, not the station-selection level — station selection always runs against the coordinate as provided.
What Precision You Actually Need
Four decimal places (±0.0001°, roughly ±11m at mid-latitudes) is more than enough for any weather use case. Six decimal places is GPS-level precision and completely unnecessary — weather stations aren’t spaced 1 meter apart. Three decimal places (±111m) works for most non-coastal, non-mountainous locations. Two decimal places (±1.1km) is where things get unreliable in terrain-varied areas.
The practical rule: if your users’ locations come from a GPS or HTML5 Geolocation API, you’re already getting 4-6 decimal places — don’t round them down before passing to us. If you’re geocoding a city name or postal code first, check what precision the geocoder actually returns. Many geocoding services snap to city centroids, which can be kilometres off if the city spans irregular terrain.
The City-Name Route Has Its Own Problem
Our q parameter accepts city names, postal codes, and coordinates. City-name lookup is convenient for quick integrations, but the centroid we resolve to for a place like “Bergen, Norway” or “Innsbruck, Austria” is a single point — likely the valley floor — when your user might be partway up a slope. There’s no way around this with a name-based lookup. You get the centroid, and station selection runs from there.
If location precision genuinely matters for your use case — agricultural monitoring, hiking apps, ski resort conditions, anything where elevation is part of the point — pass coordinates directly. Don’t rely on city-name resolution and then wonder why the elevation-adjusted temperature doesn’t match what your users are experiencing on the ground.
Checking Which Station Backed Your Response
The real-time and current conditions response includes a location block with lat and lon fields reflecting what we resolved to, and the observation source can sometimes be inferred from the region and tz_id fields. For METAR-backed responses, the station is an ICAO-coded airport or reporting site. If readings feel wrong for a location, pull the coordinate from the response and check it against known METAR station positions — the NOAA station database is publicly accessible and will usually tell you whether you’ve landed in the right microclimate zone.
It’s not as convenient as having a station_id field directly in the response — I’ll acknowledge that. But the debugging path exists and it’s usually faster than assuming the underlying model data is at fault.
One More Precision Trap: Floating-Point Coordinate Generation
This sounds obvious, but it surfaces in support conversations more than it should: if you’re programmatically generating coordinates by doing arithmetic on floats, check what you’re actually sending. Adding offsets to a base coordinate in floating-point can produce values like 51.499999999997 — technically fine, but they hit cache-miss cases differently than 51.5 would. Not a breaking problem, but worth serializing to a fixed decimal precision before passing to the API rather than relying on default float-to-string conversion.
Python’s str(float), JavaScript’s default .toString(), and C#’s default double.ToString() all handle this slightly differently. Pick a precision, format explicitly, be consistent.
One Thing Worth Sitting With
If you’re caching, cache by a bucketed key — but send the precise coordinate to the API. Those are separable concerns and conflating them is where the quiet errors come from. And if conditions data feels slightly off for a coastal or mountainous location, check coordinate precision and then check which station was selected before concluding the forecast model is wrong. In our experience, the station is the variable far more often than the model.