Area highlighting commands

[lentinj]

initmark doesn't allow you to, e.g. highlight all insects that aren't ants.

Want to be able to provide a sequence of OTTs and highlight on/off command. Unlike OTOP we want multiple strings for each highlight, as they will work independently of each other.

A single highlight command works both up and down, up like common ancestor highlighting, down flowering out like OTOP. For a given node, one finds out it's colouring by heading upwards until a node is found that has a highlight instruction (on/off).

If one wanted to highlight insects without highlighting above it, you could turn off highlighting on the node immediately above

Also want syntax to describe a common-ancestor for a target that doesn't have an OTT. Say (ott1).(ott2). This could then be used in multiple locations e.g. @12345.4556. This then allows you to target a node above the insect roots and turn off highlighting, so highlighting only starts at insects, a la OTOP: https://github.com/OneZoom/OZtree/issues/548

[jrosindell]

The common ancestor syntax could be used equally in main OneZoom URL and in definition of tour stop locations.

A well designed bit of content would choose OTT pairs that are close in the tree to make the calculations easier

In terms of practicalities, when loading a tree with such a set of instructions it would have to be developed to all the 'control points' of the tree where highlight instructions change.

[lentinj]

We're a bit worried about nodes being released and their highlighting being lost. The node release logic should pay attention to whether there's any marked_areas, if there are then it shouldn't destruct.

[jrosindell]

Another comment is that probably highlights, just like tour colour scheme, should be something that gets changed by a tour stop rather than needing to be given by a stop. So, a stop might highlight a part of the tree once and then future stops leave that highlighted until another stop says to switch that highlight off.

Other thoughts are that probably we don't want highlight colours to be constrained to the default pastel shades they are now - they should be able to be set to anything by the tour e.g. the 'colours of blood' tour that talks about chemistry for carrying oxygen in different circulatory systems.

We'll need to think about the highlight experience of a single node - OK it can be a flag from a distance but if you're really zoomed in close then what - a glowing background or something perhaps - not sure but to be discussed with graphic design later.

[jrosindell]

So, for now I think we won't make decisions on the graphical representation of highlighted sets of nodes but we could make a start on the technical side of the highlighting language that can be used in URL and in tour stops. Specifically this seems to be a list of nodes of the tree each of which as an instruction associated with it. The nodes might be OTT ids or they might be a pair of OTTids. the instructions are highlight up on/off, highlight down on/off, highlight individual on/off. The ordering of these commands should be set up by the instructions for the highlight so they will just go step by step in the order giving expanding the treat include the instruction nodes each time. We're assuming a small amount of instruction nodes. The tree is then left only with highlights that ripple down as new nodes are created because everything above a developed node is already developed too.

[jrosindell]

I guess multiple colours of parallel highlight would just need to be a set of independent highlighting instructions.

It would make sense to review the common ancestor marking code as part of this so that the same commands are used for that feature as for other highlighting tasks.

[lentinj]

So something like:-

(A|D| )(ott_spec)(X|O)(colour_spec)

Where the parts are:

• All ancestors of ott_spec / All descendents ott_spec / ott_spec only
• An OTT, or (ott).(ott) for common ancestor
• X for highlight on / O for highlight off
• Either an rrggbb triplet, or a single digit for one of the predefined colours.

So the current common ancestor highlighting might be represented as: A1011482X1,A6794X2.

This relies on X or O not appearing in ott_spec, but seems reasonably unlikely that we'd want to do that.

[lentinj]

Because we want to "fan out" markings, we can't develop & mark everything as currently, since we'll easily try and develop the world.

Instead we need to have a calc_marked_areas method called when pre_calc & calc_horizon are called, that iterates through the developed nodes and reconfigures marked areas accordingly.

Ideally we first pick apart the various places that do pre_calc & calc_horizon, wrapping them up into something common.

[lentinj]

https://github.com/OneZoom/OZtree/pull/644 does all of the groundwork for this, so we can mark nodes as they are developed, next we need to add "fan out" marks to this, so:

• If turned on for a node, all children get the mark
• If turned off for a node, no children get the mark
• Otherwise, inherit mark status from parent.

Other to-do items:

• [x] Parser to take instruction string into a half-way state with OZids instead of pinpoints
• [x] config.marked_area_color_map should live in tree-state
• [x] initmark should be replaced with query string options that are constructed back and forth from tree-state (so any marks are reflected in the URL

[lentinj]

@jrosindell The scheme above assumes one colour, like OTOP. That's not the case here, we can have any number of markings enabled at once. Whilst we could assume that we only have one fan-out-style mark and override with new colours, that doesn't sound like your style. Instead, I'm thinking that we have:

• fanmark=[colour-spec]@12345@456@789 Where @456 & @789 are points that this marking is turned off
• pathmark=[colour-spec]@12345 Marking the path from a root to a node (i.e. the existing common-ancestor markings)

...the downside here is that if you want to transition from one colour to another then you have to have mention the crossover point twice e.g. fanmark=blue@12345@456&fanmark=pink@456.

[lentinj]

Right, I think this largely works now. There's a issue-544-area-highlighting-round2 that, along with a lot of tidy-up odds and ends, adds fan/path highlights. Here's the docs on how you put one together:

https://github.com/OneZoom/OZtree/blob/8ad9d85c9ca78a52d9c45cde210d876b0f0dae7d/OZprivate/rawJS/OZTreeModule/src/projection/highlight/highlight.js#L4-L12

The URL ?highlight=path:@tetrapoda@aves&highlight=fan:@aves@GALLOANSERAE will:

• Draw a line from Tetrapods to bids
• Draw a fan for all birds, apart from fowl