Giter Club home page Giter Club logo

oztree's Introduction

This README file contains instructions for installing a private copy of OneZoom, either the tree explorer or the entire website.

Details of how to customize the OneZoom javascript viewer, along with information about the OneZoom APIs, are available by following the instructions below, then opening the compiled markdown file (at OZprivate/rawJS/OZTreeModule/docs/_compiled.markdown or if you are running your own private OneZoom web server, at /dev/DOCS - for example, https://127.0.0.1:8000/dev/DOCS).

If you simply want to run a local copy of OneZoom, but not modify the code yourself, we recommend using our Docker image. The rest of this README provides details for compiling and running a OneZoom instance (something that is done under the hood when creating the docker image).

OneZoom setup

Installing in a Docker Dev Container

If you are using Visual Studio Code or another editor that supports Dev Containers, the easiest way to set up a full development environment is to use the included Dev Container configuration. This will automatically create two containers: one for development (dev), and another (web) with the MySQL database and production web server (nginx + uwsgi), derived from the Docker image mentioned above. Your source code will be mounted simultaneously into both containers: dev will let you run build commands and web will serve it as a web server you can access via port forwarding. You can also run your own server from the dev container by running web2py.py directly -- this is particularly useful for debugging.

If you are using Visual Studio Code, perform the following steps (you will need to modify these for another editor):

  1. Follow the instructions at either https://hub.docker.com/r/onezoom/oztree or https://hub.docker.com/r/onezoom/oztree-complete to save a docker image with IUCN data.
  2. Follow the VSCode instructions for installing Dev Container support.
  3. git clone https://github.com/OneZoom/OZtree into the directory of your choice. If using Windows, it is highly recommended to clone on the WSL2 filesystem both for performance reasons and to avoid permissions issues. If you wish to fork the repository and clone your fork, you will need to copy the tags from upstream, otherwise you will see build issues later. You can do this with git fetch --tags upstream followed by git push --tags.
  4. Open the cloned directory in VSCode.
  5. Create a .env file in the .devcontainer directory and add WEB_IMAGE_NAME=onezoom/oztree-with-iucn, changing the value to whatever image name you choose in step 1.
  6. Open the command palette and choose "Dev Containers: Reopen in Container". This may take several minutes to run.
  7. Your repository is mounted at /opt/web2py/applications/OZtree and the original production docker container application is mounted at cp /opt/web2py/applications/OZtree_original. In order to sync your repository with the production database state, open an integrated terminal and run the following: cp /opt/web2py/applications/OZtree_original/private/appconfig.ini /opt/web2py/applications/OZtree/private/ && cp /opt/web2py/applications/OZtree_original/databases/*.table /opt/web2py/applications/OZtree/databases/
  8. Run npm ci && grunt dev. You will need to rerun grunt dev any time you make code changes.
  9. Visit http://localhost:8080 and the website should load! You can also run your own server from the dev container by running web2py.py directly.
  10. (Optional) Once tables are created, and everything is working, you can set migrate = 0 in private/appconfig.ini. This will mean that web2py will not make any changes to table structures in the DB, and also that changes to appconfig.ini will require a web2py restart.
  11. (Optional) Create a manager account in the auth table, e.g. so you can view docs.
  12. (Optional) MySQL is available on port 3307 if you wish to debug using local tools outside the container.

Installing locally

There are two ways in which you can install OneZoom on a personal computer: full installation and partial installation.

  • Partial installation does not create a standalone OneZoom site, but simply creates a local web file containing the javascript tree viewer. Instead of your tree viewer getting information from your own computer, it must do so by constantly requesting data from the OneZoom website (via the OneZoom APIs). This restricts your OneZoom viewer in various ways: you cannot make your own bespoke tree, you cannot change languages in the viewer, and you are dependent upon a permanent, fast internet connection. Also note that this installation method is also relatively untested, and there are unfixed problems with e.g. displaying lists of popular species. However, partial installation may be suitable for developers who simply want to re-program features of the tree viewer, such as colours, branch geometry, etc.

  • Full installation creates an entire duplicate of the OneZoom website, which is built using the web2py framework. This creates a fully self-contained local system (apart from the picture files, which can be downloaded separately). This is the most reliable installation method, but requires you to install and run extra software packages, in particular web2py and a MySQL server. Since this can be quite complicated, the majority of this readme contains instructions for full installation.

Requirements and packages

For any installation, OneZoom requires node (18+) & python (3.10).

Debian/Ubuntu

apt install nodejs npm
apt install python3 python3-dev python3-venv

FreeBSD

# NB: rust is required to build the python cryptography package
sudo pkg install lang/python310 node18 npm-node18 rust

In addition, for a full installation you also need MySQL:

Debian/Ubuntu

apt install lsb-release
wget https://dev.mysql.com/get/mysql-apt-config_0.8.29-1_all.deb
dpkg -i mysql-apt-config_0.8.29-1_all.deb
apt update && apt install mysql-server

Windows

On Windows we recommended downloading the MSI installer as it will make it easier to configure the new server during the installation. Once mysql is installed, you will need to set a root password, and create a database for web2py to use. See http://dev.mysql.com/doc/refman/5.7/en/default-privileges.html. The mysqld program is responsible for running the new database just created. When this program is running, you can connect to the database.

Installation

If performing a full installation, you need to create a database for OneZoom to use:

mysql -p
CREATE DATABASE OneZoom;
CREATE USER 'oz'@'localhost' IDENTIFIED BY 'passwd-you-should-change-this';
GRANT ALL PRIVILEGES ON OneZoom . * TO 'oz'@'localhost';

Firstly, you need to check out the web2py / OneZoom repositories, and run npm:

# NB: The path should match the eventual hostname for this installation
export WEB2PY_PATH="/srv/.../onezoom.myhostname.org"
mkdir -p ${WEB2PY_PATH}
chown deploy:staff ${WEB2PY_PATH}
git clone https://github.com/web2py/web2py ${WEB2PY_PATH} --branch v2.27.1
git clone https://github.com/OneZoom/OZtree.git ${WEB2PY_PATH}/applications/OZtree --branch production
cd ${WEB2PY_PATH}/applications/OZtree
npm ci

Next, cp private/appconfig.ini.example private/appconfig.ini and edit to match your needs, taking care to:

  • Use the same database credentials as configured earlier.

Once done, run ./node_modules/.bin/grunt dev for a development installation.

For production installation, see later.

Partial installation

If you'd like your installation to be a partial installation, run:

./node_modules/.bin/grunt partial-install

...and open static/minlife.html in a web browser. Note that this file needs to stay within the static directory to work at all. You may also need to allow your browser to allow local files to be loaded via AJAX (i.e. disabling some local cross-origin checks). Different browsers do this in different ways: for example in Chrome you can start up your browser with the --allow-file-access-from-files option, and in Safari, you can choose "Disable Local File Restrictions" from the "Developer" menu.

Note that the normal minlife.html file will use local versions of data files and the javascript treeviewer, but will get API information form the OneZoom website, and also use the OneZoom website as the source for the html page which embeds the viewer. For developers only, who may wish to create a minlife version not only using modified javascript in the treeviewer but also with bespoke html, you can run grunt partial-local-install. This is much more effort since it requires you to set up a full installation (as below) before creating the minlife scripts, but once created, the files in static will be enough for other users to view (and test) your modifications.

Database set-up / migation

For full installations, you need to setup your database.

To create required tables, use web2py migrate:

  • Edit private/appconfig.ini, setting migrate=1
  • ./web2py-run tests/unit/test_modules_embed.py, on startup this will create tables as necessary
  • Edit private/appconfig.ini, migrate=0

A database dump should be used to add species information:

# NB: OneZoom.dump.sql can be extracted from https://github.com/OneZoom/OZtree-docker
mysql -p
USE OneZoom
SOURCE /OneZoom.dump.sql

Finally, ensure indexes are created:

mysql -p
USE OneZoom
SOURCE ${WEB2PY_PATH}/applications/OZtree/OZprivate/ServerScripts/SQL/create_db_indexes.sql

Production installation

For a production installation of OneZoom, you also need nginx & supervisor:

Debian/Ubuntu

apt install nginx supervisor

FreeBSD

sudo pkg install nginx py39-supervisor lang/python310

Installation

Run grunt to configure onezoom for production use:

cd ${WEB2PY_PATH}/applications/OZtree
npm ci
./node_modules/.bin/grunt prod

Edit models/db.py, and set is_testing = False.

Then run the install scripts to set up nginx & supervisord:

sudo ./install-nginx.sh
sudo ./install-supervisord.sh

If everything works, restart both.

Database explorer

(optional) We find it useful to have a GUI interface to connect to the database and run SQL scripts, this can be used instead of using MySQL command line (similar to Windows command line) that is installed by default with MySQL. On Mac OS X we use the (excellent) https://sequel-ace.com. On windows you could try http://www.mysql.com/products/workbench/ or https://www.quest.com/products/toad-for-mysql/ Under windows, SQL Workbench can also be used, even if your MySQL server is installed under WSL2.

installing SQL Workbench on Windows works great to connect to the Ubuntu MySQL instance.

Starting and shutting down web2py

On the OneZoom main site, web2py is run using a combination of nginx and uwsgi. This is complete overkill if you just want to run a local copy of OneZoom for testing purposes. You can simply run a temporary and basic web2py server using Python 3. The simplest is to open a command-line prompt in the root web2py folder, and run the following (assuming the command python3 is linked to something like Python 3.7)

./web2py-run

When web2py is run, it will print instructions telling how to shut down the web2py server. For example, on Windows you might use taskkill /f /pid XXXX, where XXXX is the process id.

Web2py folder structure

Standard folders

databases stores all the database structure.

controllers is where most of the bespoke web2py code that runs the site lives. The public pages are in controllers/default.py.

models stores the python back end server code.

static stores all static files including images, css, and compiled js. Files which are output by various server processes are stored in FinalOutputs. This includes very large numbers of thumbnail images (stored in FinalOutputs/img) and static data files such as the tree topology and the tree cut positions (stored in FinalOutputs/data). The OZTreeModule folder contains the compiled version of most of the core OneZoom code. static/OZLegacy contains most of the old trees.

views is where all the html is stored - it's OK to just use raw html in here if no server side functions are needed for that particular page.

OneZoom special folders

OZprivate stores external files that are not formally part of web2py, such as the tree viewer code itself, and scripts which we use for updating the tree and our own database tables. The most important are:

  1. data, which contains most of the data used to build the tree (e.g. EoL mappings, OpenTree components, Yan's specific tree-building code
  2. rawJS, which contains the uncompiled javascript that when compiled, creates the OneZoom viewer
  3. ServerScripts, which contains scripts that the server can run to compile a tree, grab images from EoL, percolate images throughout the tree, etc.

Filling the database

Creating auth users & groups

Web2py uses an auth_ based system, which has tables for users, roles, and a mapping table assigning roles to users. This can be edited through the web interface: assuming you are running a temporary version of web2py on localhost, you can access the admin pages through http://127.0.0.1:8000/admin/default/design/OZtree, which will require you to enter the temporary administrator password ('pass', above) that you used in the web2py startup command. The database tables can be seen at the url http://127.0.0.1:8000/OZtree/appadmin. You need to click to edit the db.auth_user table, from where you can click to add a "New Record", and submit a first name, last name, email, username, and password. You then need to go back to the appadmin page and create a "manager" role by adding a New Record to db.auth_group table (you can type anything in the description box). Finally, you need to create a New Record in the db.auth_membership table, and assign the "manager" group ID to your user ID in the resulting page.

Other tables

The main bulk of the data returned from the API is stored in the rest of the tables in the database, as detailed below. To get the API and the rest of the website working, you will have to obtain a database dump of the OneZoom tables. You can either do this by emailing [email protected], or getting it from a Docker setup of OZTree. If you are loading new data on top of old, it is a good idea to truncate all the non-auth tables before loading data.

You can use the following steps to fill up the tables based on a Docker setup. Start by following the Docker instructions, including the 'Saving the image' section. Then, run these commands one by one:

# start by stopping/deleting any OZTree container instance that may still be running (your container name may be different):
docker stop oztree

# Create a folder on your local machine to hold the dump
mkdir ~/dbdump

# Run a new OZTree Docker container instance, mounting your local folder
docker run -d -p 8080:80 --name oztree --mount type=bind,source="$(pwd)"/dbdump,target=/dbdump onezoom/oztree-complete-with-iucn

# Start a shell in the container
docker exec -it oztree /bin/bash

# Dump the container's database into your mounted local folder. This is fairly fast. The resulting file is ~1GB.
mysqldump OneZoom > /dbdump/ozdb.sql

# Exit the running OZTree container. We're done with it now, so feel free to delete it.
exit

# Now import the dump into your local OneZoom database (you may need to pass -u & -p based on your MySql configuration)
# WARNING: this is an extremely long step that can take over an hour with no indication of progress!
sudo mysql OneZoom < ~/dbdump/ozdb.sql

# You're done, and your local database should be fully populated. Feel free to delete the dump file /dbdump/ozdb.sql

Note that mySQL stupidly has a restricted version of the unicode character set, so fields that could contain e.g. chinese characters need to be set to utf8mb4 (which is not the default). These are the vernacular field in the vernacular_by_ott and vernacular_by_name tables, the rights field in the images_by_ott and images_by_name tables, and the following fields in the reservations table: e_mail, twitter_name, user_sponsor_name, user_donor_name user_more_info, user_message_OZ, verified_sponsor_name, verified_donor_name verified_more_info. When we send you the tables, they should contain create syntax which makes sure the tables are correctly defined, but it may be worth checking too.

Optimising tables (IMPORTANT)

To get any decent performance out of your OneZoom instance, you will need to create indexes on the resulting tables. The commands for doing this are listed in OZtree/OZprivate/ServerScripts/SQL/create_db_indexes.sql, from where they can be copied and pasted into a mysql client.

The commands to create indices also include commands to convert some of the columns to 4-byte unicode if necessary (to incorporate e.g. full Japanese/Chinese common names), and to drop the indexes if they already exist. Some of these commands may cause SQL errors (e.g. "Can't DROP XXX") if you have not previously created any indices. These errors can be safely ignored. If you are using mysql workbench you may want to untick the option under Query to "Stop Script Execution on Errors", so that the index creation continues after each error.

Table information, for reference

OneZoom data list - this is data that's not stored anywhere else outside OneZoom and so should be treated with greater care

  1. Auth_* (see above: ours but easy to recreate)
  2. Banned is ours and is important but could be recreated
  3. eol_inspected is ours but is not important at all so could be lost and we wouldn't care
  4. eol_updated is ours but is not critical
  5. images_by_name and images_by_ott - entries put in by us where src=1 are ours and are semi critical because they include things like special images of sponsors etc. also includes hacked ratings and hacked pictures in general.
  6. IUCN - not ours at all
  7. leaves_in_unsponsored_tree - now not used any more can be deleted
  8. Ordered leaves and ordered nodes - can be recreated, but include derived products like popularity, matched IDs and Yan's curation of the tree. This can be regenerated any time provided our codebase and algorithms are fine
  9. PoWo - Kew list of things (for later in Kew tree)
  10. prices is ours semi critical we can recreate but includes our subjective choices.
  11. Reservations table THE MOST critical
  12. vernacular_by_name and vernacular_by_ott is the same as images - so src=1 means it's ours as before semi critical
  13. visit_count medium level of criticality it's our visit information, but we don't know if it's running. We may later split this up but tree. at the moment it's not really functioning as we want it.

Notes

  • there is a question mark over tours information and associated things
  • there are many critical source files in OZ_private, including tree sources.

Running tests

Server unit tests

NB: The server tests are not sandboxed, so have the potential to delete database data. You are advided to run this on a personal instance where data loss does not matter.

The server unit tests have no additional dependencies. To run, do:

grunt test-server

To run individual tests, do:

grunt exec:test_server:test_modules_username.py

Client unit tests

The client unit tests have no additional dependencies. To run, do:

grunt test-client

Server Selenium-based functional tests

Make sure required python modules are installed with:

pip3 install -r tests/requirements.txt

You also need chrome/chromium driver installed with, e.g.:

apt install chromium-driver

You can then run the tests with:

grunt test-server-functional

Debugging

If you wish to use your editor's debugger to debug the JavaScript code, you will need to compile source maps. Run the following:

  1. Run grunt dev to perform the initial dev compilation.
  2. Run npm run compile_js_dev:watch to compile source maps and automatically recompile if files are changed. Note: this command will continue to run until it is killed.

Documentation

Documentation is partially compiled from the source code using Grunt, and lives in OZprivate/rawJS/OZTreeModule/docs. Once compiled, it can be viewed online using your web2py server. For example, if you are running web2py on http://127.0.0.1:8000, you should be able to visit http://127.0.0.1:8000/OZtree/dev/DOCS, or (if you have manager access to the OneZoom site) at http://onezoom.org/dev/DOCS.

Keeping OneZoom updated

If you wish to make sure your OneZoom data is up-to-date, there are a few steps you can take:

  1. Make sure the "representative species" for each node (the 4x2 pictures in the middle of each internal node) are up-to-date. To do this, run

    OZprivate/ServerScripts/Utilities/picProcess.py
    

    Note that these representative pictures can be customized too (see below)

  2. Update IUCN statuses, from the IUCN API. This can be done by

    OZprivate/ServerScripts/Utilities/IUCNquery.py
    
  3. Keep a running script that mines data from the Encyclopedia of Life (EoL). This will ensure that new images on EoL are eventually downloaded to OneZoom, but it does mean that your server will continuously be sending online requests to EoL. You wll need to obtain an EoL API key (http://eol.org/info/api_overview) and add it into your appconfig.ini file. Then you can run the script as follows:

    OZprivate/ServerScripts/Utilities/EoLQueryPicsNames.py
    
  4. Recompile your own tree and database tables. Instructions for creating your own tree are in OZprivate/ServerScripts/TreeBuild/README.markdown.

Customising OneZoom

A few suggestions about ways to customize OneZoom

Easy customization possibilities

  • Change the colour schemes: the code in rawJS/OZTreeModule/src/themes gives examples of how to create new colour schemes for branches, leaves, etc of the tree. They can be gathered together into themes (including different leaf styles, default fractal views etc) by adding to the code in rawJS/OZTreeModule/src/tree_settings.js.

Harder customization possibilities

  • Customizing pictures: by running alternative versions of picProcess.py, you can choose different pictures to represent taxonomic groups. This is left as an exercise to the customiser.

  • Alternative UI layer: the current OneZoom viewer uses the UIkit framework to layer a user interface on top of the viewing canvas. The UI can send commands to the viewing canvas, and the canvas is instatiated with UI callbacks, so it is quite possible to write alternative user interfaces (e.g. using different UI toolkits)

  • Alternative projections: the code in rawJS/OZTreeModule/src/projection can be supplemented with alternative "projections" of the tree, such as treemaps, other fractal layouts, etc.

oztree's People

Contributors

davidebbo avatar dependabot[bot] avatar hyanwong avatar jrosindell avatar kz12 avatar lentinj avatar wolfmanstout avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

oztree's Issues

enhanced polytomy view and add view to menu

I want to tweak the polytomy view, especially to solve performance issues and appearance where there are very large polytomies, also the polytomy view should be added to the main menu if we want to offer it as an option. The current view looks like:
screen shot 2018-01-12 at 17 04 50

Enable independent leaf draw code use for embedded sponsor_leaf page

The code currently in 2 files in rawJS/OZTree/src is a duplicate of leaf drawing code in the main OZ codebase, used to draw leaves e.g. on the sponsor page.

We should modify the main codebase so that we can call these functions on an independent canvas using the main codebase, not rely on separate files.

This is needed because if we embed the sponsor_leaf.html code within a popup (rather than using an iframe), then we need access to that js code, as quite rightly we can't run js from an embedded page.

Sponsorship shared with e.g. conservation organisations

We should have the ability to add (to the default OZ tree) a set of nodes which lead to e.g. 1/2 the money going to another organization whose goals align with ours. For instance, half the sponsorship money on any of the 8 slow lorises could go to http://www.nocturama.org/en/welcome-little-fireface-project/ , or as Jonathan suggested, we could have a 1 week "special offer" where any sponsored bird gives 50% to the RSPB.

We could also run a competition, open to e.g. conservation charities, for access to this scheme.

This should actually be quite easy. Yan thinks we should save all this info in the partners table, which would require a few more fields, in particular, a list of OTT ids for which this partnership is valid (could also be a node OTT, in which case we look up the descendant leaves in ordered_nodes). There would also need to be a field which flagged up if this was like LinnSoc (only on a single tree, with different URL), or like slow lorises (valid only on the default OZ tree).

Create a "terms.load" file

Similarly to about.load / about.html, and data_sources.load/data_sources.html, we should create a terms.load file which is loaded into terms.html.

superflous files

There are some static html files in static/OZSite/ (iframe_load.html, About_this_tree.html, & Sources.html). I think we can probably delete these.

Should we use the existing compass or another icon for "current location"

I'm wondering if something like img_547364 is more useful (or with a rounded back end like https://www.shutterstock.com/image-vector/vector-current-location-map-marker-arrow-279362993). Alternatives might be a pointer with no circle, a hand, or perhaps a location item in front of a globe.

A google image search for current location icon is possibly useful, and https://www.shutterstock.com/image-vector/compass-icons-on-white-background-vector-145836710 has a few possibilities.

Provide a script to download photos

For museums etc we need a way to populate the pics dir so that the OneZoom instance is completely stand-alone, and will work without an internet connection (NB: this will still not allow the display of external pages such as wikipedia, though).

We cannot do this over ssh/rsync. Instead, we probably want a python script that looks up the image IDs from the database table and downloads them over http if they are missing from the pics directory (or if their updated time in the eol_updated table is more recent than the created time on an existing picture)

current location option UI design

A few issues with this...

1.) space is left on the right for a scroll bar even when one is not needed
2.) when fully zoomed out no data is shown (probably instead it should show just the root still) or some message saying when you've zoomed in this will show where you are.
3.) when I explore the tree on touch it does not dismiss the location box as it should, in fact it dismisses only on mouse up (not even on mouse down).

Search seems to give unexpected results

Behaviour observed in Oxford botanic gardens on the touchscreen: often many non-hit search results are returned. I suspect this might be because of firing off the search too easily, so that if you type "collared", a search is requested for 'col' before the rest of the word is typed. Perhaps the search delay in the UI is too long, or is being ignored by the touchscreen.

Is it confusing to not have some tabs some of the time?

E.g. if there is no wikipedia page for a species, should we put up a wikipedia tab which simply says "sorry, there is no wikipedia page for this taxon". Or is it better as we have it, where we don't show the tab if we have no data?

This was picked up as an oddity by one user, but others might find it weirder to have a "no information available" page.

Also return image ids when calling onezoom.utils.process_taxon_list

At the moment the popular species tab is populated using a onezoom JS-API call named onezoom.utils.process_taxon_list, passing in a list of OTTs and a callback function - the callback is processed for each OTT in turn, with common name, node id etc returned. This API function (in src/api/process_taxon_list.js) needs to be adjusted so that images are also returned to the callback function.

Museum display user accessibility

The museum display needs to feel easy to use for an unexperienced user. One way is by implementing #18, but we also need to take account of:

1.) The current UI relies on mouseover to show what all the small icons do. Mouseover is not useful on a touchscreen (no mouse). All icons should be large and have an obvious function - for example, rather than mouseover hints, we could include as part of them enough text to make the function clear. An example of this is the compass which shows where you are but at the top level of the tree only shows all life and so the point of it is not clear.

2.) It needs to be obvious to the user from the start what the display is showing (tree of life etc etc.) and what they can do with it (search, common ancestor, back to start, etc etc)

Touchscreen issues #1: Search radically slows down UI

Typing a general search such as "dodo" radically slows down the whole UI on James' touchscreen. We should check indexes are properly set on the DB, but I don't think this is the root of the problems as there are problems even when the server is running on another computer. It may be to do with returning too many results into the search box (possibly linked to #6)

Occasionally we create urls to impossible places

E.g. life.html/@mantodea=656293?vis=spiral#x3335951899,y2670646326,w9512788.9481

Which makes the canvas look blank, and requires a lot of zooming out. From URLs like this we should probably jump to a zoom level that at least shows something on the screen.

Make embedded own pages pinch-zoomable (e.g. with PanZoom)

E.g. it might be possible to create our own wikipedia frames, which encapsulate the wikipedia page but also turn off pinch-to-zoom. That way we don't need to inject e.g. the wikipedia css into the main OneZoom page, which has always struck me as a bit hairy. URLs could be of the form www.onezoom.org/iframe/wiki.html?Qid=xxx&lang=xxx (DONE)

We could possibly do the same for EoL / IUCN / etc pages (perhaps not for the museum display, but simply displaying the page with links and a BASE tag set), which will get around https://github.com/jrosindell/OneZoomComplete/issues/381. (This is also a potential solution to #21 and also to the issue of moving from the sponsor_node page to the sponsor_leaf page)

code alternative branch style for bacterial branches

As it is unclear whether bacterial relationships are ever really "tree-like" in the first place (and even if so, the tree will only represent a small fraction of the "core genes" in the genome). Additionally, the rooting of the bacterial tree is very uncertain. So something that marks out the bacterial branch as only partially representing the relationships (e.g. a dotted or faded line) would be good.

Additionally, we might not want the standard view (especially the polytomy view) to look as if it is rooted.

In settings the tree changing switch goes to non-existent pages

It correctly tries to switch to the alternative urls, but the view for each (e.g. default/linnean.html) does not exist any more. These views need reinstating.

Also, we should possibly create the list dynamically, from a list of views, so this doesn't happen again.

Simple online/offline switch for museum display

For museum displays that do not have internet connections, we should have a simple config parameter that switches off e.g. the wikipedia popup tab (we could potentially leave the sponsorship tab, which could show simply a url and QR code, but not an "email me" box), and checks that the installation has a local copy of all the thumbnails available.

mobile device touch issues on search

lots of the functions require two taps because the first tap triggers mouse over text to appear only and gives user a short window of time to tap again and perform the action. I think the action should be performed on the first tap

Copyright symbol on nodes is not always filled out with text

We try to get the licence etc information from data_repo on line 448 of midnode.js (data_repo.metadata.leaf_meta[code][credit]), but this is often not filled out yet, because of how collect_nodes_need_image_details() works (function in api/image_details.js).

Ideally we either want to get credit information for all images within shown nodes (perhaps a bit intensive), or as we zoom in to a node, and the 4x2 image array appears, we want to add the internal images to collect_nodes_need_image_details()

I think this is possibly a question for @kz12, what do you think, @jrosindell ?

scrolling in location function with mobile

when you get to the end of the scroll up and down it starts to affect the underlying tree page and tries to scroll that. I suspect this is annoying and difficult to fix but should be recorded in any case.

Control buttons disappear on tab popup

When a modal popup is opened, the control button bar on the bottom left disappears. I don't mind this behaviour, but I'm worried that I don't understand why it happens, although I suspect it is something to do with overflow: hidden being set on the body element in the css file.

Links *within* a modal close the modal

E.g. if in the museum display we inject a wikipedia page with footnotes (look e.g. at the node for "animals"), then when we click on a footnote, instead of being taken down the page, the modal shuts

Would like to understand & modify get_my_location() to return richness of current node

I don't understand how get_my_location() in controller_loc.js works. It need modifying to give the richness of the current location (even if that location is not named).

Question: why can't we use something like get_largest_visible_node() from record.js to get the current location, then move up the parent chain to the root, rather than the complex recursive call to get_location3() that is currently being used.

Check museum display view is reasonably "sandboxed"

Before marketing the museum display, we need to make sure that it is reasonably "sandboxed", in that there is no way to navigate to a page or popup that has an external link in it. Perhaps this could be done in an automated manner, using some sort of web crawler? This includes some of the internal OneZoom website pages.

At the moment this is done by using a get request with nolinks=1 set which
(a) redefines the A handler in internal web2py pages, where appropriate (e.g. in about.load, sponsor_node_price.load, etc.)
(b) flags the wikipedia-loading code (which gets wikipedia pages using their REST API) to remove tags that link out to external websites, but keeping internal links within a page (see function sanitise_links() in treeLayout.html: these include BASE, A, and tags with href=xxx, such as AREA - question: are any more needed?)
(c) turns off the ability to right click for context menus, so that we can't e.g. visit the source of an image by right clicking.
(d) Others??? List here.

Allow a standalone JS viewer (without requiring Web2py)

For people who want to develop the JS code, we should really not require them to run an entire web2py server. There should be a way to call the JS code from a static web page, and get nearly everything else, API calls, etc, (although perhaps not the completetree etc. files?) from our server. This should mostly be easy, as we can specify which URLs to use for the API etc in the treeLayout page.

In fact, I think the main issue here is internationalisation, because we load up the UI from a served-up web page (viewer_UI.load) which is translated into different languages. However, we could simply ask the downloader to pick a particular language, and save a copy of viewer_UI.load in that language.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.