Feature: CMR Concept ID <-> Human Readible Name translation tool #57
Replies: 9 comments
-
Comment from Slack thread:
Just to expand a little bit - when making a request against the CMR GraphQL interface, you have to specify the fields you get back in the response. What I'm trying to think through is whether: a) Can this work be backed by CMR GraphQL to make more efficient queries? One really cool thing CMR GraphQL doesn't give, but this tool automatically does, is results from all of production, UAT and SIT. |
Beta Was this translation helpful? Give feedback.
-
@owenlittlejohns b) I'm almost certain we can make a custom field with graphql that could do this use-case (I've done something like this before on a personal project I think) c) we do support querying by shortname on cmr-graphql but, not short-name + version. I don't know how much trouble it would be to add that to graphql. I would think it wouldn't be crazy difficult since cmr supports it https://cmr.earthdata.nasa.gov/search/site/docs/search/api.html#c-version but, I'm not certain |
Beta Was this translation helpful? Give feedback.
-
Querying by short-name + version isn't desirable because you can only do so via a single record. Some time ago the DAACs got together and discussed this, the result was Entry ID which allows users to search to by the combination of short-name and version via a single, supported and indexed field. Looking through the docs, and testing a few responses, that value does not come back in either json or umm_json and should be added, that would seem to solve a pretty big need. With respect to the environments, SIT and UAT should be considered testing environments, I would not recommend features in production that provided the user base with test data. That being said, it has come up recently that the use of environments is useful from a curation perspective and there should be some discussion around that. So, if this library had a feature that would present these results, using supported params and keys that are indexed, that would be a neat feature of a tool. |
Beta Was this translation helpful? Give feedback.
-
Thanks everyone for sharing your thoughts! To clarify we don't use short_name + version to query collections for concept-ids, we use native-ids, which to some is the same as short_name + version, but this is not consistent across DAACs. I like the idea of using entry-id since that is the agreed upon field for short_name + version searches. |
Beta Was this translation helpful? Give feedback.
-
So, it seems like something that would be useful would be filing a ticket with CMR to expose Entry ID (there are multiple teams actually looking to utilize this in the short term) |
Beta Was this translation helpful? Give feedback.
-
Hey folks! Restarting this thread now that we are moving into the IP. What do you all think are our next steps? |
Beta Was this translation helpful? Give feedback.
-
@eni-awowale I'm late to the party but re-reading the thread it sounds like this got redirected into a feature request for CMR directly? Once searching by Entry ID is supported we could add that to this library and that would solve your original use case? |
Beta Was this translation helpful? Give feedback.
-
Hi @frankinspace ! Thanks for re-starting this thread. I wasn't aware that this got redirected into a feature request for CMR. Can you share it with me? I do think once searching via Entry ID is supported adding the CL functionality to this library would solve our original use case. |
Beta Was this translation helpful? Give feedback.
-
@eni-awowale That was meant as a question as I was reviewing the discussion on this issue; it sounds like the suggestion is work required by CMR to support Entry ID. I don't feel I have a strong enough grasp of the issue to make the request but maybe I can poke @abbottry to see if he would be willing to fill out that ticket to CMR and link it here? |
Beta Was this translation helpful? Give feedback.
-
Hi
python-cmr
folks,I'm a developer at GES DISC, and during a hackweek last week my colleague @eni-awowale created a CLI tool (tentatively named
CNR
: CMR Name Resolver) that translates concept_id's to native_ids (and vise-versa). It's not publically shareable at this point but if you have access to Earthdata bitbucket you can see our repo here: https://git.earthdata.nasa.gov/projects/GDDS/repos/cnr/browseAfter discussion with our manager @briannapagan we were wondering if this would be something you'd be interested in merging into
python-cmr
. Before opening any PRs I wanted to start a discussion on this to make sure 1) this is something you all are interested in having in this project and 2) we're on the same page for how to implement.The tool is a python script that gets installed as a CLI tool in the
./bin
directory of your python install by using[project.scripts]
inpyproject.toml
. Example usage:The full list of aceeptable arguments:
Beta Was this translation helpful? Give feedback.
All reactions