bugpktools - Bugs: bug #49196, pkkalman shifts rows

 
 

bug #49196: pkkalman shifts rows

Submitted by:  None
Submitted on:  Tue 27 Sep 2016 07:26:52 AM UTC  
 
Category: command line utilitySeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Pieter kempeneers <kempenep>
Open/Closed: ClosedOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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.

Pieter kempeneers <kempenep>
Project AdministratorIn charge of this item.
Wed 28 Sep 2016 06:50:29 AM UTC, comment #4:

Another option would be to copy the first row(s) of the observation and only start writing the Kalman filter output from row>=down_opt[0]/2

Pieter kempeneers <kempenep>
Project AdministratorIn charge of this item.
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)

Pieter kempeneers <kempenep>
Project AdministratorIn charge of this item.
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

Pieter kempeneers <kempenep>
Project AdministratorIn charge of this item.
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 ?

Pieter kempeneers <kempenep>
Project AdministratorIn charge of this item.
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!

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by kempenep (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 18 Oct 2016 07:35:41 PM UTCkempenepStatusNeed Info=>Fixed
      Open/ClosedOpen=>Closed
    Tue 27 Sep 2016 07:19:06 PM UTCkempenepStatusNone=>Need Info
      Assigned toNone=>kempenep

    Back to the top


    Powered by Savane 3.1-cleanup1