-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Use all nan values to represent a NULL QgsRectangle #54989
Conversation
393fbcf
to
52765a3
Compare
I've rebased to current master branch and also made ::setNull() use NaN to represent the null rectangle and ::isNull() only accepting that representation. |
QGIS server seem to have a problem with nan values in rectangles: |
This was suggested by Benoit in qgis#54646 (comment)
5f6c92f
to
d17982e
Compare
The failure is due to QgsMapRendererJob::prepareJobs not checking to see if the visibleExtent is null or not. When it is null, it obviously fail to reproject. I guess if the visible extent is null that method should just do nothing ? \cc @elpaso |
Beside, mSettings.visibleExtent() is called for every iteration but it doesn't need to ? |
I think the problem is with the semantic of QgsRectangle::isFinite() that would always be false for null rectangles, making it kind of useless |
9f1e278
to
df759e4
Compare
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 21 days. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the QGIS project can do to help push this PR forward please let us know how we can assist. |
This was suggested by Benoit in
#54646 (comment)
It may make it easier to spot missing isNull() checks by callers.
I'm pretty sure things will fail but chances are that merging various commits currently in other PRs could show why they are needed.
See for instance GH-54976 and GH-54954
I'm marking this as an API break, correct me if I'm wrong