trackdb
Lachlan Musicman
Can someone please explain why I would want to define a trackdb_local?
let's build quiet armies friends, let's march on their glass towers...let's build fallen cathedrals and make impractical plans
- GYBE
Jonathan Casper
Hello Lachlan,
Thank you for your question about trackDb tables. The primary reason to use a trackDb_local table instead of just adding things directly to the main trackDb table is that you risk collisions with UCSC tables. It is not likely to be a problem with an assembly that you added to your own mirror. Maybe it would come up if UCSC also released a droBir1 assembly, and if you then attempted to download our database tables to update your own tracks. A scenario where trackDb_local makes more sense would be if you wanted to maintain an up-to-date copy of the tracks that we provide for the human hg38 assembly while also adding your own tracks. In that case, trying to use a single trackDb table would require comparing table records to incorporate our regular updates while not overwriting your own track entries. It would probably be easier to just use your own separate trackDb_local table for your own tracks, and regularly rsync UCSC's trackDb table for the updates.
Having separate tables and update processes for your own tracks also helps emphasize the difference between your own data and anything included in the kent repository, which can be helpful for future maintenance of your mirror.
A bit more information on this is included at http://genomewiki.ucsc.edu/index.php/Local_tracks_at_mirror_sites.
I hope this is helpful. If you have any further questions, please reply to gen...@soe.ucsc.edu or genome...@soe.ucsc.edu. Questions sent to those addresses will be archived in publicly-accessible forums for the benefit of other users. If your question contains sensitive data, you may send it instead to genom...@soe.ucsc.edu.
--
Jonathan Casper
UCSC Genome Bioinformatics Group
--