[DAS] GBrowse as DAS server+Ensembl as DAS client

[Prem Anand]

Thanks Andy,

You are right about the compatibility issues. However, I thought the clients
could also handle this as for example, the ensembl client first queries the
server for /das/sources/, and as it already has all the information it needs
to make a das request properly from the 'test_range' and other attributes,
it can make the request suiting the server as well.

Anyway, we have to see what gbrowse developers have to say.

Cheers
Prem


On Fri, Jan 7, 2011 at 5:33 PM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

> Hi Prem,
>
> Each DAS coordinate system (e.g. GRCh_37 chromosomes) should always use the
> same sequence names between all DAS servers. In fact, compatibility between
> DAS servers is the primary reason for coordinate systems to exist. This
> allows all clients and servers to be sure that if they use the same
> coordinates then they can communicate with each other without having to know
> anything about each particular client/server. In truth the difference
> between the sequence names used by different genome browsers is a headache,
> and the net result is that coordinates are effectively defined by whoever
> uses them first (in this case being Ensembl). So, the GRCh37 coordinates use
> names like 1, 2, 3, X, MT as defined by Ensembl's reference server.
>
> So gbrowse will need to detect this if it is to work properly, and also
> report a test_range without the "chr" prefix. As an aside, I believe UCSC
> (who also use the chrX format) do this conversion in their DAS server and
> can handle both formats.
>
> Cheers,
> Andy
>
> On 7 Jan 2011, at 16:49, Prem Anand wrote:
>
> > Hi
> >
> > We are trying to set up our GBrowse as DAS server and were testing it
> with
> > ensembl as client.
> >
> > We have the right metadata in the datasource.conf file.
> >
> > <COORDINATES uri="
> http://www.dasregistry.org/dasregistry/coordsys/CS_DS311"
> > authority="GRCh" test_range="chr1:114356433..114414381" taxid="9606"
> > version="37" source="Chromosome">GRCh_37,Chromosome,Homo
> > sapiens</COORDINATES>
> >
> > The server responds for /cgi-bin/das/sources (also /cgi-bin/das/dsn)
> well.
> > We also tried with different capabilities locally and it seems to be
> fine.
> >
> > In all our GFF files/gbrowse databases we name the chromosomes prefexing
> > with 'chr' as given in the test_range.
> >
> > But ensembl client seems to ignore the test_range and is making the
> request
> > as shown below ( from http access log)
> >
> >
> /cgi-bin/das/01_Hs_GRCh37%7CASSOC_VARIANT/features?segment=1:114355433,114415381;maxbins=872
> > HTTP/1.1" 200 345 "-" "Ensembl/60"
> >
> >
> > And as GBrowse server doesn't recognise the region
> (1:114355433,114415381),
> > it doesn't return anything back.
> > In cgi-bin/das script, approximately at around line 860, if I prefix the
> > $reference with 'chr', it works.
> >
> > foreach (@segments) {
> >        my ($reference,$refclass,$start,$stop) = @$_;
> >
> >        if($reference !~ /^chr/){
> >         $reference = "chr".$reference;
> >        }
> >
> >
> > We are not happy with this fix and wondering if it is a ensembl client
> issue
> > or gbrowse server issue.
> >
> > Shouldn't ensembl make the right request figuring out the right url from
> > 'test_range'?
> > OR
> > If GBrowse server has to handle it in a better way?
> >
> > Any directions would help.
> >
> > Many Thanks
> > Prem
> > _______________________________________________
> > DAS mailing list
> > DAS at lists.open-bio.org
> > http://lists.open-bio.org/mailman/listinfo/das
>
>