# Harp grid gives unexpected results for GOME\_1

**URL:** https://forum.atmospherictoolbox.org/t/harp-grid-gives-unexpected-results-for-gome-1/925
**Category:** HARP
**Created:** [September 10, 2025, 8:12am UTC](https://forum.atmospherictoolbox.org/t/harp-grid-gives-unexpected-results-for-gome-1/925 "2025-09-10T08:12:08Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![Klaus-Peter](https://forum.atmospherictoolbox.org/letter_avatar_proxy/v4/letter/k/48db29/32.png) [@Klaus-Peter](https://forum.atmospherictoolbox.org/u/Klaus-Peter)
#### Post date: [September 10, 2025, 8:12am UTC](https://forum.atmospherictoolbox.org/t/harp-grid-gives-unexpected-results-for-gome-1/925/1 "2025-09-10T08:12:08Z")

</div>

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

---

<div class="post-metadata">

### Author: ![sander.niemeijer](https://forum.atmospherictoolbox.org/user_avatar/forum.atmospherictoolbox.org/sander.niemeijer/32/5_2.png) [@sander.niemeijer](https://forum.atmospherictoolbox.org/u/sander.niemeijer)
#### Post date: [September 10, 2025, 9:07am UTC](https://forum.atmospherictoolbox.org/t/harp-grid-gives-unexpected-results-for-gome-1/925/2 "2025-09-10T09:07:24Z")

</div>

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

---

<div class="post-metadata">

### Author: ![Klaus-Peter](https://forum.atmospherictoolbox.org/letter_avatar_proxy/v4/letter/k/48db29/32.png) [@Klaus-Peter](https://forum.atmospherictoolbox.org/u/Klaus-Peter)
#### Post date: [September 10, 2025, 9:37am UTC](https://forum.atmospherictoolbox.org/t/harp-grid-gives-unexpected-results-for-gome-1/925/3 "2025-09-10T09:37:45Z")

</div>

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](https://forum.atmospherictoolbox.org/uploads/default/original/1X/9cd6bb27e76a61b4686297d1f2be4b2fc1c08301.png)

---

<div class="post-metadata">

### Author: ![sander.niemeijer](https://forum.atmospherictoolbox.org/user_avatar/forum.atmospherictoolbox.org/sander.niemeijer/32/5_2.png) [@sander.niemeijer](https://forum.atmospherictoolbox.org/u/sander.niemeijer)
#### Post date: [September 10, 2025, 11:09am UTC](https://forum.atmospherictoolbox.org/t/harp-grid-gives-unexpected-results-for-gome-1/925/4 "2025-09-10T11:09:33Z")

</div>

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](https://forum.atmospherictoolbox.org/uploads/default/original/1X/84b1563ede4c9019bc18efe9a0d2e0c1712f094d.png)  
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](https://stcorp.github.io/harp/doc/html/ingestions/ESACCI_OZONE_L2_NP.html), but not (yet?) for the [the L2 TC product](https://stcorp.github.io/harp/doc/html/ingestions/ESACCI_OZONE_L2_TC.html). 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](https://climate.esa.int/en/projects/ozone/#tc-l2) 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).

---

<div class="post-metadata">

### Author: ![Klaus-Peter](https://forum.atmospherictoolbox.org/letter_avatar_proxy/v4/letter/k/48db29/32.png) [@Klaus-Peter](https://forum.atmospherictoolbox.org/u/Klaus-Peter)
#### Post date: [September 10, 2025, 11:26am UTC](https://forum.atmospherictoolbox.org/t/harp-grid-gives-unexpected-results-for-gome-1/925/5 "2025-09-10T11:26:17Z")

</div>

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

---

<div class="post-metadata">

### Author: ![Klaus-Peter](https://forum.atmospherictoolbox.org/letter_avatar_proxy/v4/letter/k/48db29/32.png) [@Klaus-Peter](https://forum.atmospherictoolbox.org/u/Klaus-Peter)
#### Post date: [September 10, 2025, 4:10pm UTC](https://forum.atmospherictoolbox.org/t/harp-grid-gives-unexpected-results-for-gome-1/925/6 "2025-09-10T16:10:50Z")

</div>

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

 ![grafik](https://forum.atmospherictoolbox.org/uploads/default/original/1X/ecfa61278007f1d76b0a6f2634053000ac28452e.png)  
the figure is swapped in North South direction (it shows 1 July 1997)

---

<div class="post-metadata">

### Author: ![sander.niemeijer](https://forum.atmospherictoolbox.org/user_avatar/forum.atmospherictoolbox.org/sander.niemeijer/32/5_2.png) [@sander.niemeijer](https://forum.atmospherictoolbox.org/u/sander.niemeijer)
#### Post date: [September 10, 2025, 4:27pm UTC](https://forum.atmospherictoolbox.org/t/harp-grid-gives-unexpected-results-for-gome-1/925/7 "2025-09-10T16:27:05Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![thomasd](https://forum.atmospherictoolbox.org/letter_avatar_proxy/v4/letter/t/5f8ce5/32.png) [@thomasd](https://forum.atmospherictoolbox.org/u/thomasd)
#### Post date: [September 11, 2025, 1:45pm UTC](https://forum.atmospherictoolbox.org/t/harp-grid-gives-unexpected-results-for-gome-1/925/8 "2025-09-11T13:45:21Z")

</div>

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

```auto
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](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…

---

<div class="post-metadata">

### Author: ![sander.niemeijer](https://forum.atmospherictoolbox.org/user_avatar/forum.atmospherictoolbox.org/sander.niemeijer/32/5_2.png) [@sander.niemeijer](https://forum.atmospherictoolbox.org/u/sander.niemeijer)
#### Post date: [September 11, 2025, 2:27pm UTC](https://forum.atmospherictoolbox.org/t/harp-grid-gives-unexpected-results-for-gome-1/925/9 "2025-09-11T14:27:13Z")

</div>

It actually seems to be:

```auto
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.
