Skip to content

Use geospatial_vertical_units when inferring the length unit - #170

Closed
aarab-malik wants to merge 1 commit into
data-exp-lab:mainfrom
aarab-malik:vertical-units-length
Closed

aarab-malik wants to merge 1 commit into
data-exp-lab:mainfrom
aarab-malik:vertical-units-length

Conversation

@aarab-malik

Copy link
Copy Markdown

_infer_length_unit returned 1.0 as soon as a dataset had latitude and longitude, so it never looked at geospatial_vertical_units. A depth axis stored in km then got a code_length of 1 cm, and converting a physical length into code units was off by 1e5. Passing geometry= into the load call did not change that, because the check still used the inferred geometry.

I check geospatial_vertical_units first and only fall back to 1.0 for geodetic data when that attribute is missing. The reproducer from the issue is now a test in yt_xarray/tests/test_accesor.py.

Closes #167

Geodetic datasets were always assigned a length unit of 1.0 before
geospatial_vertical_units was checked, so code_length became 1 cm
even when the file recorded km. Check the attribute first.
@chrishavlin

Copy link
Copy Markdown
Collaborator

Hi @aarab-malik , thanks for the PR but I've actually already got a branch with the fix including more significant redesign.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

_infer_length_unit returns 1.0 (cm) for geodetic datasets even when geospatial_vertical_units is present

2 participants