GGXF format documentation

[RogerLott]

Attached is a very preliminary format specification just to act as a straw man for further discussion. I would expect much of it to be changed, some radically. If potentially useful, probably needs to be transferred into a communal editable document.

GGXF v0.1 spec 2020-06-13.docx

[desruisseaux]

Thanks for the draft. Below are a few observations:

Requirement 2

This requirement suggests to use −360 <= λ <= 0 or 0 =< λ =< +360 longitude ranges when the grid crosses the 180° meridian. Another approach could have been to keep the [-180 … +180] range but specify that the [λ₁ … λ₂] range is interpreted as "start from λ₁, then move toward increasing longitude values until we reach λ₂" where possibly λ₂ < λ₁ if the grid crosses the 180° meridian:

This approach is used by ISO 19115-1 for EX_GeographicBoundingBox and is also used in EPSG database. But I presume that the [−360 … 0] or [0 … +360] approaches are preferred in the context of this standard because they make easier to interpolate in the grid, is that right?

I ask because having 3 different kinds of longitude range complexifies a little bit the mixing of different data on the same map, while a single [-180 … +180] range with above interpretation complexifies interpolations in the grid. So it is a matter of choosing where to put complexity (I'm not suggesting either side, just seeking to make explicit which side we choose to make easier).

Metadata

In addition of extent metadata, I would suggest a CI_Citation metadata with the URL where the grid can be downloaded. A user may have a copy of a copy of a copy and lost the original provenance.

File no data flag

Is the IEEE 754 representation of floating point numbers ubiquitous enough for recommending the use of NaN (Not-a-Number)?

Parameter values

The requirements saying "The grid data in a GGXF file shall be a sequence of space-separated values" and "The end of the file shall be terminated by an EOF character" suggest a text format. A binary format such as NTv2, NetCDF or GeoTIFF would have no separator (because all values are of fixed length).

Except for above-cited two requirements, current specification seems format-neutral in current state.

If the above-cited EOF character is an ASCII control code ^C, ^D or ^Z (depending on the OS), they are not needed any more. They are vestige of a time when the CP/M system (even older than MS-DOS) didn't knew the exact size of a file (it knew only its multiple of 128).

[desruisseaux]

A comment on #1 saying "Higher resolution may not always imply higher accuracy" raises a new question for me: does the operation_accuracy parameter applies only to values in the grid (i.e. gives accuracy only at the exact node positions, where no interpolation are needed), or does it applies also to the result of applying interpolations between nodes? I ask because the purpose of a denser but less accurate grid is not clear to me, unless that grid provides more accurate interpolated values (because of shorter distances from the nodes).

[desruisseaux]

On the list of interpolation methods (bilinear, etc.), should "Geocentric translation by Grid Interpolation" (EPSG::1087) be added? It is bilinear interpolation but applied on Tx, Ty, Tz geocentric translation terms instead than on latitude and longitude values.

[RogerLott]

Intended to be provided for. In there in table C.2 as geocentric translations and this is cross-referenced from Cartesian 3D offsets. But the IGN method also has a parameter (Standard CT code) to avoid iteration in the reverse. EPSG 1087 formula covers cases with and without this. But maybe these two cases could have separate provision.