GPT, reprojection and MERIS in S-3 format (.nc)

Dear Forum

I am an old school from Beam but I am still struggling with gpt.
I have a series of MERIS RR in .SEN3 format, so not in N1, and I want to reproject the scene.

These .SEN3 MERIS directories contain 21 ncdf file and an xml manifest.

Using gpt, I am doing the following (wrong, tried many options, all wroing)
[1]
gpt Reproject -Ssource=<filepath to \xfdumanifest.xml> -t -e

I also tried (with and without quotation marks, doesn’t matter):
[2]
gpt Reproject -Ssource=<filepath to \xfdumanifest.xml> -t -e -Pcrs=“WGS84(DD)”

I think my major problem is that the Source file should not be pointed to the “MER*_.SEN3\xfdumanifest.xml” but to another, in-house one with parameters in it.
OK, so how do I process these MER.SEN3 files.

(shall I specify that SNAP cannot read any of my 100s’ .xml files either when importing under import/optical sensors/MERIS Level 1 (S3)).
Bad news, right ? Where do we go from here? (I also tried to re-write the .SEN3 as a .dim, doesn’t work).

Help would be greatly appreciated. Best, David

Type of error (done on windows, before running this on UNIX for batch processing)

gpt Reproject -Ssource=F:\REGIONS\Chile\Hermes\Test\ENV_ME_1_RRP____20081225T1
44346_20081225T144516_________________0090_075_039______ACR_R_NT____.SEN3\xfduma
nifest.xml -e
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing ex
ternal tool adapters
java.lang.NullPointerException
at org.esa.s3tbx.dataio.s3.meris.MerisProductFactory.getBandindex(MerisP
roductFactory.java:168)
at org.esa.s3tbx.dataio.s3.meris.MerisLevel1ProductFactory.configureTarg
etNode(MerisLevel1ProductFactory.java:25)
at org.esa.s3tbx.dataio.s3.AbstractProductFactory.addDataNodes(AbstractP
roductFactory.java:297)
at org.esa.s3tbx.dataio.s3.AbstractProductFactory.createProduct(Abstract
ProductFactory.java:112)
at org.esa.s3tbx.dataio.s3.Sentinel3ProductReader.createProduct(Sentinel
3ProductReader.java:95)
at org.esa.s3tbx.dataio.s3.meris.MerisLevel1ProductReader.readProductNod
esImpl(MerisLevel1ProductReader.java:23)
at org.esa.snap.core.dataio.AbstractProductReader.readProductNodes(Abstr
actProductReader.java:169)
at org.esa.snap.core.gpf.main.DefaultCommandLineContext.readProduct(Defa
ultCommandLineContext.java:59)
at org.esa.snap.core.gpf.main.CommandLineTool.readProduct(CommandLineToo
l.java:521)
at org.esa.snap.core.gpf.main.CommandLineTool.addProduct(CommandLineTool
.java:466)
at org.esa.snap.core.gpf.main.CommandLineTool.getSourceProductMap(Comman
dLineTool.java:454)
at org.esa.snap.core.gpf.main.CommandLineTool.runOperator(CommandLineToo
l.java:295)
at org.esa.snap.core.gpf.main.CommandLineTool.runGraphOrOperator(Command
LineTool.java:284)
at org.esa.snap.core.gpf.main.CommandLineTool.run(CommandLineTool.java:1

  1. at org.esa.snap.core.gpf.main.CommandLineTool.run(CommandLineTool.java:1
    
  2. at org.esa.snap.core.gpf.main.GPT.run(GPT.java:54)
    at org.esa.snap.core.gpf.main.GPT.main(GPT.java:34)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.esa.snap.runtime.Launcher.lambda$run$0(Launcher.java:55)
    at org.esa.snap.runtime.Engine.runClientCode(Engine.java:189)
    at org.esa.snap.runtime.Launcher.run(Launcher.java:51)
    at org.esa.snap.runtime.Launcher.main(Launcher.java:31)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:62)
    at com.exe4j.runtime.WinLauncher.main(WinLauncher.java:101)
    at com.install4j.runtime.launcher.WinLauncher.main(WinLauncher.java:26)
    

Error: java.lang.NullPointerException

The 4th reprocessing is still under development and SANP 5 supports the MERIS Data QWG developing the 4th reprocessing. Till now we haven’t heard about any problems. All files we had at hand so far are working.
May I ask you to upload the data to our FTP server? I send you a separate message with the credentials.

Regarding your reprojection problem. Specifying the xfdumanifest.xml manifest file as source is ok. Alternatively you can specify the folder.

I had a look at your products. It seems they were processed with an old version.
Your are processed with version 9.0.1 and 9.3 already exists.
The files have some oddities. For example the band names.
They are e.g. “04”, but should be “M04”,
Several metadata elements are not set properly or are duplicated.
Also, I have never seen RRP products before. Only RRG or FRG.
So overall, I think you have outdated test products.

Marco, thank you so much for your time. Honestly, this is greatly appreciated.

But… I have 1,000 of these. What can I do? Beam doesn’t like them, SNAP can’t read them… is there a way out? e.g. re-write them as .dim ?

Marco, thank you so much for your time. Honestly, this is greatly appreciated.
But… I have 1,000 of these. What can I do? Beam doesn’t like them, SNAP can’t read them… is there a way out? e.g. re-write them as .dim ?
Basically I need a way out.

If we can’t read them we can’t write them. You have to get newer products.
You need to ask your data provider for new products.

Hi Marco, I have a similar problem reading a Meris-SEN3 file.
It was recently written by ODESA, has the type RRP but the band names are “MO1”…
and I can’t open it in snap.
Best
hajo

Name and content file names below:
ENV_ME_2_RRP____20080101T103821_20080101T104000_________________0098_064_409______ACR_R_NT____.SEN3/
M01_rho_TOA.nc
M01_rho_top.nc
M01_rho_w.nc
M02_rho_TOA.nc
M02_rho_top.nc
M02_rho_w.nc
M03_rho_TOA.nc
M03_rho_top.nc
M03_rho_w.nc
M04_rho_TOA.nc
M04_rho_top.nc
M04_rho_w.nc
M05_rho_top.nc
M05_rho_w.nc
M06_rho_top.nc
M06_rho_w.nc
M07_rho_top.nc
M07_rho_w.nc
M08_rho_top.nc
M08_rho_w.nc
M09_rho_top.nc
M09_rho_w.nc
M10_rho_top.nc
M10_rho_w.nc
M12_rho_top.nc
M12_rho_w.nc
M13_rho_top.nc
M13_rho_w.nc
M14_rho_top.nc
M14_rho_w.nc
chl_nn.nc
chl_oc4me.nc
instrument_data.nc
iop_nn.nc
l_aer.nc
l_iwv.nc
mgvi.nc
mtci.nc
par.nc
psurf.nc
rc_mgvi.nc
tie_geo_coordinates.nc
tie_geometries.nc
time_coordinates.nc
trsp.nc
tsm_nn.nc
w_aer.nc
w_iwv.nc
xfdumanifest.xml

You find the file here;
ftp://ftp.hzg.de/outgoing/floeser/ENV_ME_2_RRP____20080101T103821_20080101T104000_________________0098_064_409______ACR_R_NT____.SEN3

As I already told David I never saw an RRP product. So maybe they are different as those we were provided till now. However, I’ll have a look at the file.

Also in your xfdumanifest.xml file the bands are referenced by e.g. “04” where we expect “M04”. Line 354.

In your file it is stated that processor version is 9.0.1 (Line 206)
<sentinel-safe:software name="megs_level2" version="9.0.1"/>
In one recent file I got it is version 9.3
<sentinel-safe:software name="MEGS-L2" version="9.3"/>

So it seems also our file does not follow the latest file format.

Dear Hajo and Marco

Thanks to Marco’s advice, I stopped wasting my time with that MEGS_9.0.1 MERIS reprocessing.
I went back to the server and re-ordered data processed with MEGS_8.1 (end 2012), delivering the scenes in .N1 format.
And now, I am fine. So I would forget about the non-native MERIS file formats.