User needs

[RogerLott]

Who are 'users'? o Producing agencies o Survey / GIS / ITS application developers o Customers of survey / GIS / ITS application developers o Geodetic and earth science researchers

A) Producing agencies require: 1) Easy to construct 2) Quick adoption by application developers 3) Include uncertainties

B) Application developers require: 1) Fully documented file format 2) Licence details 3) Single file (opening multiple files concurrently is an overhead)

C) Customers of application developers require: 1) Immediate access (no waiting on software development) 2) Metadata describing provenance, applicability and accuracy

D) Researchers require: 1)
2)

[ccrook]

User needs from a producer point of view (first cut).

"As a geodetic product producer I want to be able to publish authoritative grid based products to users in a form that they can use confidently without risk of misinterpretation"

This requires:

• Well defined format for publishing authoritative gridded geodetic data sets and associated data/metadata for use by consumers.
  • Gridded data sets include geoid models, tidal surfaces, deformation models
  • Associated data could include time functions, CRS definitions, uncertainty (standard error values).
  • Associated metadata could include licence, version info, publication date, etc so users can determine fitness for purpose.
  • Support for data sets based on one or more 2d regular rectangular grids aligned with coordinate axes, with up to (say) 5 data values at each node (eg tidal surfaces, deformation components, with uncertainties).
• Data sets based on multiple grids will typically be "nested grid" datasets for which a uniquely identifiable single grid from the set is applicable at each location within the extents of the set.
• Support for missing values at grid nodes where data is unavailable
• Defined algorithms for interpolation of grid quantities as the requirement is to define an authoritative surface model, not just an authoritative set of values grid nodes.
• Format directly usable by consumer software to provide effective publication and facilitate timely updating (particularly for deformation models) and avoid risk of corruption transforming to other formats

In practice the actual producer needs are for support in software tools for constructing, testing, interrogating grid based data sets and easy publication mechanism. As a national geodetic agency LINZ will endeavour to support customers by producing multiple formats if necessary but having a single common format would simplify maintaining an authoritative product.

[kevinmkelly]

The following application developers requirements for GGXF are gleaned from Kelly et al, 2015. Here, developer requirements are distiguished from GGXF requirements.

Informative header. GGXF must allow for a full description of the data contained in the grid, including but not limited to coordinate reference systems and data provenance.

Interpolation. GGXF should specify in its header the required or recommended interpolation method, e.g. bilinear, spline, etc. This will allow application software to apply the grid producers’ desired interpolation algorithm.

Efficient. GGXF should be computationally efficient through supporting binary files, platform independence and efficient file size. Grid header location will be flexible: headers for all grids can be listed sequentially at the beginning of the file or headers can precede each grid as it appears in the file. Since, parent grids and subgrids can appear in any order in the file, the flexible header facilitates fast access to any desired part of the file. With these, developers can build applications to have fast access to any part of very large files.

Easy to use. GGXF should be straightforward for grid producers to populate and easy and efficient for application developers to use. A well-documented description, complete with examples and an open-source API for developers must accompany the GGXF format. GGXF standard file syntax should be published and versionable.

Recognizable. GGXF file format should be identified by a unique file name extension, for example: [filename].GXA for ASCII file types and [filename].GXB for binary files.

[JATarrio]

In the following lines, and as agreed, I indicate a series of aspects that a deformation grid should have according to what the researchers require:

• Universal: although it is true that many of the countries and organizations generate their grids specifically focused on solving local or regional problems, they must tend to obtain a solution applicable on any surface of the earth. In this sense, that the grid can be used in areas of great seismic activity, high movement due to the GIA and in areas with practically no earthquakes, should be the focus of the solution. • Newfangled: When researchers initiate or seek to answer questions about a problem, an innovative and original solution is always considered a much more positive approach than a “case study”.

Currently the problem (in my opinion) that the existing models present, is in some cases the precision when modeling events such as earthquakes (in the case of modeling it), and another aspect the rigidity to update the grid, it should be aimed at a solution and format that allows it to be easily updated over time.

[RogerLott]

Customers of application developers - application users - need:

• metadata with complete summary of content.
• header integrated into the data file so that they cannot become separated.
• metadata readable by user.
• nice to have - an authoritative test point provided by the data producer.
• access to the file as soon as released by producing agency.
• ability to reduce grid coverage to user-defined area of interest (is this an historic requirement no longer relevant due to computer memory and processing speed advances?).
• fast interpolation of grid and execution of transformation.
• compressable file for easy transmission e.g. as email attachment.

[ccrook]

ability to reduce grid coverage to user-defined area of interest (is this an historic requirement no longer relevant due to computer memory and processing speed advances?).

There may still be use cases for this, eg providing local corrections grids for as part of real time positioning correction services. I'm not sure how systems such as VRS (virtual reference systems) work and what the capabilities are for providing local corrections but I suspect there could be a use case for this transmitting small subsets over limited bandwidth data channels.

[ccrook]

Not a current issue but potentially useful informative discussion - referenced on the wiki page