Add Proj::id_code and Proj::id_auth_name #204
Conversation
| pub fn id_code(&self) -> Result<&str, str::Utf8Error> { | ||
| let pj = self.c_proj as *const PJ; | ||
| let c_char = unsafe { proj_get_id_code(pj, 0) }; | ||
| let c_str = unsafe { CStr::from_ptr(c_char) }; |
There was a problem hiding this comment.
I believe there should be nullptr checking here as proj_get_id_code() might return null in case of error (typically if the CRS is custom and not tied to a known code), and https://doc.rust-lang.org/std/ffi/struct.CStr.html#method.from_ptr indicates the CStr::from_ptr() shouldn't be called with a null ptr
There was a problem hiding this comment.
When testing, I found that the Proj created by proj4str and esriwkt could not recognize the code and name。
There was a problem hiding this comment.
I found that the Proj created by proj4str and esriwkt could not recognize the code and name。
Yes, that's fully expected. Not all CRS representations contain an authority name and code
There was a problem hiding this comment.
If there are corresponding ideas or methods, converting them would be ideal.
There was a problem hiding this comment.
you can try using proj_identify() to find a known CRS that is identical to the current one, but there's no guarantee it will succeed. Custom CRS with custom projection parameter values are fully valid
| pub fn id_auth_name(&self) -> Result<&str, str::Utf8Error> { | ||
| let pj = self.c_proj as *const PJ; | ||
| let c_char = unsafe { proj_get_id_auth_name(pj, 0) }; | ||
| let c_str = unsafe { CStr::from_ptr(c_char) }; |
4 participants
Add method
to_epsgfor Proj, return epsg code