Ingest Request for MODIS_Terra_L3_NDVI_16Day

[veda-github-actor]

No description provided.

[github-actions]

Workflow Status

Starting workflow... View action run

Collection Publication Status

➡️ MODIS_Terra_L3_NDVI_16Day (Collection): Successfully published ✅

[hrodmn]

@kyle-lesinger thanks for testing out a collection with a WMTS layer - this is really cool!

I have been experimenting with the metadata fields and if we set them up well, tools like STAC Browser (or anything that uses ol-stac) can automatically display the layer map views 🪄.

It won't work on the version of STAC browser that we are running right now in VEDA (3.1), but when 3.4 is released the wmts link will be used to add a layer to the map view of the collection in STAC browser. Here is a view from a local instance:

I did some editing in my local copy and came up with this collection JSON

{
  "id": "MODIS_Terra_L3_NDVI_16Day",
  "dashboard:is_periodic": true,
  "dashboard:time_density": "day",
  "dashboard:time_interval": "P1D",
  "description": "The Vegetation Index (L3, 16-Day) layer is created from the Terra Moderate Resolution Imaging Spectroradiometer (MODIS) Vegetation Indices (MOD13Q1) data which are generated every 16 days at 250 meter (m) spatial resolution as a Level 3 product. The MOD13Q1 product provides the Normalized Difference Vegetation Index (NDVI) which is referred to as the continuity index to the existing National Oceanic and Atmospheric Administration-Advanced Very High Resolution Radiometer (NOAA-AVHRR) derived NDVI. The algorithm chooses the best available pixel value from all the acquisitions from the 16-day period. The criteria used is low clouds, low view angle, and the highest NDVI value. The MODIS Normalized Difference Vegetation Index (NDVI) complements NOAA's Advanced Very High Resolution Radiometer (AVHRR) NDVI products and provides continuity for time series historical applications. The MODIS NDVI product is computed from surface reflectances corrected for molecular scattering, ozone absorption, and aerosols. References: MOD13Q1 doi:10.5067/MODIS/MOD13Q1.061",
  "extent": {
    "spatial": {
      "bbox": [[-180, -90, 180, 90]]
    },
    "temporal": {
      "interval": [["2000-03-05T00:00:00Z", null]]
    }
  },
  "license": "CC0-1.0",
  "links": [
    {
      "href": "https://gibs.earthdata.nasa.gov/wmts/epsg3857/best/wmts.cgi",
      "rel": "wmts",
      "type": "image/png",
      "title": "Visualized through a WMTS",
      "wmts:layer": ["MODIS_Terra_L3_NDVI_16Day"],
      "wmts:dimensions": {
        "STYLE": "default"
      }
    }
  ],
  "product_level": "L3",
  "providers": [
    {
      "name": "NASA Global Imagery Browse Services (GIBS)",
      "roles": [["host"]],
      "url": "https://nasa-gibs.github.io/gibs-api-docs/gis-usage/"
    },
    {
      "name": "NASA Land Processes Distributed Active Archive Center (LP DAAC)",
      "roles": [["producer", "processor"]],
      "url": "https://www.earthdata.nasa.gov/centers/lp-daac"
    },
    {
      "name": "NASA's Earth Science Data and Information System (ESDIS)",
      "roles": [["licensor"]],
      "url": "https://www.earthdata.nasa.gov/about/esdis"
    }
  ],
  "stac_extensions": [
    "https://stac-extensions.github.io/web-map-links/v1.2.0/schema.json"
  ],
  "stac_version": "1.0.0",
  "title": "16-Day MODIS Terra Normalized Difference Vegetation Index (NDVI) - L3 NRT",
  "type": "Collection",
  "keywords": ["MODIS", "Terra", "NDVI"]
}

Is it ok if I push this version to the branch?

[hrodmn]

I have a few specific questions and a suggestion for the format of the wmts link metadata!

[hrodmn]

After some experimentation, this is what we need the wmts link to look like:

Suggested change

	{
	"href": "https://gibs.earthdata.nasa.gov/wmts/epsg3857/best/wmts.cgi",
	"rel": "wmts",
	"type": "image/png",
	"title": "Visualized through a WMTS",
	"href:servers": [
	"https://gibs-a.earthdata.nasa.gov/wmts/epsg3857/best/wmts.cgi",
	"https://gibs-b.earthdata.nasa.gov/wmts/epsg3857/best/wmts.cgi"
	],
	"wmts:dimensions": [
	"default"
	],
	"wmts:layers": [
	"MODIS_Terra_L3_NDVI_16Day"
	]
	}
	{
	"href": "https://gibs.earthdata.nasa.gov/wmts/epsg3857/best/wmts.cgi",
	"rel": "wmts",
	"type": "image/png",
	"title": "Visualized through a WMTS",
	"wmts:layer": ["MODIS_Terra_L3_NDVI_16Day"],
	"wmts:dimensions": {
	"STYLE": "default"
	}
	}

[kyle-lesinger]

After some experimentation, this is what we need the wmts link to look like:

@hrodmn Yes the more explicit calling of style: default seems appropriate. I did some more ingesting with Air Quality in dev and it seems like even if we set the dimension to time, it will automatically throwback to "STYLE: default". So while it appears unneeded, it would be good to keep it in the format that you presented (see below).

      "wmts:dimensions": {
        "STYLE": "default"
      }

[anayeaye]

@kyle-lesinger @hrodmn sorry for the noise, I have been trying to fix some json syntax errors I introduced by merging suggestions. RE the web map links, I'm thinking it is something like:

    {
	      "href": "https://{s}.earthdata.nasa.gov/wmts/epsg3857/best/wmts.cgi",
          "href:servers": [
	            "gibs-a",
	            "gibs-b"
	          ],
	      "rel": "wmts",
	      "type": "image/png",
	      "title": "Visualized through a WMTS",
	      "wmts:layer": ["MODIS_Terra_L3_NDVI_16Day"],
	      "wmts:dimensions": {
	        "STYLE": "default"
	      }

https://github.com/stac-extensions/web-map-links?tab=readme-ov-file#hrefservers

BUT I don't think the veda-ui code is taking that into account and we would need to sort out a a different handoff of the veda stac api response to the veda-ui which may be looking for something that doesn't quite align with the web-map-links spec even though it looks really close: https://github.com/NASA-IMPACT/veda-ui/pull/1644/files#diff-51d9ee79e77cc94b891a168ca648f90b458b5f81ef12e235705881bc5af03ec0R40 🤔

[hrodmn]

thanks for linking to the WMTS logic in veda-ui! based on that I think we should just put the basic GIBS url in the href slot and put the full alternate urls in href:servers (["https://gibs-a.earthdata.nasa.gov/wmts/epsg3857/best/wmts.cgi", "https://gibs-b.earthdata.nasa.gov/wmts/epsg3857/best/wmts.cgi"]). That arrangement would work for veda-ui and will work for STAC Browser's nice wmts map layer feature.

[hrodmn]

OR we could update veda-ui to handle href:servers and href like the spec suggests 😄

[hrodmn]

I am not exactly sure what these fields will get used for in veda-ui, but the temporal domain of the WMTS layer is defined in the xml that is returned by a getCapabilities request (https://gibs.earthdata.nasa.gov/wmts/epsg3857/best/wmts.cgi?service=wmts&request=GetCapabilities):

<Dimension>
  <ows:Identifier>Time</ows:Identifier>
  <ows:UOM>ISO8601</ows:UOM>
  <Default>2025-04-07</Default>
  <Current>false</Current>
  <Value>2000-03-05/2000-12-18/P16D</Value>
  <Value>2001-01-01/2001-12-19/P16D</Value>
  <Value>2002-01-01/2002-12-19/P16D</Value>
  <Value>2003-01-01/2003-12-19/P16D</Value>
  <Value>2004-01-01/2004-12-18/P16D</Value>
  <Value>2005-01-01/2005-12-19/P16D</Value>
  <Value>2006-01-01/2006-12-19/P16D</Value>
  <Value>2007-01-01/2007-12-19/P16D</Value>
  <Value>2008-01-01/2008-12-18/P16D</Value>
  <Value>2009-01-01/2009-12-19/P16D</Value>
  <Value>2010-01-01/2010-12-19/P16D</Value>
  <Value>2011-01-01/2011-12-19/P16D</Value>
  <Value>2012-01-01/2012-12-18/P16D</Value>
  <Value>2013-01-01/2013-12-19/P16D</Value>
  <Value>2014-01-01/2014-12-19/P16D</Value>
  <Value>2015-01-01/2015-12-19/P16D</Value>
  <Value>2016-01-01/2016-12-18/P16D</Value>
  <Value>2017-01-01/2017-12-19/P16D</Value>
  <Value>2018-01-01/2018-12-19/P16D</Value>
  <Value>2019-01-01/2019-12-19/P16D</Value>
  <Value>2020-01-01/2020-12-18/P16D</Value>
  <Value>2021-01-01/2021-12-19/P16D</Value>
  <Value>2022-01-01/2022-12-19/P16D</Value>
  <Value>2023-01-01/2023-12-19/P16D</Value>
  <Value>2024-01-01/2024-01-01/P8D</Value>
  <Value>2024-01-17/2024-01-17/P8D</Value>
  <Value>2024-02-02/2024-02-02/P8D</Value>
  <Value>2024-02-18/2024-02-18/P8D</Value>
  <Value>2024-03-05/2024-03-05/P8D</Value>
  <Value>2024-03-21/2024-03-21/P8D</Value>
  <Value>2024-04-06/2024-04-06/P8D</Value>
  <Value>2024-04-22/2024-04-22/P8D</Value>
  <Value>2024-05-08/2024-05-08/P8D</Value>
  <Value>2024-05-24/2024-05-24/P8D</Value>
  <Value>2024-06-09/2024-06-09/P8D</Value>
  <Value>2024-06-25/2024-06-25/P8D</Value>
  <Value>2024-07-11/2024-07-11/P8D</Value>
  <Value>2024-07-27/2024-07-27/P8D</Value>
  <Value>2024-08-12/2024-08-12/P8D</Value>
  <Value>2024-08-28/2024-08-28/P8D</Value>
  <Value>2024-09-13/2024-09-13/P8D</Value>
  <Value>2024-09-29/2024-09-29/P8D</Value>
  <Value>2024-10-15/2024-10-15/P8D</Value>
  <Value>2024-10-31/2024-10-31/P8D</Value>
  <Value>2024-11-16/2024-11-16/P8D</Value>
  <Value>2024-12-02/2024-12-02/P8D</Value>
  <Value>2024-12-18/2024-12-18/P8D</Value>
  <Value>2025-01-01/2025-01-01/P8D</Value>
  <Value>2025-01-17/2025-01-17/P8D</Value>
  <Value>2025-02-02/2025-02-02/P8D</Value>
  <Value>2025-02-18/2025-02-18/P8D</Value>
  <Value>2025-03-06/2025-03-06/P8D</Value>
  <Value>2025-03-22/2025-03-22/P8D</Value>
  <Value>2025-04-07/2025-04-07/P8D</Value>
</Dimension>

Should we be trying to populate veda-ui using the information direct from the source?

[kyle-lesinger]

@hrodmn I think that depends on how flexible veda-ui should be. There are a lot of datasets within GIBS that use a common template, but there are other WMTS layers (like ArcGIS or USGS) that do not have the same template - specifically no time attribute. I believe this means that we would have to manually assign the temporal frequency for different WMTS layers but we currently do not have any requests to bring in new datasets.

We were initially going to identify different WMTS structures but then that idea was scrapped since Water Insight decided that they just wanted static images instead of waiting for us to generate new veda-ui functionality.

Hopefully this provides a little guidance, but I think whatever decision you make will be the best!

[anayeaye]

@acblackford it sounds like this is working for the current dashboard use case now and we should publish to production with the expectation that we may want to revise some of the WMTS metadata in the future as we begin to identify best practices?