The Absurdity of Floating-Point Precision in Coordinates
Description
This is a single-panel comic, in the style of XKCD, titled 'WHAT THE NUMBER OF DIGITS IN YOUR COORDINATES MEANS'. It presents a table with two columns: 'LAT/LON PRECISION' and 'MEANING'. The table humorously illustrates the consequence of adding more decimal places to geographic coordinates. It starts with low precision (28°N, 80°W) meaning 'YOU'RE PROBABLY DOING SOMETHING SPACE-RELATED', and with each row, the precision increases, and the meaning becomes more specific and absurd. It moves from a city, to a neighborhood, to a corner of a house, to a person in a room, to 'Waldo on a page', and even 'a specific sand grain'. The final entry, with many decimal places, concludes: 'EITHER YOU'RE HANDING OUT RAW FLOATING POINT VARIABLES, OR YOU'VE BUILT A DATABASE TO TRACK INDIVIDUAL ATOMS. IN EITHER CASE, PLEASE STOP.' The joke targets developers who misuse or misunderstand floating-point precision, a common source of bugs and inefficiencies, by showing the ridiculous real-world implications of having too much data that offers no real value
Comments
7Comment deleted
The difference between a senior and a junior dev is the junior uses a double for coordinates, while the senior knows the third decimal place is already more accurate than the project's requirements
Marketing wanted 17-decimal lat/lon so we could “hyper-target” users - it’s all good until PostGIS pinpoints an electron while the GPS still dumps everyone at Null Island
After 20 years of arguing about whether to store coordinates as DECIMAL(10,7) or FLOAT, we finally compromised and stored them as VARCHAR(255) - because nothing says 'enterprise architecture' like tracking individual quarks in a string field with no validation
This perfectly captures the moment when your location API returns coordinates precise enough to identify which electron in your phone's GPS chip is currently oscillating - because nothing says 'production-ready' quite like storing lat/long with more decimal places than there are atoms in the observable universe. It's the geospatial equivalent of using a 128-bit UUID to track your three users
If your API returns 15‑decimal lat/lon, you didn’t build maps - you shipped Double.toString() with a side of GDPR
Precision creep in lat/lon: starts with 'neighborhood targeting,' ends with a DynamoDB partition key per quark and SREs paging at Planck length
Shipping lat/long with 15 decimals and no EPSG is precision theater - sure, we can pinpoint a molecule; we just can’t agree whether it’s in 4326 or 3857