Coregistration of ozone dataset with cloud dataset: unexpected results
Actual behavior
@forman @kjpearson @JanisGailis Using cloud as master dataset, ozone as slave dataset: a visual "sanity check" of the the coregistrated dataset shows the following layers looking significantly different from those in the original: O3_ndens O3_vmr O3e_ndens O3e_vmr
Other variables look ok on a quick visual inspection.
Steps to reproduce the problem
- Download / open esacci.CLOUD.mon.L3C.CLD_PRODUCTS.multi-sensor.multi-platform.ATSR2-AATSR.2-0.r1 , time constraint: 2004-01-01, 2005-01-01
- Download / open esacci.OZONE.mon.L3.NP.multi-sensor.multi-platform.MERGED.fv0002.r1, time constraint: 2007-01-01, 2007-03-31
- Select operation coregister, master ds = cloud, slave ds = ozone, for other parameters use default
- Inspect each layer of coregistered dataset.
Specifications
cate-2.0.0-dev.20 Windows 7 professional
Yes, the numbers seem to be quite different before and after. I note that these are all the 3-D fields in the dataset with dimensionality (nt, nz, ny, nx). The output dimensions look right with ny and nx set appropriately and nt and nz left unchanged. The nz axis is in pressure units which might be unexpected?
Some extra information from testing dev.23: same sort of features are seen when coregistering this ozone dataset with following master datasets: esacci.FIRE.day.L4.BA.multi-sensor.multi-platform.MERIS.v4-1.r1 esacci.OC.mon.L3S.CHLOR_A.multi-sensor.multi-platform.MERGED.2-0.r1 esacci.SOILMOISTURE.day.L3S.SSMS.multi-sensor.multi-platform.ACTIVE.03-2.r1 esacci.SOILMOISTURE.day.L3S.SSMV.multi-sensor.multi-platform.PASSIVE.03-2.r1
@HelenClifton Can you see if this also persists if co-registeration is invoked with method 'nearest'?
Hi @JanisGailis yes I see the same when I use the method "nearest"