[PROJ] PROJ grid files CDN

[Sean Gillies]

Hi Howard

> However, a significant portion of don't-even-know-they're-using-PROJ
users could benefit from PROJ having the optional ability to do its best in
application of grid shifts.

If the remote update feature will require extra build time configuration or
environment configuration, how will these users benefit? If you don't know
you're using PROJ, how do you know to enable this? Don't these users need
it on by default?

I think there are also security considerations. Is PROJ proofed against
malicious grid files like our browsers are against malicious javascript?

Somewhat off topic: should PROJ be returning incorrect results in the
absence of grid files? Should it not raise an exception instead?


On Fri, Sep 13, 2019 at 8:03 AM Howard Butler <howard at hobu.co> wrote:

> All,
>
> A few days ago, I tweeted [1] looking for a CDN partner to help us
> incrementally distribute the shift files that PROJ uses. After that
> generated some connections from organizations willing to help, I'm now
> asking the community if there is support for such an idea.
>
> The current software approach PROJ uses to apply grid shifts works just
> fine, but it has one significant deficiency that can cause PROJ to generate
> "incorrect" results – the need for proper grid shift files. Incorrect
> results can happen due to missing shift data that users didn't know they
> needed to download and put in a magical directory. Some distributions do
> not ship full copies of the shift files due to their size, and new versions
> of the grid shift files are released at a different release cadence than
> the releases of distributions, the EPSG database, or PROJ itself.
>
> The current management of the grid shift files would be improved for many
> users by providing an optional online web service alternative for obtaining
> shift information. Some benefits of a web service approach include:
>
> * users no longer have to manually fetch grid files and place them in
> PROJ_LIB
> * full and accurate capability of the software would no longer require GBs
> of grid shift files
> * the web service can manage and provide proper versioning for the shift
> files
> * cache build up of the grid files could happen lazily so users end up
> locally mirroring what they actually use
>
> I recognize that many do not want PROJ reaching out to a web service, and
> I would propose that the machinery to do this would be optionally compiled
> and optionally activated via environment variable or some similar
> mechanism. However, a significant portion of
> don't-even-know-they're-using-PROJ users could benefit from PROJ having the
> optional ability to do its best in application of grid shifts.
>
> Does the PROJ community support such an idea? How does management of grid
> shift data impact your ability to use PROJ, and what ideas do you have to
> help us improve it?  If the feedback on this proposal is generally
> positive, I will work with Even on writing an RFC of a proposed
> implementation.
>
> Howard
>
> [1] https://twitter.com/howardbutler/status/1171778886646022145?s=20
>

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190913/179a4ff2/attachment-0001.html>