is there a way to give protein sites non-sequential numbering?

[jbloom]

Context

In Nextstrain trees, is there a way to give protein sites non-sequential numbering for things like labeling branches and coloring by protein site? Right now I understand how you can pass a GFF to say define HA1 and HA2 to start at some position within the full coding sequence.

But people often use H3 numbering for other subtypes (like H7 and H5). Here the numbers of sites in the H7 or H5 HA are not always strictly sequential: if H7 has a deletion relative to H3 then the H3 numbering skips a site, and if H7 has an indel then there is a duplicate number (eg, site 133a). PDB files are often numbered this way.

Is there any established way to do this within Nextstrain trees?

Description

As an example, we currently use H3 numbering for mutations in a H5 HA. This mapping of numbering is shown here (see reference_site and sequential_site columns).

Possible solution

Perhaps one possible solution is to define a very complex GFF that defines a non-sequential feature, although this could not capture all forms of indels between the numbering schemes.

Not sure if @lmoncla @kistlerk @Haddox @jordan-ort have dealt with this?

[jameshadfield]

In terms of visualisation (Auspice) this is mostly not going to work. In theory you could use change the JSON to use reference-numbering and Auspice would display them, but the number couldn't be negative and couldn't include an {a,b} suffix; furthermore the entropy panel would now be essentially showing the reference (H3) genome.

If we want to make Auspice more useful for DMS / Influenza work then this presumably would be important. I'd think to do the bioinformatics in H5 coordinates and then include that mapping of H5-H3 numbering in the JSON for Auspice to pick up. Is that how you normally do things Jesse, or do you do the analysis in H3 coords?

[jbloom]

Yes, if something like this can be added at least we might use it sometime. But also just having clarification that is not currently possible is also helpful!

[kistlerk]

I would also find this very useful (thinking of my current trees with 16 HAs, where I maintain a tsv mapper on the side similar to what Jesse posted above) :)