Closed m-mohr closed 2 years ago
My experience with STAC thus far has been primarily on the creation side, not consumption. But I can see how this flag could be a useful way to unambiguously detect multiple no-data values, rather than having to parse the name
or description
fields.
That said, the examples where I've come across multiple no-data values are for "continuous" data, e.g., the VIIRS vegetation index products that have bands with a valid range of [-10000, 10000] and two no-data values of -13000 and -15000. If I were to add a classification extension to one of these bands, it would seem incomplete unless the valid data range was also described in a Class Object. I know this has come up before - thoughts?
That said, the examples where I've come across multiple no-data values are for "continuous" data, e.g., the VIIRS vegetation index products that have bands with a valid range of [-10000, 10000] and two no-data values of -13000 and -15000. If I were to add a classification extension to one of these bands, it would seem incomplete unless the valid data range was also described in a Class Object. I know this has come up before - thoughts?
Yes, as discussed yesterday this also applies for NOAA MRMS QPE. -1, -3 no-data, >= 0 valid values. It is incomplete, but that was what we agreed on, right? @pjhartzell At least, unless we add ranges.
Here's an example I created manually for QPE today:
{
"type": "Feature",
"stac_version": "1.0.0",
"id": "CONUS_MRMS_MultiSensor_QPE_24H_Pass2_00.00_20220530-120000",
"properties": {
"noaa_mrms_qpe:pass": 2,
"noaa_mrms_qpe:period": 24,
"description": "Multi-sensor accumulation 24-hour (2-hour latency) [mm]",
"datetime": "2022-05-30T12:00:00Z"
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
-130.0,
55.0
],
[
-60.0,
55.0
],
[
-60.0,
20.0
],
[
-130.0,
20.0
],
[
-130.0,
55.0
]
]
]
},
"links": [
{
"rel": "collection",
"href": "./collection.json",
"type": "application/json",
"title": "NOAA MRMS QPE 24-hour Pass 2"
}
],
"assets": {
"cog": {
"href": "MRMS_MultiSensor_QPE_24H_Pass2_00.00_20220530-120000.tif",
"roles": [
"data",
"cloud-optimized"
],
"type": "image/tiff; application=geotiff; profile=cloud-optimized",
"raster:bands": [
{
"spatial_resolution": 1000,
"unit": "mm",
"nodata": -3,
"data_type": "float64",
"classification:classes": [
{
"value": -3,
"name": "no-data",
"description": "No coverage or missing value (no-data)",
"nodata": true
}
]
}
],
"proj:shape": [
6553,
4279
],
"proj:transform": [
1189.1837785492494,
0.0,
-14471533.80310966,
0.0,
-1189.1837785492494,
7361866.113023454
],
"proj:epsg": 3857,
},
"grib2": {
"href": "MRMS_MultiSensor_QPE_24H_Pass2_00.00_20220530-120000.grib2",
"roles": [
"data",
"source"
],
"type": "application/wmo-GRIB2",
"raster:bands": [
{
"spatial_resolution": 1000,
"unit": "mm",
"data_type": "float64",
"classification:classes": [
{
"value": -1,
"name": "missing-value",
"description": "Missing value (no-data)",
"nodata": true
},
{
"value": -3,
"name": "no-coverage",
"description": "No coverage (no-data)",
"nodata": true
}
]
}
],
"proj:shape": [
7000,
3500
],
"proj:transform": [
0.009999999714244895,
0.0,
-129.99999999985712,
0.0,
-0.009999999714204058,
54.9999999998571
],
"proj:epsg": null,
"proj:projjson": {
"$schema": "https://proj.org/schemas/v0.4/projjson.schema.json",
"type": "GeographicCRS",
"name": "unknown",
"datum": {
"type": "GeodeticReferenceFrame",
"name": "unknown",
"ellipsoid": {
"name": "unknown",
"semi_major_axis": 6378160,
"inverse_flattening": 298.253916296469
}
},
"coordinate_system": {
"subtype": "ellipsoidal",
"axis": [
{
"name": "Longitude",
"abbreviation": "lon",
"direction": "east",
"unit": "degree"
},
{
"name": "Latitude",
"abbreviation": "lat",
"direction": "north",
"unit": "degree"
}
]
}
},
}
},
"bbox": [
-130.0,
20.0,
-60.0,
55.0
],
"stac_extensions": [
"https://raw.githubusercontent.com/stactools-packages/noaa-mrms-qpe/main/extension/schema.json",
"https://stac-extensions.github.io/raster/v1.1.0/schema.json",
"https://stac-extensions.github.io/classification/v1.1.0/schema.json",
"https://stac-extensions.github.io/projection/v1.0.0/schema.json"
],
"collection": "noaa-mrms-qpe-24h-pass2"
}
I'm a sucker for examples. 🙂
Yeah, I think this is fine. It's an optional field and it addresses a problem that we keep coming up against.
We can push off the use of a multiple values or a data range for value
until later.
Works for me too.
I opened an issue for the range issue... #33
To make it easier to detect (multiple) no-data values that are described using the Class Object, would you think that it makes sense to add a optional
nodata
boolean flag (default: false) to the class object? This could be a migration path for users that otherwise would be stuck with file extension v1.0.0.cc @pjhartzell