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

[Prem Anand]

Thanks Andy.

If there is no other alternative, then we will fix it on our side.

Cheers
Prem

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

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