-
Notifications
You must be signed in to change notification settings - Fork 96
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
Support for accessing the SpatialRef
of GCPs.
#397
Conversation
cc: @mwielocha |
use crate::vsi::unlink_mem_file; | ||
use crate::DriverManager; | ||
use std::path::Path; | ||
|
||
#[cfg(feature = "ndarray")] | ||
use ndarray::arr2; | ||
|
||
macro_rules! fixture { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused here, but 😍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return None; | ||
} | ||
|
||
unsafe { SpatialRef::from_c_obj(c_ptr) }.ok() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this is leaking the No, it doesn't.OGRSpatialReferenceH
(check out the implementation of from_c_obj
).
Does foreign_types
really solve issues like this? I only skimmed your changes, but it would be great if it did.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lnicola It solves it in the sense that we can more accurately reflect the owned vs borrowed semantics described in the GDAL docs, in a principled manner. After digging into the Layer
and MDArray
bindings, I'm pretty sure we're either leaking resources or dangerously borrowing them (no proof yet, just suspicion). Using foreign_types
would also replace GeometryRef
and OwnedLayer
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be awesome, I'll try to look into it.
bors r+ |
397: Support for accessing the `SpatialRef` of GCPs. r=lnicola a=metasim - [X] I agree to follow the project's [code of conduct](https://github.com/georust/gdal/blob/master/CODE_OF_CONDUCT.md). - [X] I added an entry to `CHANGES.md` if knowledge of this change could be valuable to users. --- Also removes trailing use of old `fixture!` macro originally removed in #342 Co-authored-by: Simeon H.K. Fitch <[email protected]>
Build failed: |
These clippy lints are more and more ridiculous, I swear. |
Damnit. I'm running |
It doesn't fail on your branch, it fails after bors merges it into master, probably because we updated bitflags in the meantime. You might have started from a stale branch. |
bors retry |
397: Support for accessing the `SpatialRef` of GCPs. r=lnicola a=metasim - [X] I agree to follow the project's [code of conduct](https://github.com/georust/gdal/blob/master/CODE_OF_CONDUCT.md). - [X] I added an entry to `CHANGES.md` if knowledge of this change could be valuable to users. --- Also removes trailing use of old `fixture!` macro originally removed in #342 Co-authored-by: Simeon H.K. Fitch <[email protected]>
Canceled. |
bors retry |
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
For some reason, I'm still getting these clippy warnings locally, even with |
I had the other problem... even with everything updated I couldn't get the warnings to occur. :/ |
It's supposed to work, and it's fine on CI. Must be something weird on my system. |
CHANGES.md
if knowledge of this change could be valuable to users.Also removes trailing use of old
fixture!
macro originally removed in #342