Sentinel-3 WFR EUMETSAT archive data processing

Hello everyone,

I’m trying to process a large archive database of Sentinel-3 data (level 2 WFR). I managed to retrieve the data I needed from the CODA and CODAREP repository and process it using snappy.
Yet, the data I downloaded after ordering it from the EUMETSAT Data Center is not well recognized by snappy. Something seems wrong with the geocoding and this message appears:

RuntimeError: java.lang.NullPointerException: The geo coding is null.

Has anyone already experienced such issue and eventually has a work around idea ?

Many thanks for your help,


Hi Olivier

Can you open the data in SNAP Desktop with any problem?
Can you show us your Python code? At least the parts where you handle the products?

I see that this exception message is only thrown by GeoUtils, where you provide the GeoCoding as parameter. How do you retrieve it?

Hi marpet,

Thanks for your reply

Here is the code which throws the exception message. It is basically a wrapper of the snappy subset function.

I can open the data downloaded from EUMETSAT Data Center in SNAP desktop without problems. But if I try to perform the subset manually, I cannot access the Geo Coordinates tab to define an area of interest. If I do the same with a S3 WFR data coming from CODA or CODAREP, the geo coordinates tab is accessible. (2.6 KB)

I’ve replicated your code in Java and it works (see the attached file). I have no Python environment at hand now. The Java code worked, so the Python should work too.
I also used a different product. Yours is not available anymore at EUMETSAT CODA.
Do you use SNAP8?
I guess you have tried your code with multiple products already. Just to ensure that the product is not the problem. (2.3 KB)

Thanks marpet!

Yes I’ve updated SNAP to 8.0.
Sorry if wasn’t clear, but the problem comes from data downloaded from EUMETSAT Data Center. Data downloaded from CODA or CODAREP are processed without issue with this code.

Would you mind trying your code with this data available here ?

BTW, I’ve asked the same question to EUMETSAT help desk, still waiting for an answer.

Works too.

I’ve only changed the coordinates in the code.

Ok, so this means the problem comes from my end and is not related to the data itself. I’ll re-install a clean version of SNAP 8. Maybe there are some conflicts with other SNAP version.

Many thanks again for your help Marco!

Hello again Marco,

I’ve reinstalled SNAP and snappy but it didn’t change a thing.
Instead I activated the option ‘Read Sentinel-3 OLCI products with per-pixel geo-coding instead of using tie-points’ and I managed to run the code properly. S3 WFR data coming from EUMETSAT Data Center apparently miss tie-points.

Would it be possible that this option was already activated on your side ?

Besides, what does it actually change to use per-pixel geocoding rather than tie-points ?

1 Like

Yes, indeed I have this option enabled.
Actually, I would consider this a bug in the data. It could be that this is allowed. But I have my doubts.
I’ve created an issue for this:
[SIIITBX-372] OLCI L2 WFR data from EUMETSAT Data Center has no tie-points - JIRA (

Could you contact the user support of EUMETSAT Data Center regarding this issue?
All this data is not contained in your product. I don’t think that this intended

The difference between pixel and tie-pint geo-coding is mainly the number of coordinates you have for the scene. In the pixel case, each pixel has a geo-location assigned. With tie-points in OLCI you have only 77 geo-locations for each line. In between the location are interpolated. For OLCI, the coordinates for each pixel are also DEM corrected.
So, you have a better geo-referencing. But processing (e.g. reprojection) is slower and needs more memory.

Thanks again Marco. That solved the problem for me.
I’ll relay the problem to EUMETSAT User Support.