Good afternoon Angie, Thanks a lot for your response. Now I'm confident that what I have done was ok and that it wasn't a waste of time.
>From my point of view, the best way of representing data is as a table: a heading with registries like primary tables are represented. BedGraph is the closest format I found, but still lacks the headings and have (#) comments between results, which is something I can handle but not the best. I appreciate your offering of putting this request into the log even if it will take some time to be done. So, now that you open to me the possibility of a format request, my request will be: -. Please add a table format, like that used to display the results of primary tables, to all non primary table data, including wigData types. Thank you very much again. All the best, Diego El día 13 de marzo de 2012 10:56, Angie Hinrichs <[email protected]> escribió: > Hi Diego, > > There are several different underlying data representations for tracks > rendered as "wiggles" -- the intuitive but large bedGraph, the newer bigWig > binary indexed files, and wiggle database tables that contain statistics for > windows of 1024 data values and indices into binary files that contain the > lossy-compressed data values. The database table is only half of the story, > which is why hgWiggle is required (not just mysql access). > > If the Table Browser had a bedGraph option for output format of any > wiggle-like track, would that suit your needs? We could log that as a > feature request but are pretty oversubscribed so I have no idea when it would > be done. In the meantime, we have a script that can translate the Table > Browser's "data points" output format (variableStep) into bedGraph -- > attached. (It is also in our source tree, > kent/src/hg/makeDb/hgLoadWiggle/varStepToBedGraph.pl.) > > Hope that helps, and please write to [email protected] if you have any more > questions, > > Angie > > ----- Original Message ----- >> From: "Diego Pereira" <[email protected]> >> To: "Hiram Clawson" <[email protected]> >> Cc: [email protected] >> Sent: Tuesday, March 13, 2012 4:02:48 AM >> Subject: Re: [Genome] Format request >> Good morning (again), >> >> Well it seems I have had a huge confusion. >> I thought wig tables had different experimental/predicted data than >> those directly accessible through MySQL. >> While this seems to be true for the map group, it doesn't seems to >> apply for the other groups (expression, regulation, compgeno). >> Am I right? >> If the aforementioned turns to be true, what are they used for? >> >> I have to say that I read the web pages that explain the different >> formats you use. >> But I didn't find anywhere an answer for this question. >> >> Regards, >> >> Diego >> >> >> El día 13 de marzo de 2012 03:47, Diego Pereira >> <[email protected]> escribió: >> > Good morning Hiram, >> > >> > Well that didn't work through MySQL workbench, so ODBC won't be >> > useful >> > for those datafiles. >> > I'll keep fighting with the variety of formats retrieved with the >> > table browser. >> > In any case I think my proposal makes sense: all the results being >> > displayed in a single and consistent format. >> > Hopefully you take it into consideration. >> > >> > All the best, >> > Diego >> > >> > El día 12 de marzo de 2012 16:25, Diego Pereira >> > <[email protected]> escribió: >> >> Good afternoon Hiram, >> >> >> >> Thanks for your answer. >> >> I'll do the tests late tonight or tomorrow. >> >> >> >> I would like to ask: >> >> Will the hgWiggle command work through an ODBC connection? >> >> Elaborating a little bit more: >> >> >> >> I really don't want to download huge files to my pc, just the >> >> results >> >> for the position I query. >> >> Kent's source is really great, but to be able to use it on my >> >> environment I'll have to rewrite tons of things, which is like >> >> reinventing the wheel. >> >> Also if I install cygwin some programs I use get messy (i.e. Ruby). >> >> >> >> For those reasons I would like to stick with the table browser. Is >> >> simple, you already did the hard work and I don't have to worry >> >> about >> >> file extensions/types. >> >> On the other hand through ODBC I can query all primary tables by >> >> position but not wigData files (they just contain an hyperlink) >> >> So, this string >> >> >> >> hgWiggle -db=ce6 -chr=chrI -doStats gc5Base >> >> >> >> Will work though ODBC? >> >> >> >> All the best and as always many thanks. >> >> Diego >> >> >> >> El día 12 de marzo de 2012 15:46, Hiram Clawson >> >> <[email protected]> escribió: >> >>> Good Afternoon Diego: >> >>> >> >>> You may find it more convenient to work with these tables >> >>> from command line operations at your site. You can use >> >>> the public MySQL server with the downloaded .wib files >> >>> for ordinary wiggle tracks: >> >>> http://genomewiki.ucsc.edu/index.php/Using_hgWiggle_without_a_database >> >>> >> >>> And any track with a bigWig type can be used with its URL >> >>> to the hgdownload server. >> >>> >> >>> With the command line commands you can format the wiggle data >> >>> in any of the available formats. >> >>> >> >>> --Hiram >> >>> >> >>> ----- Original Message ----- >> >>> From: "Diego Pereira" <[email protected]> >> >>> To: [email protected] >> >>> Sent: Monday, March 12, 2012 2:25:17 AM >> >>> Subject: [Genome] Format request >> >>> >> >>> Good morning, >> >>> I've been working with several tables at the table browser, and >> >>> I've >> >>> found really difficult and time consuming to automatize the >> >>> organization of my results due the format they are displayed. >> >>> This happens mainly with the results of wigData. >> >>> However, by using the Kent's source I found that using the >> >>> bigWigToBedGraph utility most of the results (at least those I >> >>> have >> >>> tried) are displayed uniformly with a format consistent with those >> >>> retrieved from primary tables. >> >>> I believe it can be great that the default way for displaying the >> >>> results at the table browser were in this format. >> >>> Of course I don't know how difficult it can be to do this, or if >> >>> there >> >>> are some reasons that not allow this shift in formatting. >> >>> In that case please accept my apologies. >> >>> Anyway, is just an idea that will probably help many people in >> >>> spending less time in the organization of their results . >> >>> All the best, >> >>> Diego >> >> _______________________________________________ >> Genome maillist - [email protected] >> https://lists.soe.ucsc.edu/mailman/listinfo/genome _______________________________________________ Genome maillist - [email protected] https://lists.soe.ucsc.edu/mailman/listinfo/genome
