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

Feature: cuboids_from_id #78

Open
wants to merge 4 commits into
base: integration
Choose a base branch
from
Open

Feature: cuboids_from_id #78

wants to merge 4 commits into from

Conversation

dxenes1
Copy link
Contributor

@dxenes1 dxenes1 commented Mar 19, 2021

Draft PR because I haven't added tests.

For applications in proofreading and meshing it's useful to have a way to get the cuboids that specifically belong to one ID. This functionality existed as an intermediate product of indexing and bounding boxes, so I just yanked some of that code to create a cuboid_from_id() function that returns the list of cuboid corners that contain a particular ID.

This PR adds the URL and View functions in Django. The URL is formatted in this way:
{base_url}/v1/cuboidsfromid/:collection/:experiment:/channel/:resolution/:id

SPDB PR: jhuapl-boss/spdb#28

@dxenes1 dxenes1 marked this pull request as ready for review May 12, 2021 18:47
@j6k4m8
Copy link
Member

j6k4m8 commented May 16, 2021

As an end-user, I think it would make sense for either this endpoint or another to also tell me the cuboid size. We've been consistent with our cuboid sizes historically, but there's no reason for an end-user to know what it is a priori.

@movestill
Copy link
Member

As an end-user, I think it would make sense for either this endpoint or another to also tell me the cuboid size. We've been consistent with our cuboid sizes historically, but there's no reason for an end-user to know what it is a priori.

Good point, especially since we are planning to add that other storage type soon. 😄

@dxenes1
Copy link
Contributor Author

dxenes1 commented May 17, 2021

As an end-user, I think it would make sense for either this endpoint or another to also tell me the cuboid size. We've been consistent with our cuboid sizes historically, but there's no reason for an end-user to know what it is a priori.

Good point, especially since we are planning to add that other storage type soon. 😄

Thinking it should be part of a different endpoint since this requires datasets to be indexed and cuboid sizes matters for non-indexed datasets as well. Could add it to channel info probably?

@dxenes1
Copy link
Contributor Author

dxenes1 commented Aug 2, 2022

Tested and made sure it works in latest stack. Ready for merge pending approval.

@@ -0,0 +1,200 @@
# Copyright 2016 The Johns Hopkins University Applied Physics Laboratory
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2022

@@ -0,0 +1,45 @@
# Copyright 2016 The Johns Hopkins University Applied Physics Laboratory
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2022

@@ -0,0 +1,145 @@
# Copyright 2021 The Johns Hopkins University Applied Physics Laboratory
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2022

@@ -0,0 +1,24 @@
# Copyright 2021 The Johns Hopkins University Applied Physics Laboratory
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2022

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.

4 participants