<div dir="ltr"><div dir="ltr">Hi Howard <div><br></div><div>> 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.<br></div><div><br></div><div>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?</div><div><br></div><div>I think there are also security considerations. Is PROJ proofed against malicious grid files like our browsers are against malicious javascript?</div><div><br></div><div>Somewhat off topic: should PROJ be returning incorrect results in the absence of grid files? Should it not raise an exception instead?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 13, 2019 at 8:03 AM Howard Butler <<a href="mailto:howard@hobu.co">howard@hobu.co</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
* users no longer have to manually fetch grid files and place them in PROJ_LIB<br>
* full and accurate capability of the software would no longer require GBs of grid shift files<br>
* the web service can manage and provide proper versioning for the shift files<br>
* cache build up of the grid files could happen lazily so users end up locally mirroring what they actually use<br>
<br>
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.  <br>
<br>
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. <br>
<br>
Howard<br>
<br>
[1] <a href="https://twitter.com/howardbutler/status/1171778886646022145?s=20" rel="noreferrer" target="_blank">https://twitter.com/howardbutler/status/1171778886646022145?s=20</a><br></blockquote></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Sean Gillies</div></div></div>