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.

Change History (0)

Note: See TracTickets for help on using tickets.