基因结构可视化，是不是有坑？！

写在前面

昨天建立了TBtools使用交流群-5，很快就快200人。主要还是感谢大家帮手推广。刚才看到一个有趣的问题，正好，我手上在等一个流程的运行，那就大体写写。

TBtools输出的基因结构和GSDS_v2输出的基因结构不一样？

以下贴图

大体就是这位朋友或许并不相信TBtools的输出，我早已习惯这类，所以也没有太多脾气（其实不相信的，就不要用就行啦）。
GSDS是非常老牌的网页工具，功能强大，非常适合用于做基因结构展示，我本人非常仰慕这个网站的作者以及其维护团队。在我刚刚接触生物信息数据时，那会我还帮忙一个师兄本地化了GSDS网站。
这是一个相对繁琐或者复杂的操作，主要是系统环境的配置等等。但无论如何是需要本地化这个网站的，因为这个GSDS是面对全世界的互联网用户的，所以负载是一个问题。这个跟一些云平台一样，如果你不进行收费或者从其他方面变现，那么纯粹的公益，是非常难坚持的。当然，也还有一种做法，就是量力而行。公益可以做，但是保证在能力范围内。所以大多数网页服务类网站，会对用户的输入进行一定的限制。GSDS对基因的数目还是文件大小有一定的限制，超出这个限制，用户需要自行本地化一个。事实上，我认为该团队能维护这个网页服务至今，着实很不容易。
直到后面，我看到课题组有师妹需要做基因结构可视化，想来这个东西事实似乎并不复杂，于是我就在TBtools里面写了一个基因结构可视化功能（纯粹的Java码从零实现，与GSDS无关）。我当然没想到，很快会有一些使用人群。用户的增加，加上使用交流群的活跃。
我自认为，基于用户的反馈意见，目前这个工具很稳健，而且功能似乎也是比较完善。

回到主题

事实上，我确实没看明白这位朋友提出的问题。后续他给出另外的信息

我仍然没看懂，不过我事实上认为：

1. GSDS v2 几乎不可能有问题，所以他没错
2. TBtools 这个功能经过数百上千人测试，也不会有错
3. 那么就只有他错

事实如下

问题其实很简单，他将同一个gff文件输入到GSDS和TBtools，然后得到了看起来并不相同的结果：

1. GSDS 只显示Exon
2. TBtools 显示了CDS，也显示了UTR

那么问题就在于，用户提供的文件里面，并没有UTR

但这正是TBtools开发过程中我个人的一些想法的融入

TBtools在基因结构可视化上的考虑

虽然我使用过GSDS，不过我并没有去研究过源码。事实上，我很少看别人的源码，因为我真的看不懂。那次的使用经验告诉我，如果我来写一个工具，那么我会考虑其他一些相对常见的情况：

1. gff3/gtf文件，两种格式应该同时自动支持
2. 不应该由用户自行准备gff3或gff文件的子集，因为文件可能很大，比如100Mb，从其中抽取子集，可能会有麻烦。所以应该允许用户直接提供原始的gff3或GTF文件，软件自动完成提取并可视化
3. 基因结构的展示，常常主要目的是看编码区域的变化，所以CDS是一个核心。加入一个文件只有CDS和mRNA，那么应该考虑两者的边界，如果边界不一致，那么问题很简单，剩余的部分是UTR。所以在上述情况下，TBtools自动计算出UTR
4. 蛋白结构域坐标应该支持自动映射到基因外显子内含子坐标
5. ....

事实上，还有很多。TBtools当然也支持非编码序列的基因结构可视化，那种情况就只有Exon。

大体上，用一张图来说明TBtools就基因结构可视化的一些特点

请注意，图形是可以交互了。你可以快速的批量的：
1.修改颜色
2.修改字体
3.修改性状
4.....

写在后面

用了半个小时，写了一个推文。总的来说，没有一个工具是完美的，但是有一些工具是活着的。