Hi Jorge, rs17421133 is there for 129 and 130, it's just being filtered out by default now as it has been given a higher weight (less reliable) by dbSNP since it maps to more than one location in 129 and 130. Here's a detailed explanation from one of our engineers, with instructions in making it visible:
"This is due to a change this year in SNP track behavior: by default, items with weight > 1 (more than one mapping) are hidden by default. Up to build 128, dbSNP found only one chr6 mapping for rs17421133 (chr6:32118251), so its weight was 1 and it appears by default. Since build 129, dbSNP has mapped it to two locations (chr6:32118251 and chr6:32085516), so its weight increased to 2 and it does not appear by default. In order to see all SNPs regardless of weight, click into track controls, click on "+" button for filters, and change max weight to 3. We made this change because many SNPs that map to multiple locations may actually be slightly diverged tandem duplications or paralogs instead of population variation. It's helpful to cross-check with the Segmental Dups track." Please let us know if you have any additional questions: [email protected] - Greg Roe UCSC Genome Bioinformatics Group On 6/13/11 11:09 AM, Jorge Amigo Lechuga wrote: > hi, > > we are studying position chr6:32118251 based on hg18, where dbSNP tells us > that rs17421133 has been reported on dbSNP build 123, and which has been > present on dbSNP up to current build 132. but when using Genome Browser and > displaying all available dbSNP tracks we see rs17421133 displayed only on > builds 126 and 128, but not in builds 129 and 130. considering that dbSNP > should be the gold standard, are these 2 tracks wrong? > > note that browsing dbSNP builds 129 and 130 through Broad's IGV indeed shows > this rs17421133 on chr6:32118251 as expected. > > kindly regards, > jorge. > _______________________________________________ Genome maillist - [email protected] https://lists.soe.ucsc.edu/mailman/listinfo/genome
