[Bug]: HLS metadata values concatenated with "+"

[sdcolli1]

Checked for duplicates

Yes - I've already checked

Describe the bug

While testing PCM submission of DSWx-HLS products to PO.DAAC, we received feedback from a PO.DAAC developer that our ISO XML metadata was rejected due to the time extent fields containing a "+" in it:

<gmd:EX_TemporalExtent id="boundingTemporalExtent">
      <gmd:extent>
          <gml:TimePeriod gml:id="DSWx_Time_Range">
              <gml:beginPosition>2022-08-09T14:59:32.840402Z + 2022-08-09T14:59:39.355062Z</gml:beginPosition>
              <gml:endPosition>2022-08-09T14:59:32.840402Z + 2022-08-09T14:59:39.355062Z</gml:endPosition>
          </gml:TimePeriod>
      </gmd:extent>
  </gmd:EX_TemporalExtent>
</gmd:temporalElement>

The PGE sources this datetime value from the SENSING_TIME metadata field of one of the output DSWx products. Looking at the metadata for the one of the failed DSWx products it looks like there are several fields that get concatenated with a "+":

>>> gdal.Open('OPERA_L3_DSWx_HLS_S2B_30_T19KCP_20220809T144729Z_20220818T192224Z_v0.1_B01_WTR.tiff').GetMetadata()
{'ACCODE': 'LaSRC + LaSRC', ... 'SENSING_TIME': '2022-08-09T14:59:32.840402Z + 2022-08-09T14:59:39.355062Z', ... 'SENSOR_PRODUCT_ID': 'S2B_MSIL1C_20220809T144729_N0400_R139_T19KCP_20220809T175348.SAFE + S2B_MSIL1C_20220809T144729_N0400_R139_T19KCP_20220809T180941.SAFE', ... }

Likewise, the metadata from one of the input HLS products:

>>> gdal.Open('HLS.S30.T19KCP.2022221T144729.v2.0.B02.tif').GetMetadata()
{'ACCODE': 'LaSRC + LaSRC', ... 'DATASTRIP_ID': 'S2B_OPER_MSI_L1C_DS_2BPS_20220809T175348_S20220809T144730_N04.00 + S2B_OPER_MSI_L1C_DS_2BPS_20220809T180941_S20220809T145928_N04.00', ... 'L1C_IMAGE_QUALITY': 'NONE + NONE',  ... 'PROCESSING_BASELINE': '04.00 + 04.00', 'PRODUCT_URI': 'S2B_MSIL1C_20220809T144729_N0400_R139_T19KCP_20220809T175348.SAFE + S2B_MSIL1C_20220809T144729_N0400_R139_T19KCP_20220809T180941.SAFE', ... 'SENSING_TIME': '2022-08-09T14:59:32.840402Z + 2022-08-09T14:59:39.355062Z', ... 'TILE_ID': 'S2B_OPER_MSI_L1C_TL_2BPS_20220809T175348_A028336_T19KCP_N04.00 + S2B_OPER_MSI_L1C_TL_2BPS_20220809T180941_A028336_T19KCP_N04.00', ...}

So the source of the issue is the HLS data itself.

I will be updating the PGE to make sure we don't include the "+" in our ISO metadata, but I also wanted to make sure that ADT was aware of this in case any updates are needed on your end.

What did you expect?

A single datetime string assigned for the SENSING_TIME field of DSWx-HLS output products. Not sure if any changes are needed for the other metadata fields that might contain a "+".

Reproducible steps

The DSWx-HLS product referenced in the description is available here: http://opera-int-rs-pop1.s3-us-west-2.amazonaws.com/products/OPERA_L3_DSWx_HLS_S2B_30_T19KCP_20220809T144729Z_20220818T192224Z_v0.1/OPERA_L3_DSWx_HLS_S2B_30_T19KCP_20220809T144729Z_20220818T192224Z_v0.1_B01_WTR.tiff

Links to the HLS files used for this job:
https://s3.console.aws.amazon.com/s3/object/opera-int-rs-pop1?region=us-west-2&prefix=products/HLS.S30.T19KCP.2022221T144729.v2.0.B02/HLS.S30.T19KCP.2022221T144729.v2.0.B02.tif
https://s3.console.aws.amazon.com/s3/object/opera-int-rs-pop1?region=us-west-2&prefix=products/HLS.S30.T19KCP.2022221T144729.v2.0.B03/HLS.S30.T19KCP.2022221T144729.v2.0.B03.tif
https://s3.console.aws.amazon.com/s3/object/opera-int-rs-pop1?region=us-west-2&prefix=products/HLS.S30.T19KCP.2022221T144729.v2.0.B04/HLS.S30.T19KCP.2022221T144729.v2.0.B04.tif
https://s3.console.aws.amazon.com/s3/object/opera-int-rs-pop1?region=us-west-2&prefix=products/HLS.S30.T19KCP.2022221T144729.v2.0.B11/HLS.S30.T19KCP.2022221T144729.v2.0.B11.tif
https://s3.console.aws.amazon.com/s3/object/opera-int-rs-pop1?region=us-west-2&prefix=products/HLS.S30.T19KCP.2022221T144729.v2.0.B12/HLS.S30.T19KCP.2022221T144729.v2.0.B12.tif
https://s3.console.aws.amazon.com/s3/object/opera-int-rs-pop1?region=us-west-2&prefix=products/HLS.S30.T19KCP.2022221T144729.v2.0.B8A/HLS.S30.T19KCP.2022221T144729.v2.0.B8A.tif
https://s3.console.aws.amazon.com/s3/object/opera-int-rs-pop1?region=us-west-2&prefix=products/HLS.S30.T19KCP.2022221T144729.v2.0.Fmask/HLS.S30.T19KCP.2022221T144729.v2.0.Fmask.tif

Environment

- Version of this software [e.g. vX.Y.Z]
- Operating System: [e.g. MacOSX with Docker Desktop vX.Y]
...

[nemo794]

Hi Scott,

The HLS documentation does not mention this possibility.

However, looking at the Sentinel-2 product spec (link), on page 463 it mentions that sometimes two uncompleted tiles are merged into one complete tile, i.e. a "Consolidated Tile". For the SENSING_TIME metadata field of consolidated tiles, Sentinel specifies this:

"As the two uncompleted Tiles are on two Datastrip, this metadata contains two different Datastrip Start Time"

HLS uses a "keep both times" approach for Landsat granules when two Landsat scenes are used to generate a single HLS tile, so it would not surprise me if HLS decided to simply copy that entire metadata field verbatim for Sentinel data, too.

Looking forward, how to handle this is a good discussion question. It likely makes sense to simply copy that field verbatim (there is likely not an accurate way to combination those two timestamps into one), and then update the DSWx-HLS Product Spec to alert users that this is a possibility.