Time Column in the “GriddedData” File Type

[grkal]

Dear GROOPS Team,

I would like to make a suggestion which you might find interesting for a future update of the GROOPS software regarding a slight modification to the structure of the “GriddedData” file type so as to include a time column (similar to the “Time [MJD]” column of the “Instrument” file type); in case no time information is available, this column could be automatically filled with “NaN” values or not included at all as it is the case with the “unit areas [-]” column.

In my opinion, the inclusion of a time column in the structure of the “GriddedData” file type could be beneficiary for some applications and better data handling; I will try to explain this by using some examples below.

Firstly, by enabling the “removeDuplicates” config element in the current version of the “GriddedDataConcatenate” program, the duplicate points of the input gridded data files referring either to a different point in time, e.g. gridded data files with a (partial) spatial overlap (such as repeated orbit groundtracks), or to the same point in time, e.g. gridded data files with a (partial) temporal overlap, are both removed. However, if the input gridded data files with a (partial) temporal overlap are derived from different sources, e.g. a gridded data file derived from an approximate orbit and another one derived from dynamic orbit integration, the gridded points which refer to the same epoch will remain in the concatenated gridded data file. Additionally, the user might prefer to keep the duplicate points if they refer to a different point in time and only delete the ones referring to the same point in time.

With the inclusion of a time column in the structure of the “GriddedData” file type, an additional temporal criterion for removing duplicate epochs (similar to the “removeDuplicates” config element of the “InstrumentConcatenate” program) could be added in the “GriddedDataConcatenate” program (something like “removeDuplicatesEpochs” while renaming the original “removeDuplicates” to “removeDuplicatesPoints”). By enabling this temporal criterion, duplicate epochs each of which correspond to gridded points either with different values, e.g. gridded data files derived from different sources with a (partial) temporal overlap, or with the same values, e.g. gridded data files derived from the same sources with a (partial) temporal overlap, would both be removed. The user would be able to choose between the two aforementioned removal criteria according to his needs or even to apply both.

Secondly, instead of sampling a gridded data file only in the spatial domain (as it is the case currently with the “GriddedDataReduceSampling” program), the temporal sampling could be achieved by creating a program which would work similar to the “InstrumentReduceSampling” program (something like “GriddedDataReduceSamplingTemporal” while renaming the original “GriddedDataReduceSampling” to “GriddedDataReduceSamplingSpatial”).

Finally, if a gridded data file is generated from the “Orbit2Groundtracks” program, by definition of the current structure of the “GriddedData” file type, the time information included in the input orbit file is removed. A workaround I have found for this is to write the epochs from the “inputfileOrbit” to a separate “MISCVALUE” instrument file type (with the epochs as “data0” column) using the “InstrumentArcCalculate” program. This “MISCVALUE” instrument file type would then be specified in the “Orbit2Groundtracks” program as “inputfileInstrument”. If the current structure of the “GriddedData” file type remains intact, it could alternatively be investigated to add an additional option to the “Orbit2Groundtracks” program where the user could opt to include the epochs of the “inputfileOrbit” as a data column to the output gridded data file (something like an “inputfileOrbitEpochs” boolean config element).

For the current version of the “GriddedData” file type, I have come up with a workaround regarding the removal of (possible) duplicate epochs when concatenating input gridded data files (and also reduce their temporal sampling if needed) with their time information known. Specifically, it is summed up as follows:

• Convert each gridded data file to a “Matrix” file type with “GriddedData2Matrix” program
• Create “MISCVALUE” instrument file types each of which corresponding to a specific gridded data file with the time represented in the “data0” column
• Combine each pair into “Matrix” file types each of which including the time column (set as “data0” column) followed by the columns of the corresponding gridded data file by using the “FunctionsCalculate” program
• Convert the combined “Matrix” file types to “MISCVALUES” instrument file types by using the “InstrumentSetType” program
• Concatenate the combined “MISCVALUES” instrument file types and remove duplicate epochs by using the “InstrumentConcatenate” program with the “removeDuplicates” config element enabled
• (Optional) Reduce the sampling of the concatenated file by using the “InstrumentReduceSampling” program
• Convert the concatenated (and possibly reduced) file back to a “Matrix” file type with the “FunctionsCalculate” program (with the time column after the columns of the initial gridded data files)
• Convert back to a “GriddedData” file type with “Matrix2GriddedData”

Of course, a simpler alternative would be to first concatenate the input orbit files by removing duplicate epochs with the “InstrumentConcatenate” program (and also reduce their sampling if needed) and then apply the “Orbit2Groundtracks” program. However, this would require the orbit files to be available, while my aforementioned workaround is applied directly to any input gridded data file for which the time information is known regardless of the way it was generated.

Please regard my aforementioned suggestion as a contribution towards a constructive discussion in improving the already amazing capabilities of the GROOPS software.

Best regards,
Grigorios Kalimeris
Chair of Astronomical and Physical Geodesy
Technical University of Munich

[tmayerguerr]

Thanks for the suggestion. We will discuss this in our group.
regards
Torsten