search

fraymio / modis-tools

Tools for working with the MODIS API and MODIS data.
Apache License 2.0
22 stars 11 forks source link

Query API using only short name and version #13

Closed amanbagrecha closed 2 years ago

amanbagrecha commented 2 years ago

First, thank you for open sourcing this amazing library. It really is fantastic as it can be expanded not just for MODIS but a ton of other EO datasets!

Is your feature request related to a problem? Please describe.

I see that the API currently uses doi as the parameter. This limits the ability to query/ fetch other datasets. Eg:

We are currently able to fetch only MODIS data since the doi is hard coded

The following is the end point the API is currently fetching

https://cmr.earthdata.nasa.gov/search/collections.json?doi=10.5067/MODIS/MOD13A1.006

But instead we could query the API only using short_name and version as shown below

https://cmr.earthdata.nasa.gov/search/collections.json?short_name=MOD13A1&version=006

Describe the solution you'd like

If we can exclude doi as parameter and instead use short_name and version it would help fetching other datasets as well.

For eg, the following two dataset can be queried in addition to current MODIS implementation.

  1. VIIRS/NPP Leaf Area Index/FPAR 8-Day L4 Global 500m SIN Grid V001 Provider: LPDAAC_ECS
  2. SMAP Enhanced L3 Radiometer Global Daily 9 km EASE-Grid Soil Moisture V004 Provider: NSIDC_ECS

Eg API end point:

https://cmr.earthdata.nasa.gov/search/collections.json?short_name=VNP15A2H&version=001

The current implementation would require us to change the doi to 10.5067/VIIRS for it make a request to the above end point.

Additional context

The current implementation only supports hdf file format, which can be extended to h5, nc and various popular file format.

Would appreciate your thoughts if there is any specific reason for having doi parameter for the end point.

jamie-sgro commented 2 years ago

Hi @amanbagrecha, thanks so much for this comprehensive review. You make wonderful points here about expanding the generalizability of MODIS tools. To answer your last question first, I don’t think there’s a super compelling reason not to softcode the doi. We would want to keep backwards compatibility in mind when looking into possible code changes. As for next steps, I absolutely invite you to fork the repo and draft up a PR if you would like. Otherwise we can include this Open Issue in our backlog which we would triage in the coming weeks/months.

amanbagrecha commented 2 years ago

Thanks @jamie-sgro for your input! I'd try to draft a PR within next couple of days and we can discuss any modification on the PR board.