[PROJ] Grid CDN Update and Crowdfunding Request

[Chris Crook]

Thanks Even

I'm afraid I've dropped the ball for a while on the deformation models - was more than a few months ago!  But I'm still looking for opportunities.

If PROJ is adding a grid format it makes sense to me to allow it to server for deformation grids (just a horizontal/vertical/3d shift with a time function) as well the classic case and geoid models.  It seems that we could use TIFF tags to handle them with very little extra effort - not that I'm familiar with TIFF.  LINZ would be very interested in supporting that as an extra feature as we don't have a binary format for publishing our deformation grids.  I'm just being a bit opportunistic :-)

On  level of subgrids if the algorithm is to simple pick the first grid that includes the point, then that provides all the generality we want (far more than simply nested grids), as that doesn't enforce any sort of parent child relationship.  On the other hand it could be less efficient for implementation as it would require searching through all the lowest level child grids for points only on the parent.

On using ints rather than float32 the only reason is that there might be opportunities for compression.  In many case int2 with scale and offset could equally server the purpose, and then you've halved the size of the file (and grid memory possibly).  But certainly not essential.

On uncertainties of components that is certainly not a requirement at the moment - we don't provide them at the moment.  It is a feature of NTv2, and I can certainly imagine it becoming more desirable as accuracy requirements of transformations become more demanding and uncertainty of transformations becomes more critical.

The main thing I would be hoping for is that the grid can support 1/2/3 dimensional displacements (ideally without requiring all grids to define 3 dimensional displacements).

At the risk of pushing the barrow too far, a nice to have would be a grid set id in the grid headers so that we could have more than displacement field.   Each grid set would include one or more grids.    The search algorithm would select and sum the first grid of each set including the calculation point.  This could include an optional simple time function for each grid to support deformation models.  With that simple addition we could completely encode almost any deformation model.

Cheers
Chris

-----Original Message-----
From: Even Rouault [mailto:even.rouault at spatialys.com]
Sent: Thursday, 14 November 2019 8:27 a.m.
To: proj at lists.osgeo.org
Cc: Chris Crook; 'Howard Butler'
Subject: Re: [PROJ] Grid CDN Update and Crowdfunding Request

Chris,

> I'm very interested in the possibilities hinted at for GeoTIFF for grid
> files - but not very clear what capability that would provide.   It sounds
> like it could provide a way of encoding some aspects of the
> deformation model we use in NZ.

The scope of this campaign was directly dedicated to 'classic' horizontal and vertical shift grids. I know we had a discussion a few months ago about deformation models.

> The specific capability I am hoping for is:
>
> - multiple levels of nested grid
> - 1,2, or 3 (more ?) dimensions of data at each grid node (eg de, dn,
> du,  + possibly uncertainties of each, NTv2 only provides dx/dy and
> uncertainties of them IIRC) - values to be floating point or possibly
> I4 with a defined offset and scale factor for each dimension

GDAL can encode offset and scale factors in a TIFF tag (as XML metadata), but I'm not sure of the value of that for the need we want to address, rather than use Float32 directly Regarding uncertainties, we don't make currently use of them, so I'd imagine that we would not include them in the TIFFs to make them more compact.

> Presumably this would also define an interpolation technique (bilinear
> in each dimension).  NTv2 places what appear to me to be unnecessarily
> tight constraints on relationships of subgrids with parent grids.  How
> do you envisage the selection of grid to use at a specific grid cell
> would be implemented?

I was only thinking to a single-level of subgrids, like the Canadian ntv2_0.gsb, which is the most complex grid we have in the proj-datumgrid repository. The algorithm is simple: select the (first) subgrid whose extent intersects the point to transform.

TIFF files have a concept of SubIFDs that could potentiall be used to implement multiple levels but there's no support for this in GDAL and I'm not completely sure about the state of this in libtiff itself.

Even

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

________________________________

This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info at linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.