Closed asinghvi17 closed 2 years ago
Yeah I think making a more Julian API on top of the thinly wrapped ccalls would be a good improvement for the usability of the package.
Note that this package was created when PROJ 4 was out, and wrapped the PROJ 4 API. There are convenience funtions in here, but they are all tied to the PROJ 4 API. The PROJ 4 API is deprecated in PROJ and will be removed. The new PROJ 6 API is already thinly wrapped, but no convenience functions yet. This is all in proj_c.jl
and proj_common.jl
, which is completely isolated from the rest of the package. So I'd suggest we start building on the new API, not the old one :)
Has the higher level API been implemented for the new Proj version? I just saw
https://github.com/JuliaGeo/Proj4.jl/blob/b9703624c5e1ba65e0237759b9dd139d34a1de16/src/proj_c.jl#L29-L44
and that looks like it would work well if we attach a GC finalizer when constructing a Projection
object (should just be finalizer(obj, obj -> proj_destroy(obj))
)
No so those two files are completely auto generated by the script under gen/. I would favor an approach that would keep allowing us to autogenerate the low level bindings (for keeping it up to date), either by modifying the gen script or adding stuff that builds on them in separate files.
I'll close this now that we have the Proj.Transformation
interface. That probably doesn't quite cover the Cartopy functions you mention. But we could also just document this, since they would be oneliners. Feel free to reopen if you have ideas.
Cartopy has a lot of convenience projection functions which are essentially easy-to-use wrappers around Proj4 syntax. Perhaps we should consider translating them here? I will create a prototype implementation in MakieGallery as well.