We at the LP DAAC have been noticing some inconsistencies with regards to interacting with the CMR API lately.
- First is that the temporal ranges don't seem to do what I would expect based on the documentation.
- Let's say I want to grab the AST_L1T v003 granules from 2016-10-10 at 01:38:36Z to 01:39:03Z. The query I would expect to make is this:
https://cmr.earthdata.nasa.gov/search/granules.json?pretty=true&short_name=AST_L1T&version=003&temporal[]=2016-10-10T01:38:36.000Z,2016-10-10T01:39:03.000Z
- This returns the following granules:
G1334068323-LPDAAC_ECS at time 2016-10-10T01:38:36.000Z
G1334312987-LPDAAC_ECS at time 2016-10-10T01:38:45.000Z
G1334312859-LPDAAC_ECS at time 2016-10-10T01:38:54.000Z
- Note that these granules are all from 01:38:xxZ.
- Now let's say I bump up my end time on my search by 1 second to 01:39:04Z using this query:
https://cmr.earthdata.nasa.gov/search/granules.json?pretty=true&short_name=AST_L1T&version=003&temporal[]=2016-10-10T01:38:36Z,2016-10-10T01:39:04Z
- Now I get back a fourth granule:
G1334068323-LPDAAC_ECS at time 2016-10-10T01:38:36.000Z
G1334312987-LPDAAC_ECS at time 2016-10-10T01:38:45.000Z
G1334312859-LPDAAC_ECS at time 2016-10-10T01:38:54.000Z
G1334312951-LPDAAC_ECS at time 2016-10-10T01:39:03.000Z- Note the time on that granule, it matches the exact time that I asked for in the first query.
- Let's say I want to grab the AST_L1T v003 granules from 2016-10-10 at 01:38:36Z to 01:39:03Z. The query I would expect to make is this:
Based on the documentation, it says "For temporal range search, the default is inclusive on the range boundaries." which to me says that any granules matching the dates I provide should be included in my results. This seems to work fine for the early/left side of the range, as the first granule returned matches my earliest date, but it doesn't work on the later/right side of the range.
Secondly, it doesn't seem like the option to flip the logic so that it excludes the boundary makes a difference on the results. If I add
"options[temporal][exclude_boundary]=true"
to the end for those queries, the results stay the same. I would expect the first granule to disappear in both cases since my earliest date matches the granules date exactly.
3 Comments
Michael Lubke
user-e43ec
user-7b92a
Thanks for notifying us of the problem. I filed CMR-3740 - Getting issue details... STATUS for this issue. It looks like there is a corner case in how Elasticsearch handles the underlying date matching.
siwei xu
We've decided to close CMR-3740 as working as expected.
The reason is I downloaded the granules in question and verified that the temporal values of these granules are actually NOT on the boundary of the temporal search:
G1334068323-LPDAAC_ECS: temporal value: 2016-10-10T01:38:36.483000Z
G1334312951-LPDAAC_ECS: temporal value: 2016-10-10T01:39:03.010000Z
Once that's taken into account, both the inclusive temporal search and the exclusive options worked fine.
However, the reason this issue came up was because the JSON response didn't display the fraction of the second, and the elastic search index retrieved didn't display that either. so we filed another ticket CMR-3828 to investigate that. Thank you.