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

Allow use of different primary feature identifier in outputs #84

Closed
pinin4fjords opened this issue Feb 23, 2023 · 4 comments
Closed

Allow use of different primary feature identifier in outputs #84

pinin4fjords opened this issue Feb 23, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@pinin4fjords
Copy link
Member

Description of feature

It is sometimes useful to use a different primary feature identifier in output files than the one from the input matrix. We should allow that conversion to happen as part of processing.

I imagine this being a simple local module that remaps matrix identifiers early on in the workflow by referencing the feature annotation table.

@pinin4fjords pinin4fjords added the enhancement New feature or request label Feb 23, 2023
@grst
Copy link
Member

grst commented Dec 3, 2024

Common use case: Use ensemble identifier as unique primary identifier, but still show gene symbols in plots, and use Gene sets based on gene symbols.

@pinin4fjords
Copy link
Member Author

Common use case: Use ensemble identifier as unique primary identifier, but still show gene symbols in plots, and use Gene sets based on gene symbols.

Actually I think that use case should be served by maintaining both ids and symbols, and converting to symbols close to where you need to plot. The pipeline has a parameter for the name field for exactly this reason. Symbols in particular are not good primary identifiers- they are not unique, and are missing on a number of genes.

I don't actually remember the use case I had in mind when I wrote this...

@grst
Copy link
Member

grst commented Dec 3, 2024

Ok, then it sounds like it's already covered. Shall we close the issue then?

@pinin4fjords
Copy link
Member Author

As I say, I think I had something different in mind when I wrote this. More a case of mapping actual identifiers (rather than names). But I don't remember why, so we may as well close until I remember.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants