<p>It seems like the GRIB format is being used to distribute the data (probably for storage, ease of processing?), while satellite SMAP doesn't fit under the GRIB standard (see available parameters supported in the GRIB standard <a href="https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-1.shtml" rel="nofollow noreferrer">here</a>). This is why the input code is 255 (i.e. &quot;missing&quot;).</p>
<p>I downloaded the file <code>20150402_20150404_anom1.grb2</code> and opened in Python using xarray 0.18.2 with cfgrib 0.9.10.1. I cannot see the anomalous longitude.</p>
<pre><code>&lt;xarray.Dataset&gt;
Dimensions:     (latitude: 1920, longitude: 2560)
Coordinates:
    time        datetime64[ns] 1970-01-01
    step        timedelta64[ns] 00:00:00
    level       float64 0.0
  * latitude    (latitude) float64 -89.95 -89.86 -89.77 ... 89.77 89.86 89.95
  * longitude   (longitude) float64 -179.9 -179.8 -179.6 ... 179.6 179.8 179.9
    valid_time  datetime64[ns] 1970-01-01
Data variables:
    unknown     (latitude, longitude) float32 nan nan nan nan ... nan nan nan
Attributes:
    GRIB_edition:            2
    GRIB_centre:             consensus
    GRIB_centreDescription:  Consensus
    GRIB_subCentre:          65535
    Conventions:             CF-1.7
    institution:             Consensus
    history:                 2023-01-17T15:53 GRIB to CDM+CF via cfgrib-0.9.1...
</code></pre>
<p>You can read and process the data in Python in any case using <code>'unknown'</code> as the variable name:</p>
<pre><code>ds = xr.open_dataset(...)
smap = ds.variables['unknown']
lon = ds.variables['longitude']
lat = ds.variables['latitude']
</code></pre>
<p><a href="https://i.sstatic.net/OYe7f.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/OYe7f.jpg" alt="2" /></a></p>

CC BY-SA 4.0
2023-01-18T09:04:34.967Z
My xarray version is `2022.12.0` where the anomalous longitude value appears. The problem disappears when downgraded to `0.18.2`.
irok94
CC BY-SA 4.0
2023-01-19T08:41:03.607Z
Notice that time stamps are incorrect in xarray and wgrib outputs. Is there anyway fix the time issue?
irok94
CC BY-SA 4.0
2023-01-19T15:43:09.900Z
Data in the grib files contain 3-day composites with start and end dates provided in the filename. Which is probably why the timestamp in the grib is 'incorrect', as there is only one 2D array. I would use cdo if you really wanted to change the timestamp in the file:`cdo settaxis,2015-04-02,00:00,1day 20150402_20150404_anom1.grb2 out.grb2`
Ingvar Lukas
CC BY-SA 4.0
2023-01-17T14:29:07.967Z
2023-01-17T14:29:07.967Z
Ingvar Lukas
<p>While reading the <a href="https://gimms.gsfc.nasa.gov/SMOS/SMAP/L04/" rel="nofollow noreferrer">SMAP</a> data (grib format) using xarray with cfgrib as engine, the variable is shown as <code>unknown</code> and the longitude of the data has a value of around 539 which shouldn't be possible. I assume the variable being identified as `Unknown may be due to the missing grib table for the SMAP data. Summary of data read using xarray is given below:</p>
<pre><code>&lt;xarray.Dataset&gt;
Dimensions:     (latitude: 1920, longitude: 2560)

Coordinates:
    time        datetime64[ns] ...
    step        timedelta64[ns] ...
    level       float64 ...
  * latitude    (latitude) float64 -89.95 -89.86 -89.77 ... 89.77 89.86 89.95
  * longitude   (longitude) float64 -179.9 -179.8 -179.6 ... 179.6 179.8 539.9
    valid_time  datetime64[ns] ...
Data variables:
    unknown     (latitude, longitude) float32 ...
Attributes:
    GRIB_edition:            2
    GRIB_centre:             consensus
    GRIB_centreDescription:  Consensus
    GRIB_subCentre:          65535
    Conventions:             CF-1.7
    institution:             Consensus
    history:                 2023-01-17T14:45 GRIB to CDM+CF via cfgrib-0.9.1...
</code></pre>
<p>The output of wgrib2 is given below:</p>
<pre><code>** WARNING input Code Table 4.3 = 255 (undefined) for 20150402_20150404_anom1.grb2 **
1:0:d=1970010100:var discipline=1 master_table=2 parmcat=255 parm=255:reserved:anl:
</code></pre>

<python><soil-moisture>
Read SMAP grib data using python
irok94
# Read SMAP grib data using python

(Asked by: username_0 on 2023-01-17)

While reading the [SMAP](https://gimms.gsfc.nasa.gov/SMOS/SMAP/L04/) data (grib format) using xarray with cfgrib as engine, the variable is shown as `unknown` and the longitude of the data has a value of around 539 which shouldn't be possible. I assume the variable being identified as `Unknown may be due to the missing grib table for the SMAP data. Summary of data read using xarray is given below:

```
<xarray.Dataset>
Dimensions:     (latitude: 1920, longitude: 2560)

Coordinates:
    time        datetime64[ns] ...
    step        timedelta64[ns] ...
    level       float64 ...
  * latitude    (latitude) float64 -89.95 -89.86 -89.77 ... 89.77 89.86 89.95
  * longitude   (longitude) float64 -179.9 -179.8 -179.6 ... 179.6 179.8 539.9
    valid_time  datetime64[ns] ...
Data variables:
    unknown     (latitude, longitude) float32 ...
Attributes:
    GRIB_edition:            2
    GRIB_centre:             consensus
    GRIB_centreDescription:  Consensus
    GRIB_subCentre:          65535
    Conventions:             CF-1.7
    institution:             Consensus
    history:                 2023-01-17T14:45 GRIB to CDM+CF via cfgrib-0.9.1...

```

The output of wgrib2 is given below:

```
** WARNING input Code Table 4.3 = 255 (undefined) for 20150402_20150404_anom1.grb2 **
1:0:d=1970010100:var discipline=1 master_table=2 parmcat=255 parm=255:reserved:anl:

```

**Tags:** python, soil-moisture


---

## 1 answers

### Answer by username_1 on 2023-01-17. Score: 3

It seems like the GRIB format is being used to distribute the data (probably for storage, ease of processing?), while satellite SMAP doesn't fit under the GRIB standard (see available parameters supported in the GRIB standard [here](https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-1.shtml)). This is why the input code is 255 (i.e. "missing").

I downloaded the file `20150402_20150404_anom1.grb2` and opened in Python using xarray 0.18.2 with cfgrib 0.9.10.1. I cannot see the anomalous longitude.

```
<xarray.Dataset>
Dimensions:     (latitude: 1920, longitude: 2560)
Coordinates:
    time        datetime64[ns] 1970-01-01
    step        timedelta64[ns] 00:00:00
    level       float64 0.0
  * latitude    (latitude) float64 -89.95 -89.86 -89.77 ... 89.77 89.86 89.95
  * longitude   (longitude) float64 -179.9 -179.8 -179.6 ... 179.6 179.8 179.9
    valid_time  datetime64[ns] 1970-01-01
Data variables:
    unknown     (latitude, longitude) float32 nan nan nan nan ... nan nan nan
Attributes:
    GRIB_edition:            2
    GRIB_centre:             consensus
    GRIB_centreDescription:  Consensus
    GRIB_subCentre:          65535
    Conventions:             CF-1.7
    institution:             Consensus
    history:                 2023-01-17T15:53 GRIB to CDM+CF via cfgrib-0.9.1...

```

You can read and process the data in Python in any case using `'unknown'` as the variable name:

```
ds = xr.open_dataset(...)
smap = ds.variables['unknown']
lon = ds.variables['longitude']
lat = ds.variables['latitude']

```

[![2](https://i.sstatic.net/OYe7f.jpg)](https://i.sstatic.net/OYe7f.jpg)

> **Comments:**
> **username_0**: My xarray version is `2022.12.0` where the anomalous longitude value appears. The problem disappears when downgraded to `0.18.2`.  
> **username_0**: Notice that time stamps are incorrect in xarray and wgrib outputs. Is there anyway fix the time issue?  
> **username_1**: Data in the grib files contain 3-day composites with start and end dates provided in the filename. Which is probably why the timestamp in the grib is 'incorrect', as there is only one 2D array. I would use cdo if you really wanted to change the timestamp in the file:`cdo settaxis,2015-04-02,00:00,1day 20150402_20150404_anom1.grb2 out.grb2`  

---

