= Genome browser review =

An overview of genome browsers can be found at http://en.wikipedia.org/wiki/Genome_browser and tried them. Things that make them unsuitable (for integration) in my opinion are:

* Very limited application: e.g. aimed at just viral genomes or ChIP-seq data
* Externally hosted webapp, but not able to accept any custom user tracks
* Standalone application (e.g. download a JAR) which is very hard or impossible to integrate
* Not prefilled with community data, no added value (after starting, you get an empty screen, and you should import everything yourself)

So that took care of most of them. Left are:
* UCSC / Ensembl / NCBI style (an externally hosted webapp)
* jBrowse/GBrowse style (a self hosted webapp - typically, let's assume this for now)

Pro's/Con's for UCSC (et al):[[BR]]
* (+) Hosted, updated and maintained for you, saved a lot of trouble[[BR]]
* (+) Many existing tracks, and more added gradually[[BR]]
* (+) Ability to add custom tracks[[BR]]
* (+) Accepts many formats[[BR]]
* (-) Must upload to an external service, so performance is probably bad (though optimizable with very specific formats/services)[[BR]]
* (-) Makes your app dependent on an external service

Pro's/Con's for jBrowse (et al):[[BR]]
* (+) Host by yourself, so completely customizable, update whenever you want, uptime is under your control[[BR]]
* (+) Ability to add custom tracks[[BR]]
* (+) Accepts not so many formats, but can also run on top of databases[[BR]]
* (+) Runs locally on your own files, so good performance[[BR]]
* (-) Effort to set it up, keep it running, update it, fix problems or security breaches yourself, etc[[BR]]
* (-) Little or no default tracks, must setup and update the content yourself

Supplements:

* If you want, you can checkout the code + data for the UCSC or Ensembl browser to run a local mirror:
 Better for performance, but these tools are not light-weight systems, so maintenance can quickly become a full-time job...
 (if you want to support all species / data sets)
* The Ensembl browser is much more advanced: requires a bit more tweaking of the settings to your personal needs,
 but it always surprises me when people prefer to stick to the dated UCSC browser...

= xQTL GBrowse integration =

Desired behavior:
* As a user I want to view Marker and Probe on the genome (= annotations)
* As a user I want to view QTL on the genome (= data set)
* As a user I want to view genotypes per strain on the genome (= data set)
* As a user I want to view gene expressions per individual on the genome (= data set)

Proposed solution:
* Per chromosome and per annotation produce a BED file, e.g. for all markers on ChrI
* Per chromosome and per data set produce a WIG file, e.g. for QTL profiles on ChrI
* Include in xQTL suitable links towards the gBrowse instance that include loading of the proper BED / WIG file(s) as custom track
* Include in these files hyperlinks back to the molgenis instance that serves them
We can cache these files so we don't need to update all the time.

In case data sizes become an issue we should produce BigBed and BigWig files.
See http://bioinformatics.oxfordjournals.org/content/26/17/2204.full.pdf
== How to add GBrowse linkouts to MOLGENIS databases ==

=== Add a query option to the 'rubberband' menu where you can drag to select a genomic region ===

Open your GBrowse *.conf file. The rubberband menu has HTML elements and looks like this:

{{{
[DETAIL SELECT MENU]
width = 250
html  = <table style="width:100%">
         <tr>
           <th style="background:lightgrey;cell-padding:5">
             SELECTION
             <span style="right:0px;position:absolute;color:blue;cursor:pointer"
                   onclick="SelectArea.prototype.cancelRubber()">
               [X]
             </span>
           </th>
         </tr>
}}}

We add a table row with the linkout to a URL like this:

{{{
<tr>
  <td onmouseup="SelectArea.prototype.cancelRubber()">
    <a href="http://vm7.target.rug.nl/xqtl_unstable/api/find/org.molgenis.xgap.Marker?name=SELECTION" target="_BLANK">
    molgenis region query
    </a>
  </td>
</tr>
}}}

The value of SELECTION is a GBrowse notation, so the accepting service must be compatible with these requests. An example of a resulting request:

{{{
.../api/find/org.molgenis.xgap.Marker?name=chr1:3790000..4759999
}}}

At the moment there is no MolgenisService to facility this, but it the principles are trivial. [http://www.molgenis.org/changeset/9697 A first step was done] to enhance the existing filters for this purpose, but this is not GBrowse syntax yet. The multifilters [http://localhost:8080/xqtl/molgenis.do?__target=Markers&__action=filter_set&__filter_attribute=Marker_bpstart&__filter_operator=GREATER&__filter_value=15&__filter_attribute1=Marker_bpstart&__filter_operator1=LESS&__filter_value1=35 are used like this].

=== Add a popup balloon to an annotation track ===

Open your GBrowse *.conf file. In the track, which e.g. looks like this:

{{{
[hxb-sdp]
feature       = experimental_feature:hxb_sdp
database      = variations
}}}

We add a `balloon` property, with a hyperlink, like this:

{{{
balloon click = <h2>Marker $name</h2>
       <a href='http://vm7.target.rug.nl/xqtl_unstable/api/find/org.molgenis.xgap.Marker?name=$id'>Marker info from molgenis</a><br>
}}}

When clicking this link, it will request a marker by ID. The correct mapping for the $-variable to MOLGENIS entity attribute should be investigated on a per-database basis.

{{{
.../api/find/org.molgenis.xgap.Marker?name=1
}}}

== Online GBrowse at GWAS Central (HGV-Base) ==

http://www.gwascentral.org/browser/genome?r=HGVRS1375,HGVRS1374,HGVRS1373&t=

== Online GBrowse at WormBase ==

http://www.wormbase.org/db/gb2/gbrowse/c_elegans/?name=I:10747696..10779324