java.lang.NullPointerException
at java.io.File.(Unknown Source)
at org.esa.beam.framework.gpf.main.CommandLineTool.initVelocityContext(CommandLineTool.java:204)
at org.esa.beam.framework.gpf.main.CommandLineTool.run(CommandLineTool.java:168)
at org.esa.beam.framework.gpf.main.CommandLineTool.run(CommandLineTool.java:121)
at org.esa.beam.framework.gpf.main.GPT.run(GPT.java:57)
at org.esa.beam.framework.gpf.main.GPT.main(GPT.java:36)
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.bc.ceres.launcher.Launcher.launch(Launcher.java:154)
at com.bc.ceres.launcher.Launcher.main(Launcher.java:56)
You are not doing anything wrong. Sorry, but this is clearly a bug that we’ll fix for the public release. With chance there will be an update of the beta release even before that.
In order to specify the target on the command line, please use the option "-t " to move on. Please also note that in your graph XML you use the variable $target.dim, but on the command line you don’t specify a parameter with that name.
Even if these hints solve your problem, the ‘gpt’ tool should output a human-readable error message saying waht’s wrong in your case.
the -Tfile= “C:\temp\test.dim” worked at least in Nest 4.1 but not since S1TBX … I thought that -T refers to the file node and therefore works? I think that time I took this out of a Nest example …
the -t option worked until I reinstalled and have this slf4j issue reported in another post … for our processing chain, Nest 4.1 still runs most stable via command line …
I see a space just after [-Tfile=] and before ["]. Please make sure
there is no space on your actual command-line.
In any case, we’ll fix your issue asap!
I just installed the new release SNAP 2.0 Beta 6, but the issue above still remains. I am running the scripts which work just perfectly in NEST from gpt, in SNAP I the error messages below. Is not gpt from SNAP backward compatible to NEST? I am referring to this xml file and the command
In NEST I used — maybe not fully correctly – the option -Tfile=“C:\test.dim” but this worked. Now I get the message "Error: Unknown option ‘-Tfile=C:\test.dim’
"
If I use ‘-Ptarget=C:\test.dim’ or “-t ‘C:\test.dim’” I get the error messages below. It appears to me the these option do not work anymore in SNAP since ithey ignore the file name given by me but says “Not able to write product file: ‘C:\Program Files\snap\target.dim’”
Again, all the same commands work perfectly in the old NEST Toolbox
Max
PS: Here the whole error message
WARNING: org.esa.snap.python.gpf.PyOperatorSpi: Ignoring non-existent Python module path: C:\Users\max.snap\snap-python
INFO: org.geotools.referencing.factory.epsg.ThreadedEpsgFactory: Setting the EPSG factory org.geotools.referencing.factory.epsg.DefaultFactory to a 1800000ms timeout
INFO: org.geotools.referencing.factory.epsg.ThreadedEpsgFactory: Setting the EPSG factory org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory to a 1800000ms timeout
INFO: org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory: Building new data source for org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory
INFO: org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory: Building backing store for org.geotools.referencing.factory.epsg.ThreadedHsqlEpsgFactory
org.esa.snap.framework.gpf.OperatorException: Not able to write product file: ‘C:\Program Files\snap\target.dim’
at org.esa.snap.framework.gpf.graph.GraphProcessor$GPFImagingListener.errorOccurred(GraphProcessor.java:373)
at com.sun.media.jai.util.SunTileScheduler.sendExceptionToListener(SunTileScheduler.java:1646)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:921)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at com.sun.media.jai.util.RequestJob.compute(SunTileScheduler.java:247)
at com.sun.media.jai.util.WorkerThread.run(SunTileScheduler.java:468)
Caused by: org.esa.snap.framework.gpf.OperatorException: Not able to write product file: ‘C:\Program Files\snap\target.dim’
at org.esa.snap.gpf.operators.standard.WriteOp.doExecute(WriteOp.java:289)
at org.esa.snap.framework.gpf.internal.OperatorContext.executeOperator(OperatorContext.java:1273)
at org.esa.snap.framework.gpf.internal.OperatorImage.computeRect(OperatorImage.java:65)
at javax.media.jai.SourcelessOpImage.computeTile(SourcelessOpImage.java:137)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
… 3 more
Caused by: java.io.IOException: failed to create data output directory: .\target.data
at org.esa.snap.dataio.dimap.DimapProductWriter.initDirs(DimapProductWriter.java:148)
at org.esa.snap.dataio.dimap.DimapProductWriter.writeProductNodesImpl(DimapProductWriter.java:109)
at org.esa.snap.framework.dataio.AbstractProductWriter.writeProductNodes(AbstractProductWriter.java:109)
at org.esa.snap.gpf.operators.standard.WriteOp.doExecute(WriteOp.java:287)
… 7 more
Error: Not able to write product file: ‘C:\Program Files\snap\target.dim’
Max, we’ve now removed the -T option, because it was actually never used by the SNAP source code! There must have been another reason why your XML was once running fine.
Please make sure, your XML code only contains references to parameters that have been passed in the form -Pname=value. Then, in the graph XML, the only valid reference to this parameters is using $name or even better ${name}. Avoid the dot character (.) in names, i.e. use target_dim instead of target.dim as name.
I also tried your advice with ${name} and not having a dot in the name … no success …
I cannot see that I am doing something wrong … can you? Is gpt really working on your machines?
From the long error report that line strikes me “Error: Not able to write product file: ‘C:\Program Files\snap\target.dim’” — indicating that it does not recognize the transferred name but tries the standard home directory instead? If I hard-code the target file in the xml file, then it works (although no progress bar and many warnings, which did not exist in NEST).
I can confirm that gpt has a lot of test cases that we constantly run. It seems you are using a modified graph XML file that was previously created by the graph builder. Could you please do a test and simply remove the Write node and just specify the -ttargetfile option. Another simple test is to make the Write node to last one in the graph. Thanks!!
I recreated the xml-file in SNAP in the Graph Builder. The results:
The Graph Builder in SNAP creates an xml file where the Write-operator follows right after the Read-operator, after that all other operators as they are manually added in the Graph Builder. In Nest this was no problem, but indeed, in SNAP this order is a problem! I have to open the xml in an editor and move the Write-operator to the very end. Doing this, this command works:
Using the -t option, however, only works when completely removing the Write-operator.
The bug is therefore that SNAP creates an order of operators in the Graph Builder which it cannot handle. It would be best if it was not order-sensitive just as NEST was.
Another “bug” in a way: in NEST the command line showed a progress bar. This does not seem to be the case in SNAP, but this was very useful.
[EDIT: After testing I realize that the -Ptarget option has the same prpblems above in NEST as it has in SNAP, I just never stumbled over it in NEST. -t file works best but only when the write module is removed.
For some very strange reason my wrong use of -Tfile in NEST trying to replace $target in the xml Write module gave correct results! No idea how that can work, but it still does … it seems to replace target correctly … ]