TSX Coregistration, SEVERE error messages

esteban.aguilera · February 14, 2017, 1:25pm

I’m coregistering a TSX interferometric pair over the Netherlands and I’m getting this error message:

SEVERE: org.esa.snap.core.datamodel.Product: raster width 32656 not equal to 29315
SEVERE: org.esa.snap.core.datamodel.Product: raster width 32656 not equal to 29315

It looks like it’s pointing out the fact that the images have a different number of azimuth samples. Shouldn’t this be more of a WARNING or INFO level log message?

lveci · February 14, 2017, 2:21pm

The error seems to come from a check is products are compatible.

public boolean isCompatibleProduct(final Product product, final float eps) {

    if (getSceneRasterWidth() != product.getSceneRasterWidth()) {
        SystemUtils.LOG.severe("raster width " + product.getSceneRasterWidth() + " not equal to " + getSceneRasterWidth());
        return false;
    }

This gets called by create stack to see if it can simply copy the master bands. I’m guessing your master image isn’t the same as the coregistered product you;re creating. Maybe you’re applying a max or min extent?

In any case, it seems harmless and you’re right it shouldn’t be a severe error.
Thanks Esteban

esteban.aguilera · February 14, 2017, 2:24pm

I see, thanks.

I’m just using the Coregistration feature as accessible from the menu. No further customization other than the coregistration parameters.

esteban.aguilera · February 15, 2017, 9:04am

Hi Luis, here’s another one while coregistering another slave:

SEVERE: org.esa.snap.core.datamodel.Product: first scan line left corner org.esa.snap.core.datamodel.GeoPos[53°26'37" N,7°11'36" E] not equal to org.esa.snap.core.datamodel.GeoPos[53°25'57" N,7°11'25" E]

Seems like not severe either.

hakim · February 16, 2017, 8:42pm

Hi guys,

Just to let you know that I’m encountering the same error when I try to coregister an image (NDVI) that was derived from a Sentinel-2 optical product with a TerraSAR-X stripmap SAR image.
The TerraSAR-X image has a higher resolution and was chosen as the master during the coregistration.

Below is the error I’m getting:

Picked up JAVA_TOOL_OPTIONS: -Djava.vendor="Sun Microsystems Inc."
INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters
Executing processing graphfirst_line_time metadata value is null
last_line_time metadata value is null
SEVERE: org.esa.snap.core.datamodel.Product: raster width 3955 not equal to 3957
SEVERE: org.esa.snap.core.datamodel.Product: raster width 3955 not equal to 10980
..WARNING: org.esa.s1tbx.insar.gpf.coregistration.WarpOp: Water_slv2_01Jan2000 does not have enough valid GCPs for the warp

..11%....22%....33%....44%....55%....66%....77%....88%. done.

Both products don’t have the same size obviously:

TerraSAR-X image is (3955, 2289).
Sentinel-2 image is (10980, 10980).
Both of these sizes are mentioned in the error.

ABraun · February 17, 2017, 6:06am

is your TerraSAR-X scene already terrain corrected?

I don’t know if coregistration is suitable for this purpose. I would bring both in the same projection and then use the raster collocation module.

hakim · February 17, 2017, 11:54am

Yes the TerraSAR-X image were terrain-corrected using a high-resolution LiDAR DEM (to avoid affecting the spatial resolution).

I’ve never used the Raster Collocation before, is it different from the Coregistration?

ABraun · February 17, 2017, 12:03pm

yes, coregistration searches for matches within two images for GCP creation.
collocation already presumes that both rasters have good geocoding and only adjusts the spatial resolution according to the chosen master image.

hakim · February 17, 2017, 12:53pm

There’s a problem I’ve noticed with the collocation operator. The slave product is not cut to match the geographic coordinates of the master product (which was the case with the coregistration).

After the collocation, both the resulting master and the slave have the same size (width and height by pixels).
But certain geographical coordinates (latitudes and longitudes) appear in the resulting slave product but not in the master product (which is smaller).

Is this the normal behavior of the collocation operator?

ABraun · February 17, 2017, 1:03pm

you can choose the output extents in the coregistration module (min/max of inputs, master) but not in the collocation module, that is right.
Besides that, your result looks okay?
You could crop it afterwards.

hakim · February 17, 2017, 1:14pm

Yes, judging by a few pins I’ve put on both optical & SAR images, the result (geocoding) seems quite accurate

lveci · February 17, 2017, 2:30pm

With the TC SAR product, if the geocoding can be trusted as @ABraun has said you could use the collocation operator or if you want to be able to select the minimum or maximum extents, you could use the CreateStack operator which is mostly similar to collocation.

hakim · February 17, 2017, 5:40pm

Using the CreateStack operator I couldn’t limit the extent in the slave product to the same extent of coordinates as in the master product.

I noticed in the Graph Builder that the collate operator couldn’t work because it’s complaining about the masterProduct field that’s not set (I cannot find where to set it). CreateStack works well however in the Graph builder.

ABraun · February 17, 2017, 5:58pm

sometimes you first need to complete the complete graph (links from read [+modules] to write) before you can select all required fields.

hakim · February 20, 2017, 1:05pm

I can’t find what’s missing. Here is my xml graph:

<graph id="Graph">
  <version>1.0</version>
  <node id="Read">
    <operator>Read</operator>
    <sources/>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">
      <file>C:\Data\Tewkesbury-SAR\geometric-corrections\terrain-correction\post.tif</file>
    </parameters>
  </node>

  <node id="Read(2)">
    <operator>Read</operator>
    <sources/>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">
      <file>C:\Data\Tewkesbury-Optical\Water.hdr</file>
    </parameters>
  </node>

  <node id="Collocate">
    <operator>Collocate</operator>
    <sources>
      <sourceProduct refid="Read"/>
      <sourceProduct.1 refid="Read(2)"/>
    </sources>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">
      <targetProductName>_collocated</targetProductName>
      <targetProductType>COLLOCATED</targetProductType>
      <renameMasterComponents>true</renameMasterComponents>
      <renameSlaveComponents>true</renameSlaveComponents>
      <masterComponentPattern>${ORIGINAL_NAME}_M</masterComponentPattern>
      <slaveComponentPattern>${ORIGINAL_NAME}_S</slaveComponentPattern>
      <resamplingType>NEAREST_NEIGHBOUR</resamplingType>
    </parameters>
  </node>

  <node id="Write">
    <operator>Write</operator>
    <sources>
      <sourceProduct refid="Collocate"/>
    </sources>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">
      <file>C:\Data\target.dim</file>
      <formatName>BEAM-DIMAP</formatName>
    </parameters>
  </node>
</graph>

And the error thrown is:

Error: [NodeId: Collocate] Operator 'CollocateOp': Mandatory source product (field 'masterProduct') not set.

ABraun · February 20, 2017, 2:25pm

try removing the .1 in
<sourceProduct.1 refid="Read(2)"/>
save the product and try again.

I have stumbled over this error, too:

marpet · February 20, 2017, 2:41pm

Have a look at you Collocate node.

<sources>
   <sourceProduct refid="Read"/>
   <sourceProduct.1 refid="Read(2)"/>
</sources>

There is no masterProduct. Change it to

<sources>
   <masterProduct refid="Read"/>
   <slaveProduct refid="Read(2)"/>
</sources>

Then it should work.

hakim · February 20, 2017, 3:03pm

Thanks very much. That solved my problem @marpet

I guess because the collocation operator doesn’t include a resampling, the values in the produced product are kept as in the original input products (as opposed to the CreateStack operator which alter the values of the slave product as expected after the resampling) @ABraun @lveci