Bug #12319
closed
cgfv3 files have errors in last tile path (0x35e)
Description
Some of the cgfv3 files located in l7g Data cgfv3 have errors in their last tile path (862, 0x35e).
For example, dataset huEA4EE5-GS01669-DNA_G02.cgfv3 only has 33 positions in that tile path whereas there should be a total of 35:
cgft -b 862 huEA4EE5-GS01669-DNA_G02.cgfv3 [ 169 -1 5 0 1 0 0 -1 0 0 0 0 0 0 0 0 0 0 1 -1 0 0 0 0 0 0 0 0 0 0 -1 0 37] [ 169 -1 5 0 1 0 0 -1 0 0 0 0 0 0 0 0 0 0 1 -1 0 0 0 0 0 0 0 0 0 0 -1 0 37] [[ 0 63 ][ ][ ][ ][ ][ ][ 903 1 ][ ][ 16 1 ][ ][ ][ 482 1 1003 1 1058 1 3262 1 4261 1 4705 1 4712 1 5094 1 5467 1 ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ 758 2 ]] [[ 0 63 ][ ][ ][ ][ ][ ][ 903 1 ][ ][ 16 1 ][ ][ ][ 482 1 1003 1 1058 1 3262 1 4261 1 4705 1 4712 1 5094 1 5467 1 ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ 758 2 ]]
I suspect this is because of incorrect handling of the last tilestep in the tilepath. If the last tile in the last tilepath is spanning, I think this is what triggers this error.
This ticket is to go through the cgfv3 files, figure out which ones have a bad last tile path and correct them.
When converting from CGFv2 to CGFv3, I (Abram) noticed an incorrect 0x35e SGLF file and updated it. After updating the SGLF file, I updated the corresponding CGF files. Since they used a new SGLF, I most likely needed to refer back to the FastJ and convert that way. Whatever method used to convert to the new format probably had a bug that missed the last tiles if they were non-anchor spanning. Though this should be checked, I suspect only the last tile path of having this issue as the other tile paths didn't need to be recomputed.
Updated by