[Proj] why doesn't the epsg file reference the hpgn grids?

[Even Rouault]

Selon Hermann Peifer <peifer at gmx.eu>:

> On 2015-03-18 2:59, Richard Greenwood wrote:
> >
> > Does the proj epsg file get created from data at www.epsg.org
> > <http://www.epsg.org>? And is that data lacking the reference to the
> > grid shift files, or is it "lost in translation"? It seems like there is
> > the wonderful resource in the harn grids that isn't getting used, but
> > maybe I'm overlooking something.
> >
>
> Here a few observations, from a simple user perspective:
> There is a somewhat complex (mysterious?) epsg-to-csv conversion process
> with "upstream" elements around libgeotiff and "downstream" locations
> near PROJ.4, which results in ever surprising changes in the generated
> lookup files.

As an open source code, there is no real "mystery" involved, although it is
indeed non trivial. The process is decently documented here :
http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README

>
> The changes are partly based on EPSG database updates (which is fine, of
> course) but also on changing conversion logic: about which parameter set
> to select in case of several available, which numeric precision to
> choose when converting radians from EPSG into arc seconds used in
> towgs84 values, and so on.
>
> There are plenty of helpful grid shift files listed at
> http://trac.osgeo.org/proj/wiki, but PROJ.4's epsg lookup table lists
> none of them, only the null grid appears there:
>
> $ grep nadgrids local/share/proj/epsg
> <3785> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
> +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs <>
> <3857> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
> +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs <>
>
> There haven't been many releases of PROJ lately, which brought some
> stability into coordinate transformations, as the positive side-effect
> of an otherwise sad story. However, this is expected to change and what
> I did anyway some time ago was to add my own lookup table as
> local/share/proj/hermann in order to gain control over my own
> transformations.

As most of the "heavy" grids are not directly distributed with proj, it might be
tricky to propose a reasonable +nadgrids parameter. Although we could use the @
syntax to make their presence optional. But there's currently no way of doing
the association between a datum and corresponding grids when the "raw" CSV files
are processed in the gcs.csv/pcs.csv. Perhaps something similar to
http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/datum_shift_pref.csv
could be used.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com