Joints by topology

[obucklin]

Added ApplyJointsByTopology GH Component
shortened the (COMPAS_Timber) prefix on GH component labels to CT_
bug fixes to Fabrication package
added reference surface from beam face function to BTLx, whould help with new joint implementation

What type of change is this?

• Bug fix in a backwards-compatible manner.
• [x ] New feature in a backwards-compatible manner.
• Breaking change: bug fix or new feature that involve incompatible API changes.
• Other (e.g. doc update, configuration, etc)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I added a line to the CHANGELOG.md file in the Unreleased section under the most fitting heading (e.g. Added, Changed, Removed).
• [x ] I ran all tests on my computer and it's all green (i.e. invoke test).
• [x ] I ran lint on my computer and there are no errors (i.e. invoke lint).
• I added new functions/classes and made them available on a second-level import, e.g. compas_timber.datastructures.Beam.
• I have added tests that prove my fix is effective or that my feature works.
• [x ] I have added necessary documentation (if appropriate)

[gonzalocasas]

I started using Projectname: in core and fab components, maybe change to CT: ?

[gonzalocasas]

does that work? that's a scary import :P

[chenkasirer]

Just to summarize what we discussed earlier, I think a better approach would be to add this capability as a new JointRule as we have this system in place. At least two reasons I see:

1. Currently CT_ApplyJointsByTopology is essentially a specialized copy of the auto-joint component, so does a lot of what the latter does (find intersecting beams, detect topology), if we were to use them together these things would be executing twice, and these can be pretty heavy when there's a lot of beams.
2. If we use the rule system we could later extend the autojoint component to allow some rules to override others (e.g. by order).

The new class could looks like:

class TopologyRule(JointRule):
    def __init__(self, topology, joint_type):
        ...

The topo-joint component can create an instance of TopologyRule for each topology, mapping it to the selected joint type.

To implement comply we could (somewhat not elegantly..) pass the detected topology as one of its arguments and return True if it matches the rule.

def comply(self, beams, detected_topo):
    return self.topology == detected_topo

[obucklin]

ok I ended up doing a second PR that reflects these comments. can i cancel this PR?