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

i.atcorr: fix plot_filter in create_iwave #3911

Merged
merged 4 commits into from
Aug 23, 2024

Conversation

pesekon2
Copy link
Contributor

  • missing import of pyplot
  • figures not shown correctly
  • fix wrong axes

* missing import of pyplot

* figures not shown correctly

* fix wrong axes
@pesekon2 pesekon2 added bug Something isn't working Python Related code is in Python imagery labels Jun 20, 2024
@pesekon2 pesekon2 self-assigned this Jun 20, 2024
Copy link
Member

@echoix echoix left a comment

Choose a reason for hiding this comment

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

Just like this, this PR changes the behaviour of the function. It's not exactly the same. To know if it's safe and reasonable, I'd need to know a bit more on the context and how it is used.

Is it a function part of "public api", ie used in user code in the wild, or just inside the file?

Before these changes, if I recall correctly, calling plot like this would add/change the currently active plot. In this PR, you are explicitly creating a new one, with new axes.

Before these changes, technically it would be possible to further edit the plot, and would have to call show() when needed (when it was that that was wanted, I usually returned the figure and axes for that in old code I did). Now, the function shows the plot directly here. Since only show() is used, it is a blocking function (I think it depends on the plotting backend though). For example, a non blocking call would be show(block=False) or show(blocking=False) (writing from memory, it's been years). A blocking call prevents other event processing in other parts of the code (but the new window will be able to do the interactions if the backend supports it).

So, just like this, I can't be sure if it's a safe change or not. It's maybe not a dead simple change.

@wenzeslaus
Copy link
Member

Is it a function part of "public api", ie used in user code in the wild, or just inside the file?

While the authors are free (and welcome) to make it more as an API, the function inside code for individual tools are not part of the API (only the CLI of the tool is), so any change which keeps the tool's functionality (as defined in the CLI) is fine.

Similarly, call to show is fine too because the function serves the tool, but is not meant to be used generally at this point (this is acceptable as long as it makes the coding simpler).

Copy link
Member

@wenzeslaus wenzeslaus left a comment

Choose a reason for hiding this comment

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

A screenshot would be nice for the review, but the change looks reasonable.

@pesekon2
Copy link
Contributor Author

Thanks for the reviews.

Attaching two screenshots (AVNIR and one of the Planetscopes) to keep them here as an illustration of the function's behaviour.

avnir

planetscope_0c

@pesekon2 pesekon2 merged commit 1205137 into OSGeo:main Aug 23, 2024
26 checks passed
@pesekon2 pesekon2 deleted the i_atcorr_fix_plot_filter branch August 23, 2024 08:13
@neteler neteler added this to the 8.5.0 milestone Aug 25, 2024
Mahesh1998 pushed a commit to Mahesh1998/grass that referenced this pull request Sep 19, 2024
* missing import of pyplot
* fix figures not shown correctly
* fix wrong axes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working imagery module Python Related code is in Python
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants