[MPI_WP2]: 2. IsoMemo skin IsoMemo app: bibtext, duplicates, restructure

[jroachell15]

A. higher level of data fetching
For the Isomemo app, introduce a higher level of data fetching. Currently a script is used to map data from across different databases into a single table stored in our servers. This script is something that I can edit as databases are added/removed/modified. The script should be modified so that now I would have the option of creating different data maps. In terms of the IsoMemo skin interface there would be a selection option (above “Database selection”) to select a single data map. Once a map is selected the options for Categories and corresponding fields are automatically updated. In the new script I should be able to give a link to a pdf file describing the metadata of each map). Notice that this change implies also that the following will have to be updated:

• Connection to references
• Saving queries (rename “Save data selection” as “Save query)
• IsoMemo CRAN package (include access to metadata file)
• Data fetching via URL

Select categories or fields: buttons to select all/none

Have a new option in the IsoMemo skin to load pre-saved queries. These will be stored in GitHub. A text file with fixed named/location (in GitHub) but editable will be used to list these queries or a directory will be read. (8 hrs)

• potentially new tasks: save both sql codes and graphics merge the tables into the profiles, user can use the profiles and load them for the users
• Button to visualise metadata file (mentioned above) for each data map

---

B. Iso-data: Bibtext Citation

• options with the Rcrossref package/ Please check what we discussed:
• add a "bibtex" citation style column to the database, such that the app only needs to translate from one style into another style. The translation is only a string operation that should be much faster than loading references from DOI on the fly. -> Pandora-Iso-App-Data: Update for getting citations from CrossRef iso-data#3
• implement the UI and logic to change the reference style -> [MPI_2022]: Pandora Iso-app - data tables plus interactive map (Part 2) #14

---

C. Duplicate search within Pandora
(as above or in data merger task from previous task list): the user would be able to select fields of interest. In terms of matching options the user may select an exact match or if a string in one cell is contained within another. If the search should be case sensitive or not and if spaces should be considered or not. In terms of display, the user may select to add a new column where duplicates are flagged or only to display the first or last duplicate.
Duplicate search within IsoMemo: similar to above for the IsoMemo skin. Ok on the extra time but please rephrase this to reflect the missing/additional work required (16 hrs)

---

D. IsoMemo Pandora modify Mapping

User can set max char number- Currently the data rows in Pandora and IsoMemo skin can be quite big depending on text size. Have an option to make these smaller by having the user setting a max number of characters to be displayed.

• Pandora Skin: automatically set Longitude and Latitude fields after loading data #67

---

E. Restructure (split up) scripts for modeling tabs -> #34

Goals: clean code structure, less potential bugs, fix current bugs, e.g.

• Quirky behaviour of setting scale ranges #27
• Scale on speed map changes with degree of Zoom #30

Currently, all options for one tab of one model, e.g. "AverageR" are in one script, e.g. 03-modelResults2D.R. Since they are so many inputs now, some of the inputs do depend on and interact with each ohter. This leads to several rerenderings of the map if one input is changed. The app becomes very slow.

One way out of this is to isolate some of the inputs and move them into their own module preventing them to interact with inputs outside this module. Additionally, we can add an "Apply" button to trigger a new rendering of the map.
Recommendation to modularize (isolate) the following groups of inputs

• model inputs (currently most of them on the left side, an apply button already exists)
• map view inputs, e.g. map range/center/... (currently most of them in the middle, an apply button already exists)
• map content inputs, e.g. estimation type (currently most of them on the right side at the top, no button yet)
• map style inputs, e.g. "show scale/title/...", colou/shape/... of location marks (currently most of them on the right side at the bottom, no button yet)

If the user changes an input that belongs to one module, all dependencies inside this module will be set before the map is rendered again. This should significantly reduce the number of renderings. Maybe we can even remove newly added "Apply" Buttons later.

Another opportunity here is to reuse the newly created modules for e.g. map view and map style in the other modeling tabs like "TimeR". By this, we reduce the current "copy-paste" amount of the code, which reduces the risk for bugs, and the time to fix them.

Additionally, recommendation to use a newer syntax for the shiny modules that enables to add tests for the module server functions. To achieve a more stable app we add tests that check if we get expected output for some given input helping us a lot to prevent bugs when developing.
Use frames where needed and where possible. Approved! Frames are very important! -> #4

[arunge]

Duplicate. More recent ticket is: #69