Transect profile
Background
#1140
Why did you take this approach?
Anything in particular that should be highlighted?
Can only specify a point between the first two points of the transect.
Screenshot(s)
Checks
- [X] I ran unit tests.
- [X] I've tested the relevant changes from a user POV.
- [X] I've formatted my Python code using
black ..
Hint To run all python unit tests run the following command from the root repository directory:
bash run_python_tests.sh
Looks great so far! I think there's a couple small things we can do to help end users:
- Rename the checkbox to Extract Profile Plot so its more consistent with the other ONAV plotters
- Add the point coordinates for the profile to the plot title so that users can see exactly where the profile is located
- The profile y-axis ticks are right next to color bar's units label so it looks like the profile plot's vertical axis label is the variable. That might be confusing for users so maybe we can remove the vertical ticks?
- Add the variable unit to the profile plot's horizonal axis label
After doing some digging this afternoon it sounds like OpenLayers includes some functionality to calculate distance between two points. We can probably make use of that on the front end to give users more control over the profile location. This super old thread has some examples that might be helpful: https://stackoverflow.com/questions/10109620/openlayers-how-to-calculate-distance-between-two-points but there might be a more modern way to do it in the OpenLayers docs: https://openlayers.org/
Totally agree. I have pushed those readability changes.
I'll take a look at OpenLayers and see if we can have a more elegant solution for selecting the profile location. Also we may need to discuss how to handle transects with 3+ points as well as 'compare datasets' cases
I'm not sure if you've tackled the multi-segment distance issue yet but I noticed this when I tried a line with three points:
still looking into the multiple point functionality
Stumped as to why OpenLayers is giving a different distance value than the plot. I believe they are both using the same EPSG coordinates system.
Stumped as to why OpenLayers is giving a different distance value than the plot. I believe they are both using the same EPSG coordinates system.
It's really unusual, I would have expected to get the same value too. I'll take a closer look at it tomorrow morning.
pulled your changes and still have the issue. I noticed the original plot changes sizes when adding the profile plot. maybe it's an issue with the grid stuff?
I was just doing some testing and found a couple small things that could be improved:
- Add a timeout to the distance slider to prevent it from sending multiple plot requests while the user is adjusting the value. This seems to happen when you drag the slider thumb rather than click on the distance.
- Change the variable name on the profile x axis to the proper variable name. You can use the dataset_config.variable object to grab it.
- Double check that the vertical axis for the profile and transect are the same. Seems like the profile data extends deeper than the available data in the screenshot below:
The current behaviour is that the plot will update when the user hasn't moved the slider for at least 1 second. What do you suggest? As for that plot, checking the profile location in the title it seems that it is extracting a profile from past the second point of the plot right?
I tried making the timeout length longer but that didn't seem to work so after some digging I found that there's a onChangeComplete attribute you can use in later versions of rc-slider. This only calls the change handler function only when the user has finished moving the slider thumb which seems to fix the problem. If you go this route you wont need the timeouts either.
If you want to update the package on your dev environment and try it out go ahead, if not I can just commit the change I made.
As for the profile location I think you're right. It looks like the profile position doesn't correspond to a point on the line here. When I was looking into the calculated distances on the UI vs backend I found that they didn't always agree so that might be the issue here. If so you can try passing the line distance as a percentage of total distance value in the plot query. This way any difference in the two calculations won't matter.
because of the way the line distance calculation is handled on the backend, it looks like it would be twice as slow if I passed the distance as a percentage from the frontend and recalculated it. So I think the current behaviour where there may be a slight discrepancy between frontend and backend distances would be preferable to that. What do you think?
If the data in the plot is accurate then I don't think it will be a problem as is.