This post is about the numbers of decimal places in the title: why they are ridiculous, why they are not ridiculous, and how and when to use them.
Source. On 23 January 2023, bird observer Jørn Knudsen spotted a tiny Goldcrest, Regulus regulus (Linneaus, 1758), in Teglværkskov Forest, north of Nyborg in Denmark. He recorded the observation using Arter, the Danish biological records project.
Like iNaturalist, Arter allows its users to pin their observations on a map. The Arter mapping software processed the chosen location in this case as 55.33236879409907 10.798312272550604 (more on this below). Arter users can also put an uncertainty zone around the location and adjust its size. The processed uncertainty for this bird observation was 4.068529808544554 meters.
When Arter displayed these figures on its website, the coordinates were rounded to 6 decimal places as 55.332369 10.798312 and the uncertainty was rounded to 2 decimal places as 4.07 m (see Arter record).
Arter records are shared with GBIF. This record arrived at GBIF with 55.33236879409907 10.798312272550604 and 4.068529808544554. In processing the record, GBIF likewise rounded the figures to 6 and 2 decimal places (see GBIF record).
Ridiculous! Those original figures are outrageous. The uncertainty is definitely not known to the nearest femtometer, which would be about 16 millionths of the diameter of a helium atom.
The latitude and longitude are equally outrageous. One degree of latitude is about 111000 meters, while at 55 degrees north, one degree of longitude is about 64000 meters. The coordinates have been given to the nearest 0.00000000000001 of a degree, or 1.11 nanometers in latitude and 0.64 nanometers in longitude. No location can be known that exactly, and for a bird 90 mm long, a location that precise is meaningless.
Rounded to 6 decimal places, the coordinates are given to the nearest 0.111 m in latitude (±55 mm) and 0.064 m (±32 mm) in longitude, which is still suspiciously precise, while an uncertainty rounded to 2 decimal places is to the nearest 0.01 m (±5 mm; really??).
NOT ridiculous! The unrounded latitude, longitude and uncertainty are not outrageous. They are a computer’s way of trying to approximate fractional numbers.
Computers use binary numbers, not decimal numbers, when they calculate. Binary calculations work fine with whole numbers, but have difficulty with numbers between whole numbers, like the decimal-degree latitudes between 55 and 56 N. The best a computer can do is to approximate the result of such a calculation, and the result will not be exact.
Actually, we do the same. The decimal value of 1/6 is 0.166666666666…, where the “…” means “continuing like this infinitely”. Most of us would be happy with rounding the decimal to 0.166667, which is the same as 0.166666666666… for practical purposes. Inside a computer, “for practical purposes” means “using the number of bits allowed for approximating a result”.
So a number like “55.33236879409907” should be seen not as a super-accurate latitude, but as a computer’s desperate attempt to estimate the result of a binary calculation, up to the number of decimal places allowed by the rules of its calculating program.
I’m simplifying. For readable introductions to floating point arithmetic and its rules, see Floating-point arithmetic – all you need to know, explained interactively and The Perils of Floating Point
Usage The “long form” numbers seen in the title of this post could be useful to a computer if further calculations need to be done with them. Think of them as numbers used when one computer is speaking to another computer.
The “long form” numbers should not, in my opinion, be used when a human is speaking to another human. They should be rounded off, and rounding is what both Arter and GBIF have done in this case. The rounding should be done to a number of decimal places consistent with the measurement or calculation error involved in estimating the coordinates and the uncertainty.
That’s a separate and larger topic and is partly covered in GBIF’s excellent Georeferencing Best Practices. As usual, however, Randall Munroe has helped with an XKCD cartoon:
Robert Mesibov (“datafixer”); robert.mesibov@gmail.com