Harp grid gives unexpected results for GOME_1

HARP
1

dear Sander, all,

I tried to grid GOME_1 (resolution 320km) data to 1°x° grid. The data were reprocessed with GODFIT and the import_product works well.
When I grid the data, I would expect that ~3 grid cells have the same value. However, only one of the three grid cells is filled. Depending on whether I use keep latitude_bounds or not it is either the western pixel or the central one but not all three.
Klaus-Peter

2

Can you share an example? e.g. which orbits did you include and what harp(merge) command did you use?

3

i used all files from 1995/07/01:
ESACCI-OZONE-L2P-TC-GOME_ERS2-BIRA_001021-19950701094000-fv0300.nc

O3_hp2=harp.import_product(in_files)

o3_grid=harp.execute_operations(O3_hp2,operations=‘keep(latitude_bounds,longitude_bounds,O3_column_number_density);bin_spatial(181,-90,1,361,-180,1)’)

test=o3_grid[‘O3_column_number_density’].data[0,:,:] #remove time for plotting

grafik
grafik752×403 51.1 KB

4

I tried to dig into this, but there seem to be multiple issues here. Also, the HARP implementation is from more than 10 years ago, so it is tricky to find the historic design decisions on this.

If I plot the L2 itself, I get the same small footprints as you see. So the problem seems to be in the L2 product itself:

Screenshot 2025-09-10 at 12.55.01
Screenshot 2025-09-10 at 12.55.012706×2234 380 KB

However, there is another issue where the HARP ingestion does not seem to map the coordinates to a proper bounding polygon (the final polygon in HARP should order the corner points in counter-clockwise order). The data in the product seems to order the corners differently, resulting in the wedge-shaped polygons. We already had such a reordering in the HARP ingestion for the L2 NP product, but not (yet?) for the the L2 TC product. Note that this ordering of points does not impact the overall bounding box size of the area, so the small size is really a product problem.

Then, trying to look up the format specification, the L2 TC does not seem to be part of the current O3 CCI baseline. In the documents on Ozone ECV Project the Phase 2 PSD does not mention a L2 TC and the Phase 3 PSD is not available.
Also, the document does not mention at all, for the products that do have these lat/lon boundary variables, how the pixel coordinates are supposed to be ordered.

I would recommend to contact the Ozone CCI project and ask them to clarify these issues (i.e. small footprints in L2 product, lack of documentation for L2 TC, and lack of documentation of corner coordinate point ordering).

5

Thank you very much, I hope it is not a Level2 issue. because than I can’t resolve this without additional assumptions.

6

Solved.
At the beginning of the GOME_1 there really was a gap between the pixels two years later it looks as expected:

grafik
grafik752×403 67 KB

the figure is swapped in North South direction (it shows 1 July 1997)

7

Be aware that the pixel coordinate ordering is likely still incorrect, so the weight attribution of each GOME pixel to each grid cell is likely not valid.

8

Hi, I don’t have experience with GOME-1, but recently dealt with a similar issue for GOME-2 data, where the pixel corner coordinates did not appear in the order that HARP (or CF conventions) would like.

At least for GOME-2, pixel corners are labeled ABCD, but this is not a “counterclockwise as seen from above order” as per usual convention, rather it looks like

A -- B
|    |
C -- D

It is illustrated for GOME-2/METOP in figure 5 of this DLR GOME PUG https://earth.esa.int/eogateway/documents/20142/37627/Gome-Product-user-manual.pdf . I can’t find a similar figure for GOME/ERS-2, but it could be similar…

9

It actually seems to be:

A -- C
|    |
B -- D

Which is aligned with the C/D swap we are already doing for the L2 NP product (see above) to make it counter clockwise.
We will adjust HARP to do this for L2 TC as well.
But it would be good if the CCI project actually documented this properly.