Geolocation offset with data in RAW mode

[simonrp84]

Hello,
I am returning with a new question!

For the S2A night campaign, there were some acquisitions taken in RAW mode and some taken in NOM mode. It seems that for RAW there is a geolocation offset in the output from Sen2VM of approximately 550m to the South.

For example, in the 20251204T125204 acquisition (over Japan) I see that features in the S2A imagery are around 550m South of where they should be in the daytime imagery. The same is true for other RAW mode acquisitions (although I have not checked all of them, only a random sample).

But, when I look at imagery taken in NOM mode, there does not seem to be a geolocation offset - features are in the locations I expect them to be.

Could you please explore this to see if there is some difference in what Sen2VM does in RAW vs NOM mode? I am running the same processing script for both modes, and have re-tried the processing several times so am reasonably confident this is not an 'operator error' on my side :)

[aburie-cs]

Dear @simonrp84,

Thanks for your analysis.
Behaviour should not be different between RAW and NOM acquisitions.

We will get the data and investigate what could be the reason. This could be due to the L1 framing strategy that is a little different in operational processor between RAW and NOM mode.

Best regards,

Antoine

[aburie-cs]

Dear @simonrp84 ,

As I feared, it's comming from Legacy Sentinel-2 IPF that has an issue when processing RAW acquisitions.

During the beginning of the L1 chain, a framing is applied (cutting lines) to synchronise detectors and bands.
However, in case of RAW acquisitions, twice the number of line is removed, but time is not changed (only applied one time), so times are no more corresponding to the real line.

We are creating a ticket on Legacy IPF to get a correction.

This being said, here are some questions:

• Are the past RAW acquisition important for you ?
• Are you planning to have other RAW acquisitions in the future ? (This type was limited to commissioning phase before the night acquisitions).

In Sen2VM, we can investigate the possibility to re-synchronised line and times as a workaround while waiting for Legacy correction.
Also, when Legacy correction will be delivered, it will be applied for future acquisitions, but a reprocessing will be necessayyr for the passed acquisitions (your night acquisitions for example).

What would be your opinion on the way forward ?

[simonrp84]

Thanks for investigating, @aburie-cs!

To answer your questions:

1. Yes, the past RAW acquisitions are important - so a fix for this in Sen2VM would be very much appreciated if possible!
2. Yes, potentially we are planning additional RAW acquisitions in the future (next <6 months). I'm not sure if the IPF can be fixed in time for that.

[aburie-cs]

Dear @simonrp84,

We have released a new version 1.2.0 that include the shift compensation for INS-RAW DATATAKE_TYPE.
If detected (automatically) in the Datastrip metadata, Sen2VM will look to the GIP_PRDLOC and compute a shift compensation based on the information find inside it. This GIPP is mandatory only for INS-RAW acquisition.
(It is to be noted that an optional parameter has been added in the configuration to deactivate the shift for INS-RAW if wanted, for example for when the operational IPF will be corrected)

The https://github.com/sen2vm/sen2vm-gipp-database has been updated with the different version of the GIP_PRDLOC.

We have verified on a day acquisition of S2C which is perfectly corrected, and also on night acquisitions of S2A (more difficult).
Don't hesitate if you have questions or if you saw other strange behaviors.

Best regards,

Antoine

[simonrp84]

Thanks @aburie-cs!
I saw the code updated last week and planned to spend this afternoon on getting the new version set up, so the release and your message come at the perfect time :)

I'll update my environment now and let you know how things go. Really appreciate the work of you and the team on addressing this issue so efficiently!

[simonrp84]

Unfortunately @aburie-cs it seems that Sen2VM is not running. I updated my docker (with the build command as listed in the readme) but when I try to run on a S2 granule I get this:

 docker run --rm -v /data/:/data sen2vm -c /data/UserConf/config_20251206T183211.json -p /data/UserConf/params_20251206T183211.json
2026-05-11 18:20:40 [INFO   ] Start Sen2VM
2026-05-11 18:20:40 [INFO   ] Parsing file /data/UserConf/config_20251206T183211.json
2026-05-11 18:20:40 [INFO   ] Reading IERS file at: /data/DATA/bulletina-xxxviii-049.txt
2026-05-11 18:20:40 [INFO   ] Parsing file /data/UserConf/params_20251206T183211.json
2026-05-11 18:20:40 [INFO   ] Detectors list: [DETECTOR_5, DETECTOR_6, DETECTOR_11, DETECTOR_12]
2026-05-11 18:20:40 [INFO   ] Bands list: [BAND_1, BAND_2, BAND_3, BAND_4, BAND_5, BAND_6, BAND_7, BAND_8, BAND_9, BAND_10, BAND_11, BAND_12, BAND_8A]
2026-05-11 18:20:40 [INFO   ] Find the following datastrip metadata file: /data/DATA/S2A_OPER_PRD_MSIL1B_PDMC_20251212T151208_R113_V20251206T183141_20251206T183211.SAFE/DATASTRIP/S2A_OPER_MSI_L1B_DS_2APS_20251206T202612_S20251206T183140_N05.11/S2A_OPER_MTD_L1B_DS_2APS_20251206T202612_S20251206T183140.xml
2026-05-11 18:20:41 [INFO   ] DATATAKE_TYPE is INS-RAW
2026-05-11 18:20:41 [INFO   ] Initializing: copy of the Orekit-data: /Sen2vm/orekit-data
2026-05-11 18:20:41 [INFO   ] Orekit-data: /Sen2vm/orekit-data

And nothing else, it just hangs. I set this one running yesterday and it's been like that for ~14 hours with no update. The code is running something, though, as top shows multiple java processes each using ~50% of a CPU core.

Any ideas what could be the problem here? I haven't updated any of the input or auxillary data (apart from the GIPP) compared to my previous runs of Sen2VM a few months ago...

[simonrp84]

I also get the same issue when I run the latest release directly, without docker:

 java -jar sen2vm-core-1.2.0-jar-with-dependencies.jar  -c UserConf/config_20251203T182216.json -p UserConf/params_20251203T182216.json
2026-05-12 08:36:26 [INFO   ] Start Sen2VM
2026-05-12 08:36:26 [INFO   ] Parsing file UserConf/config_20251203T182216.json
2026-05-12 08:36:26 [INFO   ] Reading IERS file at: /data/DATA/bulletina-xxxviii-049.txt
2026-05-12 08:36:26 [INFO   ] Parsing file UserConf/params_20251203T182216.json
2026-05-12 08:36:26 [INFO   ] Detectors list: [DETECTOR_5, DETECTOR_6, DETECTOR_11, DETECTOR_12]
2026-05-12 08:36:26 [INFO   ] Bands list: [BAND_1, BAND_2, BAND_3, BAND_4, BAND_5, BAND_6, BAND_7, BAND_8, BAND_9, BAND_10, BAND_11, BAND_12, BAND_8A]
2026-05-12 08:36:26 [INFO   ] Find the following datastrip metadata file: /data/DATA/S2A_OPER_PRD_MSIL1B_PDMC_20251212T154932_R070_V20251203T182201_20251203T182216.SAFE/DATASTRIP/S2A_OPER_MSI_L1B_DS_2APS_20251203T183534_S20251203T182159_N05.11/S2A_OPER_MTD_L1B_DS_2APS_20251203T183534_S20251203T182159.xml
2026-05-12 08:36:27 [INFO   ] DATATAKE_TYPE is INS-RAW
2026-05-12 08:36:27 [INFO   ] Orekit-data: /data/orekit-data

[aburie-cs]

Hum, and it is the place where the GIPPs are read.

Could you please do a "tree" command on your GIPPs folder ?
I also will add some logs in this part to make it easier to understand