The output reference documents that latitude and longitude are written with reduced precision as a privacy measure. That is true for the API path only. The CSV receives full-precision coordinates, so users relying on the documented behaviour are sharing a more precise location than they expect.
Current behaviour
docs/reference/output.md describes the latitude / longitude fields as being written "with reduced precision to 11.1 km (privacy protection)".
Rounding is applied in exactly one place, on the API path:
# codecarbon/core/api_client.py:245-246
longitude=round(self.conf.get("longitude", 0), 1),
latitude=round(self.conf.get("latitude", 0), 1),
The CSV path does no rounding. _prepare_emissions_data reads the values straight from config:
# codecarbon/emissions_tracker.py:1111-1112
longitude=self._conf.get("longitude"),
latitude=self._conf.get("latitude"),
and those were populated at full precision from the geolocation lookup:
# codecarbon/emissions_tracker.py:385-386
self._conf["longitude"] = self._geo.longitude
self._conf["latitude"] = self._geo.latitude
Why this matters
emissions.csv is the artefact users attach to papers, commit to repositories, and upload alongside experiment results. The documentation gave them a reason to believe the coordinates in it were already coarsened to roughly 11 km. They are not — they are whatever the geolocation provider returned, which for a residential connection can be considerably more precise.
This is a mismatch between a documented privacy guarantee and actual behaviour, which is worse than never having documented it.
Expected
One of:
- Apply the same rounding on the CSV path, making the documented behaviour true everywhere. This is the option that matches what users have been told, and one decimal place is unlikely to matter for any legitimate use of the field.
- Correct the documentation to state that full-precision coordinates are written to the CSV, and offer a configuration option for users who want them coarsened or omitted.
Option 1 seems more defensible given the field was documented as privacy-protecting, but it is a behaviour change to an output column and deserves a maintainer decision.
Note
The documentation half of this is being corrected in a separate docs PR, which changes the text to describe what the code actually does. This issue tracks the underlying behaviour question.
The output reference documents that latitude and longitude are written with reduced precision as a privacy measure. That is true for the API path only. The CSV receives full-precision coordinates, so users relying on the documented behaviour are sharing a more precise location than they expect.
Current behaviour
docs/reference/output.mddescribes thelatitude/longitudefields as being written "with reduced precision to 11.1 km (privacy protection)".Rounding is applied in exactly one place, on the API path:
The CSV path does no rounding.
_prepare_emissions_datareads the values straight from config:and those were populated at full precision from the geolocation lookup:
Why this matters
emissions.csvis the artefact users attach to papers, commit to repositories, and upload alongside experiment results. The documentation gave them a reason to believe the coordinates in it were already coarsened to roughly 11 km. They are not — they are whatever the geolocation provider returned, which for a residential connection can be considerably more precise.This is a mismatch between a documented privacy guarantee and actual behaviour, which is worse than never having documented it.
Expected
One of:
Option 1 seems more defensible given the field was documented as privacy-protecting, but it is a behaviour change to an output column and deserves a maintainer decision.
Note
The documentation half of this is being corrected in a separate docs PR, which changes the text to describe what the code actually does. This issue tracks the underlying behaviour question.