MUSCATE (MAJA - WASP shift after processing)

Hi all,

I need some information about the MUSCATE importer.
It would be great to find someone who has experience with the MAJA and WASP products.

I would like to project and clip both products, retrived from eoc geoservice ( EOC Geoservice ). Both overlap nicely after the download.
MAJA_WASP_01

This image shows both products over each other. The messurment is for illutrating the scale.

Now I import the MAJA product with the MUSCATE importer into SNAP:

  1. Subset to seperate the bands (only 10m bands)
  2. Reprojection to EPSG 25832
  3. Subset to clip to extensions and seperate the bands
  4. Write product

The WASP product cannot be imported with the MUSCATE importer
So I just open the relevant 10m bands with Open product

  1. Band math to /10000 to get reflectance
  2. Reprojection EPSG 25832
  3. Subset to clip to extensions
  4. Write product

After this processing the two product do not overlap anymore.
There is a shift of arount 5m

I can´t explain this shift and would be very grateful to get some help with this…

Cheers Christian

@marpet …do you know anyone who is into the SNAP MUSCATE reader/converter…?

Yes, this is Oana.

@oana_hogoiu could you have a look?

My 2 cents here would be the reprojection that does this. 5m seem like 1/2 pixel therefore in one case the reference pixel may be 0,0, in the other case 0.5,0.5. You can try to specify the reference pixel by hand in the reprojection step.

You can try to run gdalinfo on one band within each product (MAJA and WASP generated products) and see in the metadata the AREA_OR_POINT values. (I assume the bands format is Geotiff in both cases)

Hi Oana, Thanks for the sugestion.
WASP_MAJA_gdalinfo.pdf (139.2 KB)
These is the gdalinfo for all the raw and processed files.
It seems to me that the corner coordinates are shifted.
Is this due to the reprojection, as @kraftek mentioned?


I can´t figure out why the Scene width is set to 18932 pixels as it should be 10981 pixels…

Another thing that bothers me are the reflectance values.
I import the relevant bands and perform band maths:

These are the two products (raw and processed) loaded into QGIS:
The range is shifted into negative values.
Why is this happening?

Thank a lot for the great support in this forum =)

Cheers
Christian

Hi Christian,

For the half-pixel shift issue, I’d suggest doing the same operation on a single band of the MAJA product (try to open the band, not the product). It’s possible that the MUSCATE reader has a different interpretation of the pixel convention.

Regarding the negative values, I’m not familiar with the MUSCATE products, but MAJA uses -10000 as the “no data” value without setting it as such in the GeoTIFF metadata. WASP might do the same, I’m not sure.

The problem is that most resampler implementations are not “no data”-aware, so on the image borders or other no data pixels they will quite happily interpolate between -10000 and the valid reflectance values. So it’s pretty easy to get bad values because of this. IIRC, even GDAL has trouble ignoring those pixels, especially when the metadata is not filled in correctly.

One workaround for this might be to:

  • make a binary validity mask (say, 1 for -10000 pixels, 0 for the rest of them)
  • reproject both the reflectance bands and the validity mask using the same parameters and interpolator
  • binarize the resulting mask again (keep 0 as is, and replace anything else with 1)
  • mask the reflectance bands using the mask from the previous step

I hope that makes sense. The idea is that if you interpolate in the middle of some mask values like: 0, 0, 0, 1, you will get 0.25. That’s still different from 0, so it means that the corresponding pixel contains information from one that originally had a -10000 value, so it should be masked out at the end.