a(nother) plan
Closed this issue · 6 comments
sooo ... @paleolimbot help me with MacOS configure instructs on CRAN for {PROJ}? I made a mess of it recently, but it's probably not that hard?
- update on CRAN with proper MacOS and Windows 6.3.1
- convert to headers
- slowly add func (all I need is source->target proj_trans(), but proj_create() wbg)
I had settled on
- not having Rcpp here
- always assuming long/lat order
- use rwinlib /tools for Windows, and MacOS configure by CRAN for static build (so currently at 6.3.1), but fine on 7 on Linux from what I've seen
- allowing PROJ to install but not be functional
(that way {reproj} handles what gets used, falling back to proj4 if necessary (which works in 4, 5, 6, and 7)
But all is up for grabs. If a full-blown standalone is not a good idea, then keep going with this?
Definitely best to keep linking...I agree with the maintenance effort thing but right now the maintenance effort of linking against many different versions of these libraries is duplicated by the maintainers of any package that uses the spatial stack...hardly efficient. But there are other ways to make the linking easier that I should put time into first (config script templates probably).
I'll have a look today and see if I can PR a fix to a few of these...I think you're bang on except that I think headers aren't a good fit here. If in some magical world there can be a package that exports the PROJ C API, that's probably all it should do.
I think an external pointer vector like geos uses might be good for projections (also helps with memory management, since external pointers are handled by the garbage collector). I'll experiment and see what I come up with.
Cool thanks, still a couple of things here I'm dim about, appreciate it!
(some thesis items require my attention...but this is the first spatial hacking I'll do on the tail end of that!)
Awesome, hope that's all smooth sailing for your thesis! I had forgotten about libgeos, in all the "no standalone" advice. I guess it's a little different for proj and geos compared to gdal, but there's still a few subtleties that aren't very clear to me. I'm a bit "out of vibe" atm, but hoping the passion returns soonish - I really need it, having reproj has been a real leap forward, with only two obstacles (I mucked up xyz transforms so geocent caused problems, and the static config for Mac is still obscure to me).
🙏
Having played with GDAL and this a bit, I think libproj might be the way to go...GEOS and PROJ are self-contained and can be combined in lots of cool ways with other packages (s2 is a good example)...the GDAL/GEOS/PROJ stack will always be its own internally-consistent thing and it doesn't make sense to have so many copies installed (including copies of the data on Mac/Windows? With potentially different configs for each copy? That part is very confusing to me). With libproj you can point it to whatever data directory/database you want and everything that depends on it will follow...very civilized. It's an uphill battle...I'll see what I can do.
It might be good to have a zoom chat sometime?
A tough time zone window but I'd be willing to make it work 🙂