include offline proj-data

[michaelkirk]

In #124, we discovered that macos was giving slightly different results when using libproj from homebrew.

My deduction is that this is because, as of Homebrew/homebrew-core@b3e7a63, libproj from homebrew includes proj-data.

I'm not 100%, but I believe these are the "grids" used for more accurate projections - identical to what you'd get when enabling the network feature. (Is that right?).

Is it worth including a way (a feature?) for users to install the whole file up front?

Or alternatively, maybe just some documentation explaining that, if they want to use the more accurate grids without the network feature, that they should use an external proj with those grids preinstalled — e.g. on mac: brew install proj, and presumably theres an apt package or option on linux.

[urschrei]

I'm not 100%, but I believe these are the "grids" used for more accurate projections - identical to what you'd get when enabling the network feature. (Is that right?).

Correct!

Is it worth including a way (a feature?) for users to install the whole file up front?

https://proj.org/resource_files.html#external-resources-and-packaged-grids

We need to figure out whether including this zip file would put us over the crates.io size limit. I suspect that it would, but will confirm this. However, if it's generally considered acceptable for a build script to have network access, we could grab the zip (from…somewhere) at build time instead?

[urschrei]

Update: the compressed data is around 562 MB, so we can't include it, or make it available as a separate crate. It would have to be provided at build time via zip download.

[urschrei]

The file in question is available from GitHub releases (https://github.com/OSGeo/PROJ-data/releases) but I don't know whether it's acceptable from a reliability standpoint to depend on GitHub (is using releases in this way against their acceptable usage policy?) in this way. One can imagine a scenario where this is part of someone's CI pipeline and the endpoint gets hit all the time etc – but maybe that's fine? Another question: would we fail a compilation if the file couldn't be downloaded?

It's also worth bearing in mind that for most use cases, network grid functionality is by far the better option, trading the necessity of network access for a much smaller download, and this was its explicit design goal.