Skip to content

add l1 dataset metadata#87

Open
hgloeckner wants to merge 4 commits intoorcestra-campaign:mainfrom
hgloeckner:add_dropsonde_data
Open

add l1 dataset metadata#87
hgloeckner wants to merge 4 commits intoorcestra-campaign:mainfrom
hgloeckner:add_dropsonde_data

Conversation

@hgloeckner
Copy link
Contributor

I tried to write a Metadata.yaml as described here...

Maybe you can check if it works in the browser in principle, then we can check if it's sufficient? Then I wondered how to best put that CID in. It makes more sense to me to have one of them for the whole L1 and not one for each flight, but currently I give the CIDs by flight into the tree.

I see two options:

  • have the cid as I put it now as another "top-level-folder"; however it currently contains the full Level 1 data; so for this option I should probably put the metadata yaml with a separate cid?
  • remove the folder structure and have just one top-level CID.

Do you have a preference?

@hgloeckner hgloeckner requested a review from lkluft October 19, 2025 20:27
@lkluft
Copy link
Contributor

lkluft commented Oct 20, 2025

Thanks for giving this a try! :)

Maybe you can check if it works in the browser in principle, then we can check if it's sufficient?

Well, there is no implementation, yet. But I will check if it adheres to our proposed YAML format and then we can build a prototype around the Level 1 data.

Then I wondered how to best put that CID in. It makes more sense to me to have one of them for the whole L1 and not one for each flight, but currently I give the CIDs by flight into the tree.

Our idea would be that each directory that contains a dataset_meta.yaml is treated as a dataset. In your case, I would have expected something like:

LeveL_1/
  dataset_meta.yaml
  HALO-20240809b/
  HALO-20240811a/
  HALO-20240813a/
  HALO-20240816a/
  HALO-20240818a/
  ...

Then you would create one CID for the whole Level_1 directory, which is then the Level 1 dataset—I guess this is similar to your seconds suggestion.

@hgloeckner hgloeckner marked this pull request as ready for review November 3, 2025 12:21
@lkluft
Copy link
Contributor

lkluft commented Feb 4, 2026

@d70-t @hgloeckner Admittedly, I lost overview on the status of this PR...

Is the content up-to-date? Are we able to parse non-Zarr metadata? My gut feeling is that the functionality in ipfsui is implement but not merged?

@hgloeckner
Copy link
Contributor Author

I think it was meant to test the functionality of ipfsui to handle non-zarr metadata.

Generally it is up-to-date, but we'll add some more metadata and probably have some revisions when the review for the beach draft is done, which will "only" be a couple more weeks. So... we could also wait and I update with the final data once we know what we need to change

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants