Tue 18 Oct 2016 07:35:41 PM UTC, comment #5:
I looked in more detail into the problem. There were two issues that caused a vertical shift. First, there was a problem wit the initialization of the buffer (before the actual loop). As I read a new line at the beginning of the for loop, I should stop reading before the first row. This solved the shift for the times > initial time. The second issue was a shift for the initial time. Here, I forgot to set the obsLineBuffer to the centre of the obsLineVector:
obsLineBuffer=obsLineVector[down_opt[0]/2];
The bug is fixed in version 2.6.8.
|
Wed 28 Sep 2016 06:26:32 AM UTC, comment #3:
I think the error is in the irow=0 for writing. As explained, the corresponding row to read from should be 1 indeed, but then the geotransform should be corrected accordingly. I think I should correct gt[3] as follows when setting the geotransform for the writers:
gt[3]+=static_cast<int>(down_opt[0]/2)
|
Wed 28 Sep 2016 06:09:57 AM UTC, comment #2:
Sorry for my mistake.
down_opt[0]/2 should be 1 for the int operation if down_opt[0]==3.
However, the reasoning was that the first row (0) in the model at coarse res (300 m), the centre pixel at the observation at fine res (100 m) should be the second row (1). This would correspond to the centre of the coarse res pixel
|
Tue 27 Sep 2016 07:19:06 PM UTC, comment #1:
Thanks for the detailed information. Could you please tell the version of pktools with which you tested (pkinfo --version).
Also, I would like to test on the same data (or better small extract of it) so I can reproduce.
The -down 3 option seems to be a workaround for the round error indeed.
I do not see that maxRow is set to 1 when irow ==0. In that case down_opt[0]/2=3/2 -> 0 for int operation, thus maxRow is 0 as it should be ?
|
Tue 27 Sep 2016 07:26:52 AM UTC, original submission:
When examining the output of pkkalman, it appears that pixel rows are shifted upward by a fixed amount of pixel, so row x in the ouput corresponds to row x+s in the observation input.
Upon inspection of the code, there are 2 different reasons:
- In our case, the resolution of the model is (approximately) 300m, while the resolution of the observation is 100m. Hence, the 'down_opt' variable should be 3. If this is not specified as an argument however, this code tries to compute it:
if(down_opt.empty()){
double resModel=imgReaderModel1.getDeltaX();
double resObs=imgReaderObs.getDeltaX();
int down=static_cast<int>(ceil(resModel/resObs));
if(!(down%2))
down+=1;
down_opt.push_back(down);
}
The result of this in our case is 5, because resModel/resObs=3.00000000xxx.
We worked around this by adding the '-down 3' argument.
- This reduced the shift to one row. For the 'forward' model, it seems to me that this is caused by the code on line 587, at the beginning of the loop over all rows:
int maxRow=(irow+down_opt[0]/2<imgReaderObs.nrOfRow()) ? irow+down_opt[0]/2 : imgReaderObs.nrOfRow()-1;
obsLineVector.erase(obsLineVector.begin());
imgReaderObs.readData(obsLineBuffer,GDT_Float64,maxRow,readObsBand);
obsLineVector.push_back(obsLineBuffer);
Here, when irow ==0, maxRow is set to 1, so obsLineBuffer is not row 0 of the observation image, but the first row. It is this buffer that is used as input for row 0 of the output, which could explain the pixel shift.
I'm not familiar enough with the code to be entirely sure what the best fix would be, but let me know if I can help.
Thanks, and best regards!
|