Float-like storage of lat/lon/height in site_info.json

[alexdanjou]

Storing the lat/lon/height in site_info.json as float while wanting the precision to be kept makes it difficult to maintain (e.g AMB latitude of 69.6200, TAC longitude of 1.13870). Indeed, loading the file with json make us loose the precision.

If you know of an alternative to json that avoids this, it might helps.
Otherwise, is the precision here really necessary?
If yes I would suggest to store this values as strings. This would require an adaptation of lots of bits of code but nothing complicated. Would be quite easy to solve this as we go along.

[alexdanjou]

Feel free to add anyone that might be concerned by this.

[brendan-m-murphy]

Maybe this info should be stored at netcdf? We could keep a text version for human-readability, but load the actual values from netcdf. We could add a helper function to openghg_defs to load this info (if there isn't one already... I think it might be in OpenGHG though).

Is the issue that the trailing 0's are dropped?

The following example runs (both asserts are true):

import json
lat_val = 1.13870
data = {"lat": lat_val}

json_lat_val = json.loads(json.dumps(data))["lat"]

assert json_lat_val == lat_val
assert str(json_lat_val) == "1.137"

So numerically, python doesn't think anything has been lost, but the string repr isn't the same. (Python doesn't print trailing 0's apparently.)

(Note: the value output by dumping to json string then loading that string is {"lat": 1.1387}, so there is the loss of precision in the scientific(?) sense. But both numbers are the same 64-bit floats, I think.)

[rt17603]

I think we'd need to think a bit about how people want to use it. At the moment I believe people mainly just update the json file directly. Doesn't mean we couldn't move to something more automated but we'd need to think about interfaces.

For reference, the number of dp (including 0s) has been important in the past because it is used to explain the level of precision the lat, lon is known to.