| 3 | | In the future (when gBrowse supports bigbed) it is that if a user want to view data on a gBrowse the following happens |
| 4 | | * Produce a BigBed (for annotations such as Marker) / BigWig files (for decimal data such as QTL). This may take some time on first call, or if the files needs refreshing on change |
| 5 | | * Include in MOLGENIS suitable links towards the gBrowse instance that include loading of that custom track |
| 6 | | * Include in these files hyperlinks back to the molgenis instance |
| | 3 | Desired behavior: |
| | 4 | * As a user I want to view Marker and Probe on the genome (= annotations) |
| | 5 | * As a user I want to view QTL on the genome (= data set) |
| | 6 | * As a user I want to view genotypes per strain on the genome (= data set) |
| | 7 | * As a user I want to view gene expressions per individual on the genome (= data set) |
| | 8 | |
| | 9 | Proposed solution: |
| | 10 | * Per chromosome and per annotation produce a BED file, e.g. for all markers on ChrI |
| | 11 | * Per chromosome and per data set produce a WIG file, e.g. for QTL profiles on ChrI |
| | 12 | * Include in xQTL suitable links towards the gBrowse instance that include loading of the proper BED / WIG file(s) as custom track |
| | 13 | * Include in these files hyperlinks back to the molgenis instance that serves them |
| | 14 | We can cache these files so we don't need to update all the time. |
| | 15 | |
| | 16 | In case data sizes become an issue we should produce BigBed and BigWig files. |
