TSX Coregistration, SEVERE error messages

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?

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

I see, thanks.

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

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.

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.

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.

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?

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.

1 Like

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?

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.

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

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.

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.

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

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

<graph id="Graph">
  <node id="Read">
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">

  <node id="Read(2)">
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">

  <node id="Collocate">
      <sourceProduct refid="Read"/>
      <sourceProduct.1 refid="Read(2)"/>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">

  <node id="Write">
      <sourceProduct refid="Collocate"/>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">

And the error thrown is:

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

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

I have stumbled over this error, too:

Have a look at you Collocate node.

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

There is no masterProduct. Change it to

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

Then it should work.


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