Page 1 of 1

Tile metadata in the GetCapabilities file

Posted: Thu Jun 10, 2021 1:13 pm America/New_York
by kdpenner
I emailed support and thought I'd post here as well.

I'm learning the basics of querying a WMTS server. There is a python library to do this but there must've been server side changes, as a query that once worked: ... image/jpeg

is broken.

Take the Landsat_WELD_CorrectedReflectance_TrueColor_Global_Annual image. I want to extract a region around some lon, lat. My understanding is that I need to determine the tile matrix, tile row, and tile col containing the lon and lat. For that I need the pixel scale (arcsec probably?) and tile dimensions. First question: where are these data?

I've parsed the GetCapabilities file.
>>> import requests
>>> from xml.etree import ElementTree
>>> xml_url = (" ... est/1.0.0/"
>>> resp = requests.get(xml_url)
>>> xml = ElementTree.fromstring(resp.content)
>>> contents = xml[-2]
>>> layer = contents.findall(".//*[.='Landsat_WELD_CorrectedReflectance_TrueColor_Global_Annual']..")[0]

Section 6.1 of the WMTS implementation standard has that TileMatrixSetLink has most (all?) of the parameters I need to determine which tiles to get. But the GetCapabilities file has only the pixel scale in meters:

>>> layer[5][0].tag
>>> layer[5][0].text
>>> layer[5][0].attrib

Are the metadata supposed to be there?

I have other questions but I'll pose those later.

Re: Tile metadata in the GetCapabilities file

Posted: Fri Jun 11, 2021 9:36 am America/New_York
by kdpenner
I figured it out. The data model is that TileMatrixSetLink points to the TileMatrixSet for 31.25m. TileMatrixSet lives in the Contents element.

Still, the Landsat data for tile matrices 5 and above are broken.

Re: Tile metadata in the GetCapabilities file

Posted: Tue Jun 22, 2021 1:10 pm America/New_York
by LP DAAC - jwilson
We have reached out to a Subject Matter Expert for any further guidance.

Re: Tile metadata in the GetCapabilities file

Posted: Wed Jul 07, 2021 3:42 pm America/New_York
by mwong4
This is a known issue with a recent release of our software. Instead of returning an "empty tile" JPG/PNG when there is no data visualized in the requested tile, a 404 is returned. Below, you can see this request work for the 0/0/0 tile. ... image/jpeg

It just so happens that the z/y/x tile you are requesting has no data. We are working a solution presently, though a 404 response may still occur in some instances (e.g. if an invalid date is requested). So, handling 404s is recommended.