Closed jbyrne6 closed 9 months ago
So, the logic here is:
if the cmr key [Collection]/SpatialExtent/HorizontalSpatialDomain/ResolutionAndCoordinateSystem
exists, look for the GenericResolutions
key. If GenericResolutions
is found, use that information to render the resolution label in the UI. If GenericResoultions
key does not exists, then that is an unexpected error and we render "Issue Loading Resolution" in the UI.
if the cmr key [Collection]/SpatialExtent/HorizontalSpatialDomain/ResolutionAndCoordinateSystem
does not exist: assume this was intentionally left out, render "Not Applicable" for the resolution label in the UI.
I think that makes sense to me but would appreciate @jjmcnelis opinion as well.
So, the logic here is:
if the cmr key
[Collection]/SpatialExtent/HorizontalSpatialDomain/ResolutionAndCoordinateSystem
exists, look for theGenericResolutions
key. IfGenericResolutions
is found, use that information to render the resolution label in the UI. IfGenericResoultions
key does not exists, then that is an unexpected error and we render "Issue Loading Resolution" in the UI.if the cmr key
[Collection]/SpatialExtent/HorizontalSpatialDomain/ResolutionAndCoordinateSystem
does not exist: assume this was intentionally left out, render "Not Applicable" for the resolution label in the UI.I think that makes sense to me but would appreciate @jjmcnelis opinion as well.
@frankinspace and @jbyrne6 -- Thanks for the opportunity to review. This logic described in your comment is appropriate, IMO. (So the only time we should see "Issue Loading Resolution" is in the rare case where a dataset has an alternative representation is given under HorizontalDataResolution subfield, e.g. https://cmr.earthdata.nasa.gov/search/collections.umm_json?provider=POCLOUD&ShortName=SEAGLIDER_GUAM_2019 and datasets with that characteristic are not likely to be in supported in hitide.)
Changes
Related Issues
48
52
49