Opened 2 years ago
Last modified 2 years ago
#2606 closed enhancement
wcst_import - NEW - automate setting gridOrder in ingredients — at Initial Version
Reported by: | Bang Pham Huu | Owned by: | Bang Pham Huu |
---|---|---|---|
Priority: | major | Milestone: | 10.1 |
Component: | wcst_import | Version: | 10.0 |
Keywords: | Cc: | ||
Complexity: | Medium |
Description
``gridOrder`` - specify the grid order of axes defined by the coverage CRS. Axes of a CRS which is not part of the file CRS have gridOrder that is same as the order in the CRS definition. For example, if the coverage CRS is a compound CRS ``OGC/0/AnsiDate@EPSG/0/4326`` and data files themselves have CRS ``EPSG/0/4326``, then gridOrder for the ansi axis in ``OGC/0/AnsiDate`` will be 0, and the gridOrder of the ``EPSG/0/4326`` axes will follow with 1 and 2. If the CRS order was reversed to ``EPSG/0/4326@OGC/0/AnsiDate``, then the gridOrder of 4326 axes (Long/Lat) would be 0 and 1, and of AnsiDate (ansi) would be 2. Usually axes of non-file CRS (AnsiDate in this example) will also have setting ``dataBound: false``. Below we give hints on how to determine the gridOrder of axes in the file CRS. When data is imported with the ``gdal`` or ``grib`` slicer, generally the gridOrder is ``n`` for X axes (Longitude, E, ...), and ``n+1`` for Y axes (Latitude, N, ...). When importing data with the ``netcdf`` slicer, the gridOrder should usually match the dimension order of the imported variable, which can be checked with ``ncdump -h``; e.g. a variable ``float dc(time, lat, lon)`` will have gridOrder ``n`` for time, ``n+1`` for lat, and ``n+2`` for lon.
Note:
See TracTickets
for help on using tickets.