You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/raster_index/design_choices.md
+13Lines changed: 13 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,3 +46,16 @@ The downside here is that CRS information is duplicated in two places explicitly
46
46
### Don't like it?
47
47
48
48
We chose this approach to enable experimentation. It is entirely possible to experiment with other approaches. Please reach out if you have opinions on this topic.
49
+
50
+
## Handling the `GeoTransform` attribute
51
+
52
+
GDAL _chooses_ to track the affine transform using a `GeoTransform` attribute on a `spatial_ref` variable. The `"spatial_ref"` is a
53
+
"grid mapping" variable (as termed by the CF-conventions). It also records CRS information. Currently, our design is that
54
+
{py:class}`xproj.CRSIndex` controls the CRS information and handles the creation of the `"spatial_ref"` variable, or more generally,
55
+
the grid mapping variable. Thus, {py:class}`RasterIndex`_cannot_ keep the `"GeoTransform"` attribute on `"spatial_ref"` up-to-date
56
+
because it does not control it.
57
+
58
+
Thus, {py:func}`assign_index` will delete the `"GeoTransform"` attribute on the grid mapping variable if it is detected, after using it
59
+
to construct the affine matrix.
60
+
61
+
If you wish to extract the GeoTransform attribute to write it to a location of your choosing use {py:meth}`RasterIndex.as_geotransform`.
0 commit comments