<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Willing to help vs committed to help it is a big difference. </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I support such an idea, but not through a voluntary base, maybe through OSGeo somehow?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Sep 2019 at 15:03, 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>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>