WCST_Import and Petascope_band, dimension metadata for netCDF encoding.

[Vlad Merticariu]

Currently, wcst_import only supports saving global metadata:

"metadata": {

"type": "json",
"global": {

"MarsType": "'${grib:marsType}'",
"Experiment": "'${grib:experimentVersionNumber}'"

}

}

This gets persisted in the gml:extraMetadata section of the coverage.

We need to allow the same for band-specific metadata. E.g. for a coverage having band chlor_a, we must allow:

"metadata": {

"type": "json",
"global": {

"MarsType": "'${grib:marsType}'",
"Experiment": "'${grib:experimentVersionNumber}'"

},
"chlor_a": {

"uom": "g/m^{3",
"Standard name": "Chlorophyll Concentration"}

}

}

This information should be persisted in the same place: the extraMetdata section of the coverage. When the coverage is encoded into a format that supports band specific metadata (e.g. netcdf), the saved metadata should be encoded in each band.

---

Update, using this example to import band and dimension metadata in general recipe

        "metadata": {
          "type": "xml",
          "global": {
	    "description": "'This file has 3 different nodata values for bands and they could be fetched implicitly.'",
            "resolution": "'1'"
          },
          // metadata of each band
          "bands": {
	      "red": {
		  "metadata1": "metadata_red1",
  		  "metadata2": "metadata_red2"
               },
	      "green": {
		  "metadata3": "metadata_green3",
  		  "metadata4": "metadata_green4"
               }, 
	      "blue": {
		  "metadata5": "metadata_blue5"  		  
               }
           },
          // meta data of each dimension (axis)
	   "axes": {
	      "i": {
		   "metadata_i_1": "metadata_1",
		   "metadata_i_2": "metadata_2"
	       },
              "j": {
		   "metadata_j_1": "metadata_3"
	      }
           }
        },

[Bang Pham Huu]

I think the band metadata should be put inside a JSON object

"global": {
},
"band": {
 "chlor_a": {
     "uom": "g/m3",
      Standard name": "Chlorophyll Concentration"
   }  
}

it is clearer about the context of metadata.

[Bang Pham Huu]

I think it is much clearer if the band's metadata is put into the "bands" of "slicer" object and then n Petascope, it can put to <swe:field> …. </swe:field> instead of global: <gmlcov:metadata>.

"slicer": {
          "type": "netcdf",
          "pixelIsPoint": true,
          "bands": [
            {
              "name": "chlor_a",
              "description": "This one has problem with coefficient when slicing on a time axis.",              
              "identifier": "chlor_a",
              "nilValue": "-999"
            }
          ],

but need to check if swe element allowes it, if it is then this option is better for both WCST_Import and Petascope to support the band's metadata.

[Vlad Merticariu]

I already checked that and the schema of swe doesn't allow that. I think it's best we stick with the first option as it's most flexible and keeps the same level of nesting, irrespective of the metadata type.

[Bang Pham Huu]

Replying to vmerticariu:

I already checked that and the schema of swe doesn't allow that. I think it's best we stick with the first option as it's most flexible and keeps the same level of nesting, irrespective of the metadata type.

ok, then we will stick with the "global" metadata for coverage and bands as I checked the ingredient and it specified a place to do this.

"coverage": {
        "crs": "OGC/0/Index2D",
        ****"metadata"****: {
          "type": "json",
          "global": {
            "resolution": "'1'"
          }, 
          "bands": {
            ***********bands's metadata*********    
          }
        },

[Dimitar Misev]

For the rasql encode() you'd specify the metadata in each variable like this I believe:

  // Specify variable names, band ids (0-based), etc; the variables can be objects listing details 
  // like type, metadata and data for netCDF, or simply an array of variable names
  "variables": {
    "var1": { "metadata_key": "value", ... },
    "var2": { "metadata_key": "value", ... },
    ... 
  },