S3 LST product mosacking: How to get per-pixel time stamp?

s3tbx
#1

Hi, I am using GPT with the Mosaic operator to mosaic multiple S3 LST L2 files. This works great, but I need in the output file also a variable that provides the observation timestamp for each pixel (this is important in the mosaic since neighboring pixels can be from different overpasses and thus observed at different times).

I am not sure how to do this since the S3x_SL_2_LST____ input files do not appear to include a gridded timestamp variable. Does anybody have an idea how to approach this? I am attaching my XML which I call simply via “gpt mosaic2.xml *.SEN3”

mosaic2.xml (1.1 KB)

#2

There is way to get the time information. The way how to retrieve it has some issues but sufficient for your use case, I think.
You can use the TIME variable in the BandMaths and add a band with time information.
This can be done with following graph.
mathTime_and_merge.xml (1.1 KB)
This will give you a MJD2000 time value as double (float64) data type. The data type float64 cannot be used in the GUI, only if you use the GraphBuilder or the Graph XML. This is the first issue.
The time will be the same for each line. It doesn’t check for each pixel. That’s the second issue, but most products only provide start and stop time and not the time for each pixel.

The third issue is that the mosaic processor only handles float32 data. So, you will lose information about the daytime here. Probably it is sufficient for you if you can distinguish between days.

In your case you don’t need the extra graph. You can simply add a variable to your mosaic configuration. I hope this is sufficient for you to distinguish the pixels.
mosaic2_addedTime.xml (1.3 KB)

2 Likes
#3

Thank you so much! This is very helpful. I just tried it and it sort of does what I need. The first and second issues you mentioned are not really a problem for my use case (the first because this is supposed to run in batch mode in an operational environment anyway so it’s all command line based, the second because the time differences within each line should be negligible anyway). The third issue is a little more annoying as it basically makes the data inside the output geotiff file not self-contained, but instead (if I understand it right - please correct me if I misunderstood) when reading the output file one has to stitch together the fractional MJD2000 value providing the time of the day and the date retrieved from the filename or some other source. Maybe the third issue can be fixed relatively easily in a future version of SNAP, but until then I will go ahead with the method you suggest. Thanks again.

#4

Yes, you misunderstand me. The data you have in your GeoTiff contains the date but not the exact time. The digits before the decimal point are correct but after the decimal point the accuracy is lost. Because of the conversion from double to float32. The digits after the decimal point define the time. 0.5 is at midnight, so also the digit before changes during a day. But the accuracy is sufficient for your use case.

#5

Hm, now I am a bit confused. What I get when runnning mosaic2_addedTime.xml are values such as for example 7652.41895 (see below for a screenshot from SNAP). I don’t really know how to interpret the first 4 digits before the comma since MJD2000 is supposed to be 5 digits for the day as far as I understand. However, the digits after the comma when converted to time are quite close to the actual overpass time given in the individual orbit files (e.g. 0.41895*24 = ca.10:03 UTC) under the assumption that the MJD starts at midnight and not at noon as you say. According to e.g. http://www.csgnetwork.com/julianmodifdateconv.html that seems to be the case (“The MJD begins at midnight rather than noon (the .5 in the formula), in keeping with more standard conventions and modern representation of time.”).

I don’t really need the day (i.e. the digits before the comma) since I know this information for each file anyway, but I need to have the approximate time in that day at which each pixel was observed. If the precision of the fractional time after the comma is at least accurate enough to within 10-15 minutes of the actual time then that would be good enough accuracy for my purposes.

image
image810Ă—626 62.4 KB

#6

To convert the number 7652.41895 to the actual date/time I use this webpage

First, I calculate the value for January the first of 2020 at 0:00:00 => 2451544,50000
Then I sum up both values:
7652,41895 + 2451544,50000 = 2459196,91895
The I use this number to convert it to date/time:
10:03:17.28 UT on December 13, 2020