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
Ocean data often comes on a curvilinear grid (i.e. the latitude and longitude axes are two dimensional). The current Crop module implements xml_to_nc.py, which uses CDAT (and the cdms2 library in particular) to crop the latitudinal and longitudinal dimensions. 'cdms2' can't handle cropping of two dimensional lat/lon axes, so if people would like to be able to crop ocean data on its native grid (i.e. rather than regridding first to convert the lat and lon axes to one dimensional) then someone will need to write a module to implement the cdo sellonlatbox function, which can handle curvilinear grids.
The text was updated successfully, but these errors were encountered:
I agree - a more modular approach with this could be a good way to go. As the xml_to_nc.py performs a couple of different functions (checking bounds, cropping, converting from xml to nc), it is probably better to have a 'sanity checker', a cropper and a xml converter as separate scripts, even if they end up being wrapped in a single VisTrails module. That would deal with this nicely.
Ocean data often comes on a curvilinear grid (i.e. the latitude and longitude axes are two dimensional). The current
Crop
module implementsxml_to_nc.py
, which uses CDAT (and thecdms2
library in particular) to crop the latitudinal and longitudinal dimensions. 'cdms2' can't handle cropping of two dimensional lat/lon axes, so if people would like to be able to crop ocean data on its native grid (i.e. rather than regridding first to convert the lat and lon axes to one dimensional) then someone will need to write a module to implement thecdo sellonlatbox
function, which can handle curvilinear grids.The text was updated successfully, but these errors were encountered: