Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revamp repo and its purpose #32

Open
valentina-s opened this issue Mar 11, 2022 · 2 comments
Open

Revamp repo and its purpose #32

valentina-s opened this issue Mar 11, 2022 · 2 comments
Assignees

Comments

@valentina-s
Copy link
Contributor

I find the purpose of this repo kind of confusing. The name and the access.md file are focused on orca data. However, the description focuses and other folder focuses on software. The main focus seems on preprocessing software, since a lot of the more advanced software now is in other repos, so the scope can be updated.

I also find the diagram in the access.md very hard to read since it points leftwards! It most probably needs a caption, and there may be a better place for it, unless one has a better way to relate it to the access topic.

Maybe with some community suggestions/discussion the organization of this repo can be improved.

@paulcretu
Copy link
Member

paulcretu commented Mar 12, 2022

I agree @valentina-s, the original purpose of this repo was to provide access to the AWS data (instructions and software), kind of what orca-hls-utils is. Over time it became a catch-all for various data processing experiments. We should either clean it up or archive it. I'm not exactly sure what it should be—but I like the idea of having a single go-to repo for figuring out how to access the data.

Perhaps revamping the repo could be a part of orcasound/orcagsoc#32? If orca-hls-utils is improved, it might be good to move it into here (as the scope will expand beyond HLS to include FLAC data as well, and eventually metadata).

Or maybe it's fine to leave orca-hls-utils where it is, but make orcadata itself into a package that acts as an entrypoint for accessing data—basically some sort of high-level orcasound CLI. I always imagined doing something like:

> orcadata list nodes
> orcadata list audio --node <node_name>
> orcadata get audio --node <node_name> --format hls <start_date> <end_date>
> orcadata get detections --node <node_name> --format json <start_date> <end_date>
> orcadata get ais --node <node_name> --format csv <start_date> <end_date>
> orcadata get ooi --node <node_name> <start_date> <end_date>

as well as having an SDK so other tools can automatically use the commands programmatically. We could even hook up data processing commands:

> orcadata spectrogram --node <node_name> <start_date> <end_date>
> orcadata convert hls-to-wav <directory>

@scottveirs
Copy link
Member

In today's standup, @valentina-s announced/demoed that she had fixed the right-to-left diagram by making it "read" left-to-right!

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

No branches or pull requests

4 participants