Inputs do not occupy the same physical space

[goffartb]

Hi,
I am working with Sen2Agri, using MAJA 3.2.2 for Sentinel 2 pre-processing.
Currently, I have a site running over around 10 tiles. For three of those tiles, I have the following issue :

`ScientificProcessing: ITK Exception: itk::ERROR: PersistentStreamingMaskConditionalStatisticsVectorImageFilter(0x4393e60): Inputs do not occupy the same physical space!

InputImage Origin: [2.0010000e+05, 9.9900000e+04], InputImage_1 Origin: [2.0010000e+05, 4.7887289e+06]
Tolerance: 2.4000000e-04
InputImage Spacing: [2.4000000e+02, -2.4000000e+02], InputImage_1 Spacing: [2.4000000e+02, 9.3774179e+06]
Tolerance: 2.4000000e-04`

It is happening for tiles 35NRA, 36NTF, 36NUF, for images in June 2020. Those 3 tiles are on the same latitude. They cover the south part of the red AOI on the image below :

Here is the log.
uganda_maja_manual_run.txt

Would you have any idea about the source of the error ?

Thank you for your help,

Benjamin

[petket-5]

Hi Benjamin,

There seems to be an error with one of the intermediate images created by Maja 3.2.2 which is originating from either a wrongly situated DEM (created by Sen2Agri from SRTM and SWBD data) or malformed L1C products. Given that you encounter this error systematically on three tiles, I tend to investigate the former.
Do you have gdalinfo installed on your system? If so, could you please run the following commands and post the output here? I copied the paths from your attached log, you might need to change it a little to get to the right files:

gdalinfo /mnt/archive/demmaccs_tmp/tmp23ITUD/36NTF/S2_TEST_AUX_REFDE2_36NTF_20200601T080611_0001.DBL.DIR/S2_TEST_AUX_REFDE2_36NTF_0001_ALT_R1.TIF
gdalinfo /mnt/archive/demmaccs_tmp/tmp23ITUD/36NTF/S2_TEST_AUX_REFDE2_36NTF_20200601T080611_0001.DBL.DIR/S2_TEST_AUX_REFDE2_36NTF_0001_SLP_R2.TIF
gdalinfo /mnt/archive/demmaccs_tmp/tmp23ITUD/36NTF/S2_TEST_AUX_REFDE2_36NTF_20200601T080611_0001.DBL.DIR/S2_TEST_AUX_REFDE2_36NTF_0001_MSK.TIF
gdalinfo /mnt/archive/demmaccs_tmp/tmp23ITUD/36NTF/S2A_MSIL1C_20200601T080611_N0209_R078_T36NTF_20200601T101035.SAFE/GRANULE/L1C_T36NTF_A025815_20200601T082835/IMG_DATA/T36NTF_20200601T080611_B01.jp2
gdalinfo `find /mnt/archive/demmaccs_tmp/tmp23ITUD/maccs_36NTF/.maja-working-directory/ -name "vns_caching_rasterize_image_m_IPZoneMaskSubReaders_band_id0_0" | head -n 1`

Kind regards,
Peter

[goffartb]

Hi Peter,

Thank you for your help.

Here are the gdalinfo ouputs.
gdalinfo_ALT_R1.txt
gdalinfo_B01.txt
gdalinfo_MSK.txt
gdalinfo_SLP_R2.txt
gdalinfo_vns_caching.txt

The file vns_caching_rasterize_image_m_IPZoneMaskSubReaders_band_id0_0 was not existing anymore. I recreated according to the options that are given in the log file, from the following source file :
S2A_MSIL1C_20200601T080611_N0209_R078_T36NTF_20200601T101035.SAFE/GRANULE/L1C_T36NTF_A025815_20200601T082835/QI_DATA/MSK_DETFOO_B01.gml

The problem seems to come from that file. The gdalinfo is giving "Pixel Size = (240.000000000000000,9377417.851528383791447)"

Kind regards,
Benjamin

[petket-5]

Thank for your input. I cannot see any problem with the DEM creation. Something went horribly wrong during the rasterisation of the input detector footprint masks... I will try to download the product and see if I can reproduce.I will keep you updated.

Peter

[petket-5]

Hi Benjamin,

I just checked using Maja3 and Maja4. Maja3 does not calculate the bounds properly as one of the coordinates is negative. There seems to be an overflow happening in that case which propagates to the gdal_rasterize calls that results in the vns_caching_rasterize_image_m_IPZoneMaskSubReaders_band_id* rasters to be wrong.
Maja4 does not have the same issue. Sen2Agri only contains a distribution of Maja3 howver. You can still process the S2 products in question using the following Maja precompiled executable to be found here.

Kind regards,
Peter

[goffartb]

Hi Peter,

Thank you very much for your feedback.
I have then launched the pre-processing with Maja4, it seems to work indeed.

Kind regards,
Benjamin