Possible code simplifications for SearchReadsExample

[cassiedoll]

• read cigar building is now available from utils-java
• instead of using a fixed chromosome list we can use the coverage API call (passing no args results in a very similar format to the hardcoded list

[pgrosu]

The coverage buckets are precomputed? I know the end is fixed, but if the targetBucketWidth is changed, wouldn't that require new on-the-fly meanCoverage computations?

~p

[calbach]

Coverage is precomputed at various bucket widths. The targetBucketWidth is floored to the nearest precomputed bucket width and that's what gets returned. The minimum bucket width is chosen such that it's not too much more expensive to compute the coverage yourself, if finer granularity is needed, i.e. the smallest bucket (2048 bases) contains about one page of reads for a 100x coverage read group set.

This is documented here.

That said, I think counting coverage at a specific single position, or perhaps even for all single bases is still a useful example.

[pgrosu]

Aha! Thanks CH for clarifying this for me. Yeah, I agree that in the future that type of granularity would help, but for now that the tried-and-true way of reads/search seems to work for <= 2048 base pairs. I tried that with a start and end = start+2048 with a pageSize of 3000, and I didn't get a nextPageToken at the end which is nice. And of course the trusted --count -1 never fails me, and seems to return a manageable number of reads:

$ java -jar genomics-tools-client-java-v1beta2.jar searchreads --read_group_set_id CMvnhpKTFhD04eLE-q2yxnU --start 2000000 --end 2002048 --reference_name 1 --count -1 --pretty_print --fields "alignments(fragmentName)" | grep fragmentName | wc -l
215
$

Thanks,
~p

[cassiedoll]

(updated initial comment to remove the suggestion of deleting the coverage example)