Creating a cropped GRD from SLC using gpt

would that be the terrain-correction as outlined in the gpt batch script, using a local DEM?

slc2geotiff.xml (6.3 KB)

looks good. But again, converting SLC to GRD will not give you better geolocation. I recommend to test it once with GRD outside a batch script and check if the result is sufficient.

Thanks! Got the batch terrain correction/subset working with GRD, looks quite good. Is there a way to add additional map sources, like google maps to the WorldWind Analysis View?

How would I terrain correct the different polarizations separately? I need these as two geotiff files, not one with two bands. Any ideas for the batch script?

During Terrain Correction you can select a source band. If you only select one, there will only be one output

I have never used the WorldWind Analysis view, sorry. You can load a WMS to the main map window as demonstrated here: Better Map overlay?

Thanks a lot, got it all working now with gpt and script… the images are now really nicely geo-located.

very good.

Almost there… the Tie-Point Grids section is missing in the processed (subset’ed + TC) geotiff, how can I add it?

I’m using in-house extraction code to read out the pixels…

you will probably have to create them as separate bands using the Band Maths.

Wouldn’t that create a section under Bands and not at the root level?

Is it the subset step that removes this section? If just doing the Terrain-Correction and saving, would the Tie-Point Grids be left intact?

tie-point grids are not treated as official bands and Terrain Correction (including conversion to GeoTiff) will probably lose these grids.
More importantly, after terrain correction, the initial tie-point grids are of lower positional accuracy (they exist from the beginning, but terrain induced shifts are not contained). If you need the coordinates of each pixel, I suggest to perform terrain correction first and then create the lat and lon bands in the band maths with the expressions X and Y

grafik

This can be done with the gpt as well.

In a last step, you can export the GeoTiff with all three rasters.

Seems like tiepoints are part of the standard, see here https://docs.opengeospatial.org/is/19-008r4/19-008r4.html#_requirements_class_modeltiepointtag

If I can’t reproduce the same file structure using SNAP and gpt I’m afraid this is a show stopper for me…

I agree that it can be contained by a GeoTiff, but the tie-points are generally no longer a part (because they contain obsolete information) after Terrain Correction.

I understand that terrain correction is making the initial info obsolete…but then we need to create an updated info, that’s how I see it.

How can SNAP show the Tie-Point Grids data? Selecting properties on these doesn’t reveal much, mainly the raster size…

Here’re the json contents from gdalinfo from the two files, I guess it’s basically the ground control points missing.

gdalinfo_cropped_Intensity_VH.tif.json (2.1 KB)
gdalinfo_s1a-iw-grd-vh-20200307t052415-20200307t052440-031565-03a2fe-002.tiff.json (42.4 KB)

Since it’s a small subset I might be able use these instead…

“cornerCoordinates”:{
“upperLeft”:[
12.6940838,
56.1047535
],
“lowerLeft”:[
12.6940838,
56.098645
],
“lowerRight”:[
12.7059415,
56.098645
],
“upperRight”:[
12.7059415,
56.1047535
],

I agree. But the Band Maths does exactly that.

Are you saying Band Maths may create the ground points section, making it identical to the orginal geotiff? (and making my current code be able to read, without any changes)

When I make a band math this will end up in the bands section…

no, you are right that any band maths result will end in the band section not under tie-point grids. I thought that you simply need one lat and lon coordinate for the geocoded output. I don’t know how this is solved best in the code, sorry.
Maybe there is an easier way to achieve your overall aim? I’m still not clear why you need the tie-point grids as such.

Thanks for your persistent help. We use our own extraction code that’s why it won’t work if ground control points are missing. There are other ways to solve this, but we still need to update our code to look for corner coordinates if the ground points are missing.

The gpt output’ed geotiff saves all metadata in to a custom geotiff tag by id 65000, which is the first of any custom tags. This segment is XML and 7MB of size in my case. We would need to add XML parser module to fetch this which is one solution.

Is there any other way you know of to manually add another geotiff tag from SNAP, saving the corner coordinates in a simple format which would enable us to easily extract these?

Or, we could use the Band Maths functionality and save for every pixel the corresponding lat/long coordinate. This is how I interpreted your earlier advice by using the X and Y data…

I lean toward the Band Maths if there isn’t any other easy way to store the corner lat/long coordinates, as we don’t need to rely on the XML which may change.

maybe @marpet has an idea here

Managed to gpt batch create a three band, cropped TC’d geotiff by adding three entries under the BandMaths targetBands section.

Didn’t not use the X and Y expression as it seems to store the pixel value, instead used LAT and LON to fetch the pixel position, right?

grd2geotiff.xml (4.6 KB)

The cropped image is a bit clipped at left side, not sure if this is expected or how I can fix it?

oh, right! X and Y are the pixel coordinates.

If you did the subset before terrain correction, it has maybe clipped too much because the image was not rotated yet. Please have a look at Marco’s explanation on this. S3-OLCI Subset Issues
I would slightly increase the subset area to go sure.