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

[Andy Jenkinson]

Hi Prem,

The test range does not really provide enough information - it only provides a single identifier, and does not help identify which of Ensembl's sequences that refers to and so cannot be a generic solution. It's true that Ensembl could make some assumptions and implement an ad-hoc solution for this specific case (similar to the hack you have applied) but this would not be compliant with the DAS specification and would be confusing for other DAS clients. In the past we have found that supporting non-standard functionality has been very confusing for others and is a major reason for inconsistency of DAS implementation today. For that reason, I would suggest that it is better to do the conversion in the server. I'm actually surprised it does not do this already, as I seem to remember when Lincoln was working on updating gbrowse for DAS 1.6 that things worked OK with Ensembl.

Cheers,
Andy

On 7 Jan 2011, at 17:56, Prem Anand wrote:

> 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
> 
>