Child pages
  • Temporal Search Inconsistencies with CMR API
Skip to end of metadata
Go to start of metadata

We at the LP DAAC have been noticing some inconsistencies with regards to interacting with the CMR API lately.

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.

  • No labels

3 Comments

  1. 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.

  2. 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.