You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand this cumulus-cnm-to-granule step generates the path field (which is needed by the following ingest-granule step) based on uri field (which comes from the original CNM message).
I noticed that during this step, the leading / will be removed in the path field, e.g.: "uri": "/data/Aura_OMI_Level2/OMNO2.003/2022/001/..."
will lead to: "path": "data/Aura_OMI_Level2/OMNO2.003/2022/001"
This causes consistency issues for your ingest pipeline, because our parsing PDR step will eventually generate: "path": "/data/Aura_OMI_Level2/OMNO2.003/2022/001"
which does include the leading / as shown above.
So, the question is: is there a good reason for CNM cumulus-cnm-to-granule step to remove the leading /? Is there anyway we can keep the leading / easily?
The text was updated successfully, but these errors were encountered:
I understand this
cumulus-cnm-to-granule
step generates thepath
field (which is needed by the following ingest-granule step) based onuri
field (which comes from the original CNM message).I noticed that during this step, the leading
/
will be removed in thepath
field, e.g.:"uri": "/data/Aura_OMI_Level2/OMNO2.003/2022/001/..."
will lead to:
"path": "data/Aura_OMI_Level2/OMNO2.003/2022/001"
This causes consistency issues for your ingest pipeline, because our parsing PDR step will eventually generate:
"path": "/data/Aura_OMI_Level2/OMNO2.003/2022/001"
which does include the leading
/
as shown above.So, the question is: is there a good reason for CNM
cumulus-cnm-to-granule
step to remove the leading/
? Is there anyway we can keep the leading/
easily?The text was updated successfully, but these errors were encountered: