Rename package to Proj.jl #57
Conversation
This also changes the UUID and gives a breaking bump to the version number, as suggested in https://github.com/JuliaRegistries/General/#how-do-i-rename-an-existing-registered-package.
There are still some parts here that we may want to bring back, like higher level wrappers to the geodesic part of the library. But for now it is easier to remove all this.
Done by patching Clang.jl: use `strip` in `format_block(x::Clang.Paragraph, options)`.
From docstrings Parameters and Returns lists. Done by removing `push!(lines, "")` twice in Clang.jl
There was a problem hiding this comment.
Very cool. The generated docs look pretty useful already.
which is defined as
const Coord = SVector{4, Float64}
By the way I did the following recently in StaticArrays: JuliaArrays/StaticArrays.jl#980 ... which for Proj could be seen as useful (for projected CRSs) or confusing (for everything else). You're welcome / I'm sorry respectively 😅
Base exports ∘, compose can be imported manually.
Ha yes I saw that! I think for many cases it's quite nice to use. Perhaps we should document this, but then also warn about axis order. And |
Haha :-) I did joke that we were not going to use |
No API changes, it was a breaking release because the autotools build system was removed.
and use new keyword syntax
|
I was working on GeoMakie, and noticed that there is one feature which doesn't work all the time: inverse transformations. With some transformations, Proj errors out when applying the inverse transformation - the error message is something along the lines of "cannot construct a forward transformation". I think it might be worth it to include a |
|
Interesting. Do you have an example of a transformation for which that is the case, for testing? Probably indeed the FWD and INV method is better, since it seems closer to how PROJ is meant to be used. |
|
https://proj.org/operations/projections/igh.html and https://proj.org/operations/projections/nicol.html were what I tested with |
|
I've pushed a prototype to the branch |
|
Ubuntu fails on a network issue. There seem to be two possibly distinct issues: and Full logs here: https://github.com/JuliaGeo/Proj4.jl/runs/6261236370?check_suite_focus=true#step:6:334 |
Change `Coord` from being a `SVector{4, Float64}` alias to a struct implemented here. This struct is now mostly internal, since tuples are always returned from transformations. SVectors still work as input coordinates, just like tuples, vectors, and multiple arguments `f(x, y)`.
The `proj_context_set_ca_bundle_path` call in `__init__` only affects libproj, but not this command line call.
Such that the GitHub license detection will recognize it.
|
Nice! Congratulations on merging this 🥳 🎉 |
This renames the package to Proj.jl as discussed in #26. Proj4.jl currently wraps both the old and new API, and uses PROJ version 7.2. This also updates to PROJ 9.0. Since PROJ 8 the old API is removed however, making this a breaking release, and in my opinion a good time for the rename. This also will set the minimum supported Julia version to 1.6, since the PROJ_jll has that as well.
The new (Transformation / CoordinateTransformations) API is kept the same here. The wrapper generation code has been updated however, using the new Clang.jl. All the generated code is together in libproj.jl. This includes the geodesic code, all the geod_ * functions are there. I have not yet generated higher level geodesic code like in proj_geodesic.jl, perhaps it's fine to leave that for the future? If there is anything else important missing here, it'd be good to hear about that here.
This passes tests now, but I still marked it as a draft to play around a bit more with the generated code. Currently the only real replacement we do is to replace
PJ_COORDwithCoord, which is defined asconst Coord = SVector{4, Float64}. But perhaps we should give such a treatment also to other types likePJandPJ_AREA, which are now aPtr{Cvoid}, orPJ_PROJ_INFO. The PROJ data types are documented here. Input very welcome. Some of this behavior can also be controlled by Clang.jl generator options.Another TODO is to integrate
build_docstringfrom wrap_proj.jl and then delete this file in favor of generator.jl. Currently we use Clang.jl's new feature to parse the doxygen docstrings and add them, but we can probably improve them by parsing the Doxygen XML, this combination is also done in GDAL.jl. Although if it's not much improved I'd be happy to get rid of that code as well. Or maybe just write some good docstrings manually for the most important functions, and have generator.jl add them to libproj.jl. Edit: it does add quite a few more docstrings with the old doxygen.xml code, but I decided not to add it. Some docstrings were malformed. Plus I think that this code makes maintenance of this package harder.