BAM files are, at least as far as I know, simply binary compressed versions of SAM files. They have the exact same information and are used in the same way. Why then does the SAM format use a 1-based coordinate system while BAM uses a 0-based one?
This is the relevant section of the SAM format specification (emphasis mine):
1-based coordinate system A coordinate system where the first base of a sequence is one. In this coordinate system, a region is specified by a closed interval. For example, the region between the 3rd and the 7th bases inclusive is [3, 7]. The SAM, VCF, GFF and Wiggle formats are using the 1-based coordinate system.
0-based coordinate system A coordinate system where the first base of a sequence is zero. In this coordinate system, a region is specified by a half-closed-half-open interval. For example, the region between the 3rd and the 7th bases inclusive is [2, 7). The BAM, BCFv2, BED, and PSL formats are using the 0-based coordinate system.
The two coordinate systems are a very common source of error in bioinformatics, so there must be some reason why these two largely equivalent formats use different systems. For that matter, why do the VCF and BCF formats, whose relationship is equivalent to that between SAM and BAM, also do this? I am guessing there is a good reason and it is equally applicable to both pairs of sister formats.
samtools view in.bam chr1:1-1000
may have a different output thansamtools view --bam in.bam chr1:1-1000
, give that the latter writes a BAM where the former writes a SAM? $\endgroup$samtools
manual states that "all position coordinates are 1-based" when giving regions, so it must handle the conversion internally. Indeed, I can confirm that this commandmd5sum <(samtools view -b sample.bam chr1:36931633-36931871 | samtools view) <(samtools view sample.bam chr1:36931633-36931871)
returns identical md5sums for both inputs. $\endgroup$RNAME[:STARTPOS[-ENDPOS]]
notation is 1-based regardless of what input or output it's used with; meanwhile specifying the same regions via-L BEDFILE
is naturally 0-based as expected for a BED file. (Internally it's all converted to 0-based half-open as that's the natural representation for doing interval arithmetic.) $\endgroup$