Add geospatial extent to model ouput schema

[joshuatorrance]

Closes #66

Adds the follow attributes to the model output schema:

• geospatial_lat_min
• geospatial_lat_max
• geospatial_lat_units
• geospatial_lon_min
• geospatial_lon_max
• geospatial_lon_units

Details and description are heavily plagiarised inspired by the ACDD equivalents.

I restricted this schema to require units of degrees_north/degrees_east. ACDD permits other units.

I have also restricted the longitude to -180 to 180. ACDD also allows 0 to 360. Reasoning here is just to keep things simple, if this would be restrictive then it can be relaxed.

• Is the way I've duplicated the 2-0-0 schema the correct way to create a new schema?
• The min/max values have type number. These are the first numbers in the schema - need to check all the downstream tools handle numbers correctly.
  • addmeta needs a solution for numerical templates see issue & PR
  • access-output-data-specifications may need an update to the auto-doc generation

[aidanheerdegen]

Questions and suggestions ...

[blimlim]

Thanks @joshuatorrance! I've taken a quick look at the changes and just had a couple of quick questions:

1. Are there any issues if the models use different conventions to the geospatial_lon_max, geospatial_lon_min variables for their longitude data? E.g. the atmosphere outputs in ESM1.6 use longitudes in [0, 360], the ocean seems to use [-280, 80]

2. I'm not on top of the details at all, but I believe the regional models can run with a rotated grid, e.g. In cases like this, I'm guessing the geospatial_..._max/min values wouldn't correspond to the exact bounding box for the dataset, but would contain it – would that cause any issues?

[joshuatorrance]

Thanks @joshuatorrance! I've taken a quick look at the changes and just had a couple of quick questions:

1. Are there any issues if the models use different conventions to the `geospatial_lon_max`, `geospatial_lon_min` variables for their longitude data? E.g. the atmosphere outputs in ESM1.6 use longitudes in [0, 360], the ocean seems to use [-280, 80]

2. I'm not on top of the details at all, but I believe the regional models can run with a rotated grid, [e.g](https://forum.access-hive.org.au/t/um-nesting-suite-lam-inclusion-grids-not-aligning/745/2). In cases like this, I'm guessing the `geospatial_..._max/min` values wouldn't correspond to the exact bounding box for the dataset, but would contain it – would that cause any issues?

1. If the models use different conventions for their actual lat/lon values then it's probably simpler to not have any restrictions on the values for the geospatial bounds. The translation isn't complicated for these and downstream tools will need to handle the translation for the values themselves anyway.
2. These values just describe the min/max for lat/lon so calculating their values may be trickier for rotated pole scenarios. They don't try to describe the bounding box for rotated poles, non-rectangular grids, etc., just the min/max values.