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

Extend usefulness of tip labels #1668

Merged
merged 2 commits into from
Aug 28, 2024
Merged

Extend usefulness of tip labels #1668

merged 2 commits into from
Aug 28, 2024

Conversation

jameshadfield
Copy link
Member

The motivating use case is the proliferation of datasets using an accession for node.name but who wish to see node names of another piece of metadata. See commit messages for more details.

Using our current monkeypox/mpxv dataset with the following differences:

  • node.name is the accession (which is the uniq ID used throughout the pipeline). This removes the need for the pipelines to use JSON-modification scripts such as set_final_strain_name.py.
  • "strain" is added to node_attrs reflecting the original strain name. (Any name can be used here.)
  • "tip_label": "strain" added as a display_defaults
  • "strain" added to filters and colorings

On hover boxes show both the chosen tip-label and the underlying node name (accession). (On-click modals are similar)
image

Filtering to duplicate strain names works intuitively
image

@nextstrain-bot nextstrain-bot temporarily deployed to auspice-node-name-nfdhwoehmtis June 8, 2023 04:41 Inactive
@jameshadfield
Copy link
Member Author

You can test the above dataset using this PR at https://nextstrain-s-nextstrain-wpreme.herokuapp.com/staging/monkeypox/mpxv/auspice-pr-1668

@victorlin
Copy link
Member

There's conflicts with files I've edited since this PR was opened. Addressing them with a rebase onto latest master.

@victorlin victorlin force-pushed the node-name branch 2 times, most recently from 56d531e to b837f36 Compare October 31, 2023 00:20
@victorlin victorlin temporarily deployed to auspice-node-name-mdhdakef6deq November 2, 2023 18:48 Inactive
@victorlin victorlin self-requested a review November 2, 2023 18:48
Copy link
Member

@victorlin victorlin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I played around on the review app. Overall nice improvements! Just a few minor things.

src/components/tree/infoPanels/click.js Outdated Show resolved Hide resolved
src/components/tree/infoPanels/hover.js Outdated Show resolved Hide resolved
src/components/tree/infoPanels/hover.js Outdated Show resolved Hide resolved
src/components/tree/infoPanels/hover.js Outdated Show resolved Hide resolved
Any normal `node_attr` in the tree can be used as a tip label, as well
as the special-cases of strain-name and "none". Previously we only
allowed valid colorings. Normal here means a node_attr value which is an
object with a "value" key, thus excluding special-cases such as "div",
"hidden", "vaccine" etc - see the JSON schema for more context
<https://github.com/nextstrain/augur/blob/master/augur/data/schema-export-v2.json>
jameshadfield added a commit to nextstrain/mpox that referenced this pull request Aug 26, 2024
This is a companion commit to changes in Auspice <nextstrain/auspice#1668>
which allow any node-attr to be used as the tip label and which displays
this tip label in the node hover/click boxes as well as alongside nodes
(at suitable zoom levels). This allows us to drop the `set_final_strain_name`
script and ensures all node names are unique which improves the behaviour
of Auspice

This commit only changes the Nextstrain datasets, not the Nextclade ones
@jameshadfield
Copy link
Member Author

jameshadfield commented Aug 26, 2024

I've rebased this onto master and also simplified the process by allowing any node_attr to be used as a strain name rather than only colourings. See nextstrain/mpox#275 for a PR showing the corresponding changes which make use of this PR:

mpox testing datasets available at:

or use this test version of auspice.us

@j23414 / @kimandrews if you have any applicable datasets could you test them here?

Copy link
Contributor

@joverlee521 joverlee521 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes make sense to me.

Used nextstrain/zika#72 to produce testing zika dataset for the new Auspice view.

Comment on lines +40 to +44
for (const [attrKey, attrValue] of Object.entries(d.node_attrs || {})) {
if (typeof attrValue === 'object' && 'value' in attrValue) {
nodeAttrKeys.add(attrKey)
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-blocking, probably more of a change in Augur

I was looking at the augur export schema to figure out which attrs this would be included here. Worth noting that we would not be able to use accession as the tip label because it does not use the value key.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's a good point. I wish we had made the schema so that every node-attr was the same structure.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to refrain from addressing this here, but I do think moving all node_attrs values to objects will reduce complexity in Auspice a lot, see for example all these different getters. We don't have to do this on the augur side (necessitating schema changes and all that), we could probably do it within treeJsonProcessing.js.

@@ -56,10 +62,7 @@ export function collectAvailableTipLabelOptions(colorings) {
*/
{value: 'none', label: "none"},
{value: strainSymbol, label: "Sample Name"},
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One oddity I noticed here is the hardcoding of node.name to "Sample Name" which is a little jarring when we use accessions for node.name.

Copy link
Member

@victorlin victorlin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple small nits and a bug

src/components/tree/infoPanels/helpers.js Outdated Show resolved Hide resolved
CHANGELOG.md Outdated Show resolved Hide resolved
src/components/tree/infoPanels/hover.js Outdated Show resolved Hide resolved
This generally better reflects the intention of changing the tip label
key, which was previously only reflected in text drawn to the RHS of
tree nodes at certain zoom levels.

The motivating use case is the proliferation of datasets using an
accession for `node.name` but who wish to see node names of another
piece of metadata. This is possible by adding the desired name as a
node_attr and (optionally) setting this as the default tip label.

Note that the order of items in the node-clicked modal has been
slightly altered and is now more consistent across internal branches,
terminal branches & tips
@jameshadfield jameshadfield merged commit e62fde9 into master Aug 28, 2024
26 checks passed
@jameshadfield jameshadfield deleted the node-name branch August 28, 2024 20:39
jameshadfield added a commit that referenced this pull request Sep 10, 2024
This fixes a bug introduced in #1668 where the node name wouldn't be
shown when the selected tip label is "Sample Name".

Closes #1847
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

4 participants