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
The GEOCAT reader is written to expect the lat/lons contained within the file are on the fixed grid. Recently, a need has arisen to check metadata to ensure this is true and adjust the navigation appropriately.
Solution
Check the global metadata for alternative navigation flags
If necessary, use a swath definition to handle the datasets
Should a warning about resampling before writing be added to alter the user that the swath data will need to be resampled or should the reader automatically put the data on a ESPG:4326? This seems to be a deviation from how the readers typically work, but it would require anyone using the reader to add a resampling line to their scripts, if they do not already contain a resample line.
Describe any changes to existing user workflow
Some backwards compatibility should be handled within the reader by setting any metadata flags that did no previously exist to None, or to a value which indicates a fixed grid. I am not certain that resampling to a WGS84 grid within the reader is a good way to handle compatibility with existing scripts.
Possible changes for the user depending on the handling within the reader:
The potentially will have to resample the data before writing for proper geo-referencing within an existing workflow.
The resampling could affect performance.
The text was updated successfully, but these errors were encountered:
Feature Request
The GEOCAT reader is written to expect the lat/lons contained within the file are on the fixed grid. Recently, a need has arisen to check metadata to ensure this is true and adjust the navigation appropriately.
Solution
Check the global metadata for alternative navigation flags
If necessary, use a swath definition to handle the datasets
Should a warning about resampling before writing be added to alter the user that the swath data will need to be resampled or should the reader automatically put the data on a ESPG:4326? This seems to be a deviation from how the readers typically work, but it would require anyone using the reader to add a resampling line to their scripts, if they do not already contain a resample line.
Describe any changes to existing user workflow
Some backwards compatibility should be handled within the reader by setting any metadata flags that did no previously exist to None, or to a value which indicates a fixed grid. I am not certain that resampling to a WGS84 grid within the reader is a good way to handle compatibility with existing scripts.
Possible changes for the user depending on the handling within the reader:
The text was updated successfully, but these errors were encountered: