Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SAM: PNEXT 0 with RNEXT = #510

Open
jkbonfield opened this issue Jun 17, 2020 · 0 comments
Open

SAM: PNEXT 0 with RNEXT = #510

jkbonfield opened this issue Jun 17, 2020 · 0 comments
Labels

Comments

@jkbonfield
Copy link
Contributor

The SAM spec has the following two statements.

If RNEXT is *, no assumptions can be made on PNEXT and bit 0x20.

If PNEXT is 0, no assumptions can be made on RNEXT and bit 0x20.

Firstly it should probably say "FLAG bit 0x20".

Also if RNEXT is = and PNEXT is 0 then logically we're saying we can't make assumptions on RNEXT and due to PNEXT and therefore we can't complain that PNEXT is invalid because of RNEXT not being *. That seems a little circular, but perhaps it's consistent.

I raise it though because this specific case causes htslib to turn PNEXT to * as it says position 0 must mean unmapped. Htsjdk also warns about this case, but at least doesn't modify the data.

Personally I think it's an htslib bug as it has no right to change the data, even if it wishes to warn about it, but thought I'd run it past the other maintainers first.

The only spec nuance here really is is it justified to want to say the mate maps somewhere else on this chromosome, but we don't have the exact coordinate (maybe it was just a crude kmer hit) so we wish to list it as unknown? The spec appears to forbid this, but it's a bit tenuous.

@jkbonfield jkbonfield added the sam label Jun 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: To do (backlog)
Development

No branches or pull requests

1 participant