Snap 8 - mapProjection in RD-Terrain Correction changed?

Dear Snap developers,

congratulations for the new release. You seem to have addressed some important issues here, great!

I found one difficulty with my workflows when porting to the new version. I use epsg codes for defintion of the mapProjection parameter within the Terrain-Correction operator, in order to keep it simple, but adjustable.

e.g. as the most simplest of all, and working in Snap 7: -PmapProjection=‘EPSG:4326’

In Snap 8 that won’t work anymore, throwing a Java NullPointer exception (see below).
I tried to translate the EPSG code into WKT format using rasterio’s crs class in python, and insert this into the -PmapProjection, but it doesn’t work neither.

How did those options changed, and what would be the most easy and user-friendly way to select a certain projection (I prefer EPSG)?

Thanks,
Andreas

INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters
INFO: org.esa.snap.core.util.EngineVersionCheckActivator: Please check regularly for new updates for the best SNAP experience.
INFO: org.hsqldb.persist.Logger: dataFileCache open start
org.esa.snap.core.gpf.OperatorException: org.esa.snap.core.gpf.OperatorException due to java.lang.NullPointerException
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:440)
at org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp.initialize(RangeDopplerGeocodingOp.java:349)
at org.esa.snap.core.gpf.internal.OperatorContext.initializeOperator(OperatorContext.java:528)
at org.esa.snap.core.gpf.internal.OperatorContext.getTargetProduct(OperatorContext.java:298)
at org.esa.snap.core.gpf.Operator.getTargetProduct(Operator.java:385)
at org.esa.snap.core.gpf.main.CommandLineTool.runOperator(CommandLineTool.java:306)
at org.esa.snap.core.gpf.main.CommandLineTool.runGraphOrOperator(CommandLineTool.java:284)
at org.esa.snap.core.gpf.main.CommandLineTool.run(CommandLineTool.java:188)
at org.esa.snap.core.gpf.main.CommandLineTool.run(CommandLineTool.java:121)
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(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:84)
at com.install4j.runtime.launcher.UnixLauncher.start(UnixLauncher.java:66)
at install4j.org.esa.snap.runtime.Launcher_gpt.main(Unknown Source)
Caused by: org.esa.snap.core.gpf.OperatorException
at org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp.createTargetProduct(RangeDopplerGeocodingOp.java:564)
at org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp.initialize(RangeDopplerGeocodingOp.java:306)
… 24 more
Caused by: java.lang.NullPointerException
at org.esa.s1tbx.commons.CRSGeoCodingHandler.(CRSGeoCodingHandler.java:61)
at org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp.createTargetProduct(RangeDopplerGeocodingOp.java:530)
… 25 more

Error: org.esa.snap.core.gpf.OperatorException due to java.lang.NullPointerException

Andreas, yes indeed I was able to reproduce your problem with the EPSG code. It was caused by checking for the degree unit. This will be fixed in a module update.

Thanks
Luis

ok, thanks. Does this mean also the old behaviour of providing EPSG strings will work again?
Also the AUTO:42001 etc options were quite helpful actually

Thanks

Yes it will still work

Great,
thanks!

Hello,
I am having the same problem with SNAP v8. I see there is a fix coming in an update, so thank you.
But is there a workaround we could use in the mean time?

Best Regards,
Paul

Ahh, that AUTO:42001 works instead of using the EPSG code. I am not familiar with that nomenclature.

Ok, AUTO:42001 worked (processed without failure) but did not quite give the output I wanted.

But substituting ‘WGS84(DD)’ for ‘EPSG:4326’ worked and gave the desired output. I was not familiar with that (WGS84(DD)) nomenclature either. So, that’s my work around.

1 Like

Dear @lveci,

I am still having some issues here. In particular, when I declare only the Pixel spacing in meters, and use EPSG:4326, the output file will be basically emtpy. Is this intended? If I remember correctly, in SNAP 7 this was working.

as an example:
gpt Terrain-Correction -PdemName=‘SRTM 1Sec HGT’ -PdemResamplingMethod=‘BILINEAR_INTERPOLATION’ -PexternalDEMFile=’’ -PexternalDEMNoDataValue=0 -PexternalDEMApplyEGM=‘false’ -PimgResamplingMethod=‘BILINEAR_INTERPOLATION’ -PpixelSpacingInMeter=100 -PalignToStandardGrid=true -PmapProjection=‘EPSG:4326’ -t ‘TC’ ‘calibrated’

other EPSG codes seem t work just fine.

Thanks in advance,
Andreas