[Biopython-dev] Genome Diagram Default Behavior

Leighton Pritchard Leighton.Pritchard at hutton.ac.uk
Wed Aug 1 10:53:19 UTC 2012

Hi all,

On 1 Aug 2012, at Wednesday, August 1, 10:27, Peter Cock wrote:

On Wed, Aug 1, 2012 at 1:37 AM, Zachary Charlop-Powers wrote:
However if you use  strand="None", Genome Diagram will draw
the features inline with the track and always in the positive direction.
For myself, and probably others, keeping the direction of the features is
immensely useful as you can often get a sense of operon structure in
prokaryote genomes just by looking at the genes.

That's true. I find it easiest to identify operon structure in that way (i.e. visually and approximately) by noting where the features swap between positive and negative strands. Other approaches might include colouring positive/negative/None strand features differently.

Of course the forward and
the minus strands can be drawn but condensing small sections of genes to a
single track saves space when making images.

It doesn't, if the single track is the same height as before - what differs is the whether the features on that track are half, or full, track height.

So, would it be possible to change the default behavior of Genome Diagram
to draw features inline (strand="None"), but to preserve their orientation?

I think there's a better way to get what you're after. Changing the default setting here would modify more than whether the arrow spans the whole track, and it would also mean that GenomeDiagram does not respect the strand data of features by default. I think that's a bad thing.

I think I know what you mean - that kind of picture is quite common
e.g. for viruses - but only where there are no overlapping genes
on opposite strands. GenomeDiagram was written originally primarily
for bacteria, were overlapping genes on opposite strands are more
common, which may explain the design choices made.

My original choice was made for a combination of reasons:

- I wanted to respect the strand information in the source data
- The 'box' sigil was easiest to draw, and was the first to be available (this carries no inherent directional information as an image)

The overlapping gene issue is relevant but, since the resolution of a drawn image is often such that boxes slightly overlap even when there is no feature overlap, it didn't feature in my consideration.

Currently strand controls both orientation (for arrows, no effect on
box sigils) and vertical placement (above, below, or straddling the
line). Basically you want to override the vertical placement only?
Note this is sigil dependent - it makes sense for the arrow, but not
the default box (which was originally the only sigil supported).

That's how I understand Zachary's suggestion: to draw an arrow with orientation preserved, but across the positive and negative strands of the track.

The good news is the underlying drawing code can do this - the
arrow drawing is just given a bounding box and the requested
orientation (left or right) argument set by the get_feature_sigil
method of the LinearDrawer or CircularDrawer.

If you need this right now, a careful hack in get_feature_sigil is
the way to proceed.

The question is how to most cleanly expose this to the user while
not breaking anything else (e.g. cross links), and ideally allow for
a related option which Leighton and I have considered […]

My original plan was to have more sigils available, implemented as draw_X() functions in the AbstractDrawer module. This would seem to be a good case for a draw_large_arrow() (or somesuch) function. The issue then would be a slight change to the prototypes for the existing draw_box and draw_arrow functions. Basically, we'd pass the overall bounding box and strand (x0, x1, btm, ctr, top, strand) information to the new functions, and let them decide where to place the sigil - above, below, or straddling the centre line.

Then, we could choose whether draw_arrow() takes an additional argument (e.g. straddle=True) for the behaviour that Zachary wants, or whether we use a new sigil ('large_arrow'), which could have its own function - just like that of draw_arrow() - but would probably be better implemented by just passing the straddle=True (or whatever) argument.

This way, the change is transparent to the user, except for perhaps choosing 'large_arrow' rather than 'arrow' as a sigil.

That suggests this setting might be best at the GenomeDiagram
feature level. Perhaps a new attribute/argument 'strand_mode',
(a) ignore strand for vertical placement (what you want)
(b) divide vertical space in two (current behaviour)
(c) divide vertical space in six (frame specific placement)

Hmm. Leighton?

I'm choosing to leave frame-specificity out of the discussion, for now ;)



Dr Leighton Pritchard
Information and Computing Sciences Group; Weeds, Pests and Diseases Theme
DG31, James Hutton Institute (Dundee)
Errol Road, Invergowrie, Perth and Kinross, Scotland, DD2 5DA
e:leighton.pritchard at hutton.ac.uk       w:http://www.hutton.ac.uk/staff/leighton-pritchard
gpg/pgp: 0xFEFC205C tel: +44(0)844 928 5428 x8827 or +44(0)1382 568827


This email is from the James Hutton Institute, however the views
expressed by the sender are not necessarily the views of the James Hutton
Institute and its subsidiaries. This email and any attachments are confidential and 
are intended solely for the use of the recipient(s) to whom they are addressed.
If you are not the intended recipient, you should not read, copy, disclose or rely on 
any information contained in this email, and we would ask you to contact the 
sender immediately and delete the email from your system.  Although the James 
Hutton Institute has taken reasonable precautions to ensure no viruses are present 
in this email, neither the Institute nor the sender accepts any responsibility for any 
viruses, and it is your responsibility to scan the email and any attachments.

The James Hutton Institute is a Scottish charitable company limited by guarantee.
Registered in Scotland No. SC374831
Registered Office: The James Hutton Institute, Invergowrie Dundee DD2 5DA. 
Charity No. SC041796

More information about the Biopython-dev mailing list