Re: PROJ grid files CDN

On Fri, Sep 13, 2019 at 12:07 PM Even Rouault <[email protected]>
wrote:

> > 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?
>
> Good point. I can imagine that an application with a GUI such as QGIS
> could
> ask the question to the user "QGIS might download resource files needed
> for
> coordinate transformation. Do you agree ?", and if they approve, set the
> appropriate environment variable.
>
> A realistic use case for this download-on-demand capaibility is that you
> know
> that PROJ exists, that you are going to use it, but you don't know in
> advance
> which part(s) of the world you're going to work on, and don't want to /
> cannot
> download data for the whole world in advance.


> >
> > I think there are also security considerations. Is PROJ proofed against
> > malicious grid files like our browsers are against malicious javascript?
>
> In that context, one should indeed have a deeper look at how it opens them
> and
> try to secure that (with the curent raw formats which are quite simple,
> that
> shouldn't be too challenging). That said, the resources it would fetch
> would
> not be random, so unless a hostile party manages to upload a corrupted
> file in
> the CDN storage (or changes entries in the local proj.db), the set of what
> is
> access should be rather well defined.
>
> Note: those concerns about security are already valid currently. For
> example
> if using a PROJ string with a geoidgrids/nadgrids parameter that points to
> a
> local file that would be hostile.
>
> > Somewhat off topic: should PROJ be returning incorrect results in the
> > absence of grid files? Should it not raise an exception instead?
>
> There's no such thing as a "correct result" regarding coordinate
> transformation that involve changes of datum. There are results that are
> more
> or less accurate given the possibilities offered in the database which are
> themselves somewhat arbitrarily available according to what national
> geodetic
> agencies have provided to EPSG, which tranformation methods are actually
> implemented in PROJ, etc. So depending on what is available and what your
> needs are, you could get a result that is correct with an accuracy of
> 100m,
> 10m, 1m, 1cm...
> In reality, the difference of accuracy between using a 7-parameter Helmert
> transformation vs using a grid is quite often 1m vs 10cm, so raising an
> exception when the grid is not there could be over-zealous if the user
> hasn't
> required a particular level of acuracy and the result given by the
> 7-parameter
> Helmert is just fine for them.
> The lower level services of PROJ can give you the available possibilities,
> with their accuracy and if some resources are missing or not, and where
> they
> can be downloaded.
>

Thanks for the explanation, Even!

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.

-- 
Sean Gillies

_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj