Reconsider surface/subarea approach in location tree

[gracemyz]

See location spreadsheet and discussion in #151.

Currently the location tree uses a set of default lists for surfaces/subareas. It's easy to specify exclusions from these default lists for each location, but harder/less efficient to specify additions. We should reconsider how we assign surface/subarea lists to each location.

[gracemyz]

Some preliminary thoughts and questions --

Handling exceptions from default lists In #151 @kvesik suggested two options:

(a) allow both exceptional exclusions and exceptional additions, or (b) just have a couple of default lists plus some exceptional lists that contain precisely the items required by those locations (as opposed to having to frame exceptions in terms of exclusions).

Option (a) is the simpler, less disruptive (easier backwards compatibility) approach. However, currently option (a) seems to be overkill as there are only two locations with exceptional additions (tongue and heel of hand). If we go with option (b), we can cover all the existing body options using a set of 9 surface lists and 8 subarea/bone joint lists. They are:

Surface options:

• No surfaces allowed
• Default non-hand list: Anterior, Posterior, Lateral, Medial, Top, Bottom
  • Tongue surface list: default minus posterior, lateral
  • Neck surface list: default minus lateral, medial, top, bottom
  • Non-hand list 1: default minus medial, top, bottom (used by 4)
  • Non-hand list 2: default minus medial, bottom (used 3)
  • Non-hand list 3: default minus top, bottom (used by 19)
• Default hand list: back, friction, radial, ulnar
  • Hand list 1: default minus radial, ulnar (used by 4)

Subarea / bone/joint options:

• No subareas/ bone/joints allowed
• Default non-hand subarea list: contra half, upper half, whole, centre, lower half, ipsi half
  • Tongue subarea list: default minus upper, lower, plus dorsum, blade, tip
  • Non-hand subarea list 1: default minus upper, lower (6)
  • Non-hand subarea list 2: default minus contra, ipsi (42)
• Default hand subarea list: finger side, wrist side, radial side, ulnar side, centre (3)
• Default bone/joint list: metacarpophalangeal joint, proximal bone, etc (6)
  • Bone/joint list 1: default minus IP joint and medial bone (2)

Streamlining the location tree tuple? The current tuple elements are:

#   name, editability, mutual exclusivity, checked/unchecked, hand/nonhand location,
#   allow surfaces?, relevant exceptions to list of surfaces,
#   allow subareas/bone-joints?, relevant exceptions to list of subareas/bone-joints

By including the "no surfaces allowed" and "no subareas/ bone/joints allowed" in the above options, we can remove the corresponding booleans from the tuples in the locn_options_body keys.

Editability is always off; there was a comment that maybe it can be removed. Also, checked/unchecked is always unchecked. So possibly tuples could be reduced to five elements: eg: ("Upper arm above biceps", rb, nh, nonhand_surfaces_3, nonhand_subareas_2) instead of ("Upper arm above biceps", fx, rb, u, nh, allow, (top, bottom), allow, (contra_half, ipsi_half))

Issues

• Backwards compatibility!
• At last week's meeting we said that eventually we would like users to edit their location options... what will this look like? Will they be able to create their location tree from scratch, or are they limited to turning off certain options etc?