The purpose of this ticket is to prototype a new capability for automatic generation of the MeasuredParameters section of an ISO XML template, based on the Metadata available within a given OPERA product (GeoTIFF or HD5).
Currently, this section of the ISO XML template is derived manually based on inspection of the available product metadata and Product Spec Document, however, this can be error prone and lead to missing or mismatched metadata between product and ISO XML.
Describe the feature request
A better approach might be to further "templatize" the MeasuredParameters section of the current Jinja2 template into a loop that traverses over a dictionary of product metadata and creates the individual XML entries automatically.
A template Jinja2 loop for each measured parameter could look like the following:
Note that this example is mostly for explanatory purposes and will likely not work as-is in the Jinja2 template syntax.
For the initial prototype, lets not worry about filling in the field descriptions, as this will likely require a separate effort to develop a separate look-up table with descriptions sourced from a Product Spec document. Also for the initial prototype, let's only focus on the DSWx-S1 PGE.
That being said, the goals of this ticket are as follows:
[x] Rework the ISO XML template for DSWx-S1 to convert the MeasuredParameters section into a for-loop as described above
[x] Make any necessary modifications to dswx_s1_pge._collect_dswx_s1_product_metadata() to create the dictionary of product metadata suitable for use with the new for-loop template. This could include moving the product metadata into its own measured_parameters sub-dictionary (to distinguish from metadata used elsewhere in the template), as well as precomputing of things like the type-strings for each parameter ("int", "float", "string" etc...). Some metadata values are also stored as Python lists or numpy arrays, so logic that can convert to a string representation before being fed to the template may also be useful here.
[x] Generate an example of the new ISO XML (via DSWx-S1 integration test) so we can evaluate how to refine this capability further
Checked for duplicates
Yes - I've already checked
Alternatives considered
Yes - and alternatives don't suffice
Related problems
The purpose of this ticket is to prototype a new capability for automatic generation of the
MeasuredParameters
section of an ISO XML template, based on the Metadata available within a given OPERA product (GeoTIFF or HD5).Currently, this section of the ISO XML template is derived manually based on inspection of the available product metadata and Product Spec Document, however, this can be error prone and lead to missing or mismatched metadata between product and ISO XML.
Describe the feature request
A better approach might be to further "templatize" the
MeasuredParameters
section of the current Jinja2 template into a loop that traverses over a dictionary of product metadata and creates the individual XML entries automatically.A template Jinja2 loop for each measured parameter could look like the following:
Note that this example is mostly for explanatory purposes and will likely not work as-is in the Jinja2 template syntax.
For the initial prototype, lets not worry about filling in the field descriptions, as this will likely require a separate effort to develop a separate look-up table with descriptions sourced from a Product Spec document. Also for the initial prototype, let's only focus on the DSWx-S1 PGE.
That being said, the goals of this ticket are as follows:
MeasuredParameters
section into a for-loop as described abovedswx_s1_pge._collect_dswx_s1_product_metadata()
to create the dictionary of product metadata suitable for use with the new for-loop template. This could include moving the product metadata into its ownmeasured_parameters
sub-dictionary (to distinguish from metadata used elsewhere in the template), as well as precomputing of things like the type-strings for each parameter ("int", "float", "string" etc...). Some metadata values are also stored as Python lists or numpy arrays, so logic that can convert to a string representation before being fed to the template may also be useful here.