TimeSpanMap contains alternating Transition and Span entries.
Span entries can be inserted into the map almost randomly, despite they are often built either chronologically or reverse chronologically. Span entries are inserted by calling addValidBefore, addValidBetween, or addValidAfter, with some dates that will correspond to the transition with the previous or next span.
As of 12.X, these dates are fixed. The map can be populated progressively but once chosen a transition date cannot be changed. In some cases, it would be useful to change the transition dates after the fact. One example is when the transition date is only approximately guessed first and is refined later on during computation.
I would propose to add a resetDate method to the Transition class in order to allow moving it.
Let’s take an example, suppose I have a TimeSpanMap with the following spans and transitions: spanA / 00:00 / spanB / 00:10 / spanC / 00:20 / spanD / 00:30 / spanE. Then refining computation it occurs that the transition between spanC and span D that was initially guessed to occur at 00:20 really happens at 00:20:10. Changing the transition date here is straightforward and does not wreak havoc ; it simply implies that after the update, spanC will still be active at 00:20:05, whereas before the update it would have been spanD that would have been considered active.
Now lets consider another change. Starting from the same map, what should we do if instead of updating the transition from 00:20 to 00:20:10 we want to update it to 00:35? It would then go past the next transition. There are two approaches here. The first approach would be to forbid this and trigger and exception if we see a collision with previous/next transition while moving a transition. The second approach would be to consider users know what they do and if they override a transition, then they may completely wipe out a span (here it would mean deleting spanD and considering that after the update spanC ranges from 00:10 to 00:35 and is followed by spanE). It is of course also possible to set up an API allowing both approaches, which would in fact be in the same spirit as the eraseEarlier boolean in addValidBefore and the eraseLater boolean in addValidAfter. If a collision occurs, then if the erase boolean is true, spans are just deleted and next spans reconnected according to the new transition date, whereas if the erase boolean is false an exception would be triggered.
Of course, moving a transition to infinity should be supported (at least if the erase boolean is true).
My current idea is to allow both approaches and set up the API with such a boolean.
What do Orekit users and developers think about this?