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 <[email protected]>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 <[email protected]> > 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 > > > [email protected] > > > http://lists.open-bio.org/mailman/listinfo/das > > > > > > _______________________________________________ DAS mailing list [email protected] http://lists.open-bio.org/mailman/listinfo/das
