<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 13, 2019 at 12:07 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</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">> If the remote update feature will require extra build time configuration or<br>
> environment configuration, how will these users benefit? If you don't know<br>
> you're using PROJ, how do you know to enable this? Don't these users need<br>
> it on by default?<br>
<br>
Good point. I can imagine that an application with a GUI such as QGIS could <br>
ask the question to the user "QGIS might download resource files needed for <br>
coordinate transformation. Do you agree ?", and if they approve, set the <br>
appropriate environment variable.<br>
<br>
A realistic use case for this download-on-demand capaibility is that you know <br>
that PROJ exists, that you are going to use it, but you don't know in advance <br>
which part(s) of the world you're going to work on, and don't want to / cannot <br>
download data for the whole world in advance.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> I think there are also security considerations. Is PROJ proofed against<br>
> malicious grid files like our browsers are against malicious javascript?<br>
<br>
In that context, one should indeed have a deeper look at how it opens them and <br>
try to secure that (with the curent raw formats which are quite simple, that <br>
shouldn't be too challenging). That said, the resources it would fetch would <br>
not be random, so unless a hostile party manages to upload a corrupted file in <br>
the CDN storage (or changes entries in the local proj.db), the set of what is <br>
access should be rather well defined.<br>
<br>
Note: those concerns about security are already valid currently. For example <br>
if using a PROJ string with a geoidgrids/nadgrids parameter that points to a <br>
local file that would be hostile.<br>
<br>
> Somewhat off topic: should PROJ be returning incorrect results in the<br>
> absence of grid files? Should it not raise an exception instead?<br>
<br>
There's no such thing as a "correct result" regarding coordinate <br>
transformation that involve changes of datum. There are results that are more <br>
or less accurate given the possibilities offered in the database which are <br>
themselves somewhat arbitrarily available according to what national geodetic <br>
agencies have provided to EPSG, which tranformation methods are actually <br>
implemented in PROJ, etc. So depending on what is available and what your <br>
needs are, you could get a result that is correct with an accuracy of 100m, <br>
10m, 1m, 1cm...<br>
In reality, the difference of accuracy between using a 7-parameter Helmert <br>
transformation vs using a grid is quite often 1m vs 10cm, so raising an <br>
exception when the grid is not there could be over-zealous if the user hasn't <br>
required a particular level of acuracy and the result given by the 7-parameter <br>
Helmert is just fine for them.<br>
The lower level services of PROJ can give you the available possibilities, <br>
with their accuracy and if some resources are missing or not, and where they <br>
can be downloaded.<br></blockquote><div><br></div><div>Thanks for the explanation, Even!</div><div><br></div><div>I think I'll be in roughly the same situation as QGIS developers. Have you and Howard considered grids-on-demand as a PROJ API that developers could use in QGIS or Rasterio or gdalwarp? Or as a service like DNS? Something about having it built into the library feels not right to me. I'm trying to think of a precedent for this and am drawing a blank.</div><div><br></div><div>-- <br></div></div><div dir="ltr" class="gmail_signature"><div dir="ltr">Sean Gillies</div></div></div>