multiple differnet LCS instances on CSM edges

[CagtayFabry]

one thing that is still complicated is having an 'analytical' as well as a 'measured' LCS representation for the same transformation in one CSM instance.

possible workarounds with our current implementation:

• In the IIW example we 'solved' this by essentially having a branching CSM, where one edge was the predefined (planned) movement and another edge was the recorded movement. In this case both edges had (to have) different names.
• Another way would be to create two identical CSM instances (like CSM_planned, CSM_measured where all edges would have the same name between the two but the data would differ. However this would still require to manage multiple instances and could lead to a lot of redundant/doubled info and data.

One idea to offer a solution would be to allow multiple different LCS instances as attributes on a single CSM edge. For now, let's say we allow one instance that can (in some tbd way) be labelled 'planned' and one other with label 'measured'. An edge is valid if it has either one of the labelled instances or both.
Then we would have a switch that let's the user choose which of the transformations to apply.

This would allow some other cool features:

• see if a given route along the graph is covered with only planned/measured data
• interpolate and compare chained transformations either with measured or with analytical values etc.
• probably others

Too keep it simple(r) it would probably be easiest to start by only allowing the edge to be defined in one direction (there are probably workarounds if measured and planned values represent each others inverse)

what do you think?

[vhirtham]

I think this will certainly be a useful feature, but we need to be clear that this will make an already complex class even more complex. Also, the schema would need an adjustment that adds additional complexity.

A simple approach would be to turn the transformation attribute at the edges from a LocalCoordinateSystem instance into a dictionary. All methods that need it will get an additional label parameter that defaults to "default". So in case we never provide labels, every transformation is stored in the dictionary with "default" as its key. Now if I want to do some transformations, I can also provide a label. If that label is found in the edge dictionary, the corresponding LCS is used, if not I try to get the default one. If there also isn't a default transformation defined, I get an exception that specifies which edge is missing a transformation and shows me a list of defined labels at this edge. For example, we might have the labels "experiment" and "theoretical" but no "default". This means that I always have to provide a label when working with a CSM that has a transformation without "default". However, we can provide a state variable that tells the CSM to use a specific label as default when doing transformations.

The question here is, how we will include this into our schema. We can simply define some sort of "transformation collection" and use this at the edges, but I think that it would be nice if only an LCS is written and not always a collection if we only have a default LCS at an edge. So we have to analyze the dictionary first during serialization and return either a single LCS or the full dictionary. IIRC this isn't easily combinable with the graph serialization. This means that we would need to wrap the dictionary (or its functionality) into its own class and provide a schema for it or adjust the graph before serialization.

• probably others

Another possible use case here would be to store multiple identical experiments in the same CSM. Should be nice if you want to compare multiple experiments against each other 😉