# Defining a bedfile for chromosome X without pseudo-autosomal regions

I would like to define a bedfile for chromosome X, to target only basepairs outside of pseudo-autosomal regions (and going forward other regions, too).

First, I wasn't able to find an already prepared bedfile in any of the online repositories (but let me know if it is available somewhere).

Second, I compiled the bedfile for all basepairs in chromosome X as a starting point (by looking at the latest assembly at genome browser):

chrX    0       156040895       # as defined at https://genome.ucsc.edu/


The genome browser is 1-based and the last base is inclusive, while the bedfile is 0-based and last base is not inclusive, therefore I had to subtract 1 from the bed start.

Afterwards, I wanted to exclude the pseudo-autosomal regions as defined at this page. However, I am not sure if basepair "Start" and "Stop" are 0- or 1-based and inclusive/not inclusive. I might use the same convention used on the genome browser, but I am not sure if that's correct in this case. I wasn't able to find this information on their website or online.

Assuming that the NCBI "Start" and "Stop" field follow the UCSC parameters (1-based and inclusive), the resulting bed (PAR regions excluded) might be the following:

chrX    0       10000
chrX    2781479 155701382


Edit: the section on the centromeres has the "Length" parameter, from which I could infer that "Start" and "Stop" base-pairs are both inclusive. At the same time, the "Stop" base-pair of PAR#2 in chromosome X is base-pair 156,030,895, which is also the last base-pair number if we were considering the UCSC genome browser notation (1-based and inclusive). Therefore, it seems to me clear that the same notation is used, and the proposed bed-file should be correct.

The UCSC Genome Browser renders data visually with a one-based, closed index. The underlying data are often stored and presented as files worked with on the command-line, using zero-based, half-open coordinates.

This difference in indexing can be important when using the website to view data or when using the download tools to grab a dataset for offline calculations, such as files in BED format.

There is a good overview of indexing on Biostars.

To solve this in a general way:

The UCSC Kent Utilities fetchChromSizes tool can be used to retrieve the sizes of chromosomes for your genome assembly of interest, e.g. hg38.

Using this assembly, to build a sorted BED file for set operations:

$$fetchChromSizes hg38 | grep -v '_*_' | awk -v FS="\t" -v OFS="\t" '{ print 1, "0",$$2 }' | sort-bed - > hg38.bed


Replace hg38 with your assembly of interest.

To then filter this for chrX:

$$awk '($$1=="chrX")' hg38.bed > hg38.chrX.bed


The intervals in hg38.bed and hg38.chrX.bed use a zero-based, half-open coordinate system.

To then get regions of chrX without autosomal regions, you could define a sorted BED file containing those regions, which also use zero-based, half-open coordinates:

$echo -e 'chrX\t10000\t2781479\nchrX\t155701382\t156030895' > pseudoautosomal.chrX.bed  I am assuming that the coordinates on Ensembl and NCBI use one-based indexing. Converting to a zero-based index requires subtracting one base from the start positions of these intervals. It would be ideal if these groups were to clarify the indexing they use. I am making this assumption based on how Ensembl defines regions on chrY, which start at position 1 and not 0, as one would expect to see with a one-based coordinate system. The numbers reported on Ensembl and NCBI are otherwise identical, so I also assume that NCBI's numbers use the same indexing and require the same correction to the start base. In any case, to calculate the difference between these regions and chrX: $ bedops --difference hg38.chrX.bed pseudoautosomal.chrX.bed > answer.bed


This is what my output looks like:

\$ more answer.bed
chrX    0   10000
chrX    2781479 155701382
chrX    156030895   156040895


These coordinates are in BED format and so use a zero-based, half-open coordinate system, by convention.

To turn these into one-based, closed coordinates — to query signals over exact regions in the UCSC Genome Browser, for instance — you would add one base to the start positions of each genomic interval.

(Edit: Fixed PAR#2 start coordinate per comment.)

• Thank you, great answer! I will look more into that, to understand why our results differ. I could spot one mistake on mine, I missed the 10k bp at the end.
– gc5
Sep 17 at 23:00
• Another caveat if you work with a mix of data from UCSC and Ensembl is that they pick different naming schemes for chromosomes. For instance, chrX is X in Ensembl world. If you use set operation tools or awk, Python scripts, etc. to process BED files, the name scheme you use should be consistent over files, either one or the other, in order to get correct results. This is easy to fix, but can also be easy to overlook. Sep 18 at 1:28
• Is there a problem with your command: echo -e 'chrX\t10000\t2781479\nchrX\t155701383\t156030895' > pseudoautosomal.chrX.bed? Why in the first line the start is 10000 (Start in PAR#1, - 1) and the second line is 155701383 (Start in PAR#2, without -1)? To summarize, why you subtracted 1 from the first line "Start" and not from the second? Thanks! (I am assuming you got the "Start" numbers from ncbi.nlm.nih.gov/grc/human)
– gc5
Sep 20 at 16:38