[Genome] Annotation tracks and genome builds

[Archana Thakkapallayil]

Hello Micah,

Our developers are discussing possible solutions for implementing this 
feature in our custom track manager. I will get back to you in a few 
days. In the meantime, there is a way to specify a db in the custom 
track URL, in case that would work for you.

http://genome.ucsc.edu/cgi-bin/hgTracks?db=organism_name&position=chr_position&hgt.customText=URL.

Please see this help page for more information:
http://genome.ucsc.edu/goldenPath/help/customTrack.html#SHARE

In general, custom tracks expire 48 hours after they were last accessed. 
It won't change if you switch the assemblies. The exception to this rule 
is custom tracks that are saved as part of a session.  (Note, however, 
that we do not guarantee that the custom tracks saved in sessions will 
exist forever . You may need to reload them if we experience a power 
outage or some other disturbance or if you do a cart reset.  But they 
are not purposely removed after 48 hours of non-use.)

I hope this information helps.  If you have any further questions, 
please do not hesitate to write back to this list.

Regards,

Archana
UCSC Genome Bioinformatics Group

Micah Berman wrote:
> I am currently using custom annotation tracks on the UCSC browser, 
> mostly simple BED formatted lists.  I was wondering if there is a way in 
> the track or browser data of these annotation tracks to define which 
> build of the genome (eg. hg17) these tracks belong to.  I understand 
> that on the top of the page where I upload these files I am able define 
> the build from a drop-down list, but is there a way to define the build 
> intrinsic to the annotation file (like a track or browser line 
> definition)?  I would be more comfortable knowing that my files will not 
> erroneously align with the wrong build. 
>
> One the files are uploaded, are these BED definitions linked permanently 
> to the build with which they were uploaded?  Do they change if I switch 
> builds on the browser?  I'd appreciate your help in learning more about 
> this issue.
>
> Thanks,
>
> Micah Berman
>
>