Martijn Visser
Martijn Visser
This is the pipeline you are using, with the proj definition: ``` Transformation pipeline description: axis order change (2D) + WGS 84 to EGM2008 height (1) definition: proj=pipeline step proj=unitconvert...
Switching from using remote to local grid makes it 30x faster for me. Exactly how much will also depend on your network. ```julia using Proj, PROJ_jll # use projsync to...
```julia # read [lazzily] in EGM2008 geoid as a GeoArray with 1 minute resolution egm2008 = GeoArrays.read(geoid_file) ``` It's worth noting that this is not a lazy read, it read...
Yes I think it would be good to add it to the readme, it also took me some time to find the right steps. Would you want to add it?...
Hmm that's odd. Something similar to GDAL is done on loading Proj.jl: https://github.com/JuliaGeo/Proj.jl/blob/v1.4.0/src/Proj.jl#L129-L133 Did you load Proj first? Because if you only loaded PROJ_jll, this initialization code is not run.
Oh wait setting the path to the certificates in `libproj` only affects `libproj`, not applications like `projsync`. For those you have to set the `PROJ_CURL_CA_BUNDLE` environment variable, which you can...
I agree that the latter is nicer. It will be very breaking on course. But perhaps if we are bundling it with the other breaking PRs that are open, and...
Yes, the functions in `src/generated/libgeos_api.jl` and we generally wrap them in `geos_functions.jl` to offer a nicer API. And like you mention for `GEOSConcaveHull` that hasn't been done yet. That doesn't...
Similarly `GEOSConcaveHullByLength` needs to be wrapped, this came up in #182.
I never really planned to generate most of `geos_functions.jl`. You're right that a significant part follows the same patterns, and that could be automated. If it makes it easier to...