Point matches should contain the context that they were calculated in

[fcollman]

The point match database should contain an explicit representation of the context that they were generated in. This relates to the "local" transforms issue, in that if we imagine that depending on the problem (TEM, SEM, LM, etc) that users will want to calculate point matches, and therefore run solvers from different initial conditions, than there needs to be a guaranteed way to map point matches to their locations. For example, it would seem that you should be able to use the coordinate mapping service to map point matches from the "local" context they were generated in to the "global" coordinate of some stack, however, given that now sometimes point matches are generated where "local" doesn't actually mean 0 transformations on the data, but rather something a bit more specific there is no way to do this in a guaranteed way. Eric Trautman and I had a long talk about this in Berlin, and his thought that came out of that converation was to add this contextual information to the point match database, so that it can be tracked, and therefore you would use the following mapping, to go from the context point matches were generated in to any particular next context... start_context>local>end_context. Or alternatively maybe we should extend the coordinate mapping service to map between contexts directly... but that's a separate issue.