this might be, but as long as not all parts of the graph are valid, the intermediate products will not show as inputs in subsequent steps of the graph, as it is the casee in your example. “Source Bands” remains empty unless the problem in the “Terrain Flattening” step is solved.
Let me then try and input my external DEM first
The windows looks better now but I still don’t have any clue where to key in the corner coordinates for subsetting the image. Another thing I notice is certain modules still don’t detect the source bands, in this case speckle filter and onwards.
For now, I have removed the Subset module to proceed with the processing but I still wonder how do I subset on the go.
Can you please show the full graph in a screenshot so we can see the order of the steps?
What is your input image?
If you put a polygon formatted as WKT (as in your case) and hit “Update”, a yellow rectangle should appear in the map. You can zoom to it to see if it looks okay.
hmm, it is strange that after the subset, the intermediate product is no longer accepted by SNAP.
Can you please upload the xml file so I can have a look at it?
Putting terrain flattening and terrain correction in the same graph will kill performance. We are hoping to place them in the same operator in the future. Also, speckle-filtering should be done done before flattening while the original SAR image statistics are still intact.
Why would you want to filter and then terrain flatten the image?
The whole intention of generating Beta0 is to supply it to the next step for terrain flattening without disrupting the statistics which will happen if you introduce filtering between them.
Instead, generate the Beta0 and terrain flatten it so that completes the Radiometric part of the processing and then speckle filter the image before proceeding with the Geometric part which is the Terrain correction.
This is exactly what I discuss with Andreas,
here: Radiometric & Geometric Correction Workflow
I’m not entirely sure which is is the correct order, speckle-filters often assume that the input data has a certain statistical districution and it’s possible that the terrain-flatteing part disturbs that. Perhaps @eyeinsky could clarify?
thank you. I just tried it with another image and adjusted the WKT and the graph reports no error:
3
Looks like your Subset part did not store the node. Please have a look at mine and adjust the WKT in the XML according to your data and try again
myGraph_S1_Processing_AB.xml (7.4 KB)
Can you tell me how did you subset using the pair of corner coordinates which is generally needed while sub-setting with geographic coordinates.
actually, I used geographic coordinates. I created the WKT here: https://arthur-e.github.io/Wicket/sandbox-gmaps3.html
1 Like
it is highly inefficient to use terrain flattening and terrain correction in the same graph - it’s much better to split it in two.
I agree, but still the subset error should have a different reason.
In my case as below, what is going on, why the polygon as wkt couldn’t be updated, I want to subset GRDH
You are not using geographic coordinates (UTM probably). It should work if you switch to WGS84 (EPSG:4326)
1 Like
Yes, it should be geographic coordinates, but hopefully in the future update, could be accepted both.
In my case I have pair of corner coordinates, one from the upper left hand and the other from the bottom right hand. How do the convert these to the WKT format? I guess this website,
https://arthur-e.github.io/Wicket/sandbox-gmaps3.html
doesn’t have the provision to precisely adjust to a given values of corner coordinates.
if you have two latitudes and two longitudes you can create the polygon string yourself following the WKT definition rules: https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry
1 Like