search

OSOceanAcoustics / echoshader

Interactive visualization of ocean sonar data
https://echoshader.readthedocs.io
MIT License
9 stars 8 forks source link

Design the APIs for use as widgets (Updating) #34

Closed ldr426 closed 1 year ago

ldr426 commented 2 years ago

Ideas

Ms @leewujung once reminded me to include some thoughts in my proposal on how I would design the API for use as widgets. But the day when Ms Lee gave this advice is already the deadline for GSoC application. I don't have enought time to add the design patterns in the proposal. I will list some thoughts there in the next few days.

ldr426 commented 2 years ago

For visualizing sonar data as a stack of cards in https://github.com/OSOceanAcoustics/echoshader/issues/17#issue-1168669060

Slice diagram

image

Bird's-eye view

image

ldr426 commented 2 years ago

For visualizing sonar data as a data cube in https://github.com/OSOceanAcoustics/echoshader/issues/17#issue-1168669060

Prototype

made by balsamiq image

ldr426 commented 2 years ago

For plotting statistics from sonar data interactively in https://github.com/OSOceanAcoustics/echoshader/issues/20#issue-1168728349

Prototype

made by balsamiq image

ldr426 commented 2 years ago

For Interactive visualization of sonar data and geospatial location in https://github.com/OSOceanAcoustics/echoshader/issues/18#issue-1168692706

Prototype

made by balsamiq image

ldr426 commented 2 years ago

For 3D echogram curtain along ship track in https://github.com/OSOceanAcoustics/echoshader/issues/26#issue-1169037627

This part can link the aerial view of the ship track in 2D and map with editable box. We can use editable box in echogram and map to specify the area of this 3D curtain.

Prototype

made by balsamiq image

ldr426 commented 2 years ago

Ms @leewujung : Just done the design patterns which are not included in the proposal. These are just sketchy prototypes to demonstrate core functionality. I will add more components to do some styling work( like add css in html 😏). Please tell me what components or functions you want to add in these prototypes. 😄 It would be wonderful to create a comprehensive and detailed prototype before coding begins!

leewujung commented 2 years ago

Hey @ldr426 -- thanks for putting together these! I think these are great that it helps one think very clearly on what are the parameters needed for each form of the visual displays.

By API I was actually referring to the programmatic design of how we structure the echoshader library and how users would interact with it. But after thinking about this some more, I think this part is better done via in-depth discussions between contributors and the mentor team. We can continue to brainstorm here, but for sure we as a team need to talk more once the program actually starts.

There are a few things that we should think about:

Haha, the above has become a sprawling comment. We can move them to a separate issue at some point, once we have more thoughts flushed out.

ldr426 commented 2 years ago

Ms @leewujung: Aha. Although not the API design you referred to, API design also includes HCI(Human-Computer Interaction) design. Programmatic design is on stage next. :)) Let's do top-down design first, then bottom-up programming and assembly!

Q1

What are the common set of components that we can specify, probably using param?

There are four APIs to create components and UI including using param. And I do agree we should use param library to specify components and do linking. We can create a module to store component parameters generated by param. It is kind of like separating data and view in some backend frameworks. Then define a CommonComponents class, which includes the most common components and parameters. All other component sets are its subclasses. It will be easy to locate and operate if needing to customize components and parameters. May call this as 'configuration centralization'. Another benefit for param is using decorator would make the code methodical. Also add several modules to do other configs, like adding inline color bars for maps and images.

Q4

In terms of structuring the library, between Declarative Panels, widgets and params, and templates, where do we want each of our visualization options to sit?

As we mentioned above, create a module to store widgets and params. Similarly, create another module called plot.py to store declarative panels. Users call this module to plot and combine what they want.

ldr426 commented 2 years ago

Ms @leewujung:

Q2

How/where do we define the parameters/components interaction with the underlying echodata (like slicing a particular frequency)? When does computation get executed?

Nomral view and 3D echodata are easy to do slicing by using existing tools. Core components are included in above prototype. For birds'-eye view, we can define depth range component and data range component to show the level. Also add a select component to select Time of Day(dimension: 24 hr x total number of days selected like below) or Time of Week(dimension: 7 days x total number of weeks selected). Ms @leewujung once you said from the birds'-eye view we can watch how the animal migration wrt sunlight hours changes over season, the diel vertical migration. Setting up Time of Week can offer a wider view. Also add a toggle to swith between noraml view and birds'-eye view.

For computation in birds'-eye view, my idea is to develop a module to do computation work which plotting calls . We don't need to reshape the whole data before plotting. Once users specify frequency, depth and time selection, then the module create a xarray slice for plotting.

Q3

point the source to a folder with whole bunch of files and wanting to display them

We can create a module to display the data processed by echopype and files info by using Dataframe or Tabulator. Not sure if it is what you mean.

for display involving lat/lon

If this mapping relation is needed in plotting only, we could create a new module in ehcoshader to execute it, that is good for modular programming and decoupling. I have no idea if this mapping is used anywhere else. But achieving this in echopype could make responsibilities of each library clear. The final dimension and time points should be identical to the Sv data. But the number of latitude and longitude data points is about three times that of Sv data. Also the ping_time is not a subset of location_time. So there must be some matrix reduction and mapping work. This computation can be done before plotting map and curtain. Also add a Dataframe to show this kind of mapping relations (users get a copy of the interpolated data back) and create a file to store it.

leewujung commented 1 year ago

This is another good reference issue that I'll be closing now to declutter. But I've added the "good reference" label so that we can find this easily.