Polygon stacks and time reference conversions

This paper describes how a time-based planning system, which supports resource constraints, may be extended such that a resource constraint interval does not have to refer to the start- or end-time of the underlying activity but to any linear combination thereof, such as the middle. This way, an activity with multiple resource constraints referring to different time intervals no longer has to be split into sub-activities, which may simplify the planning model and the algorithm. To be able to describe the necessary transformations, we introduce the concept of PolygonStacks and describe the operations which a typical planning engine requires to intersect the sets of consistent timeline entries of all constraints defined on an activity. We then introduce Sliders and Offsets, which allow specifying the constraint intervals in a more generic way as supported in current planning models. Based on this preparation, we can derive two lemmas, which provide the conversions required by Sliders and Offsets. We continue with several conversion examples and point out how to solve the issues which will occur during implementation. A short sketch of the complexity of our current implementation demonstrates that further work on performance should be considered, even though in practice we observe that the bottleneck of calculation remains within profile calculation rather than PolygonStack operations.


Introduction
Within the new planning library Plains, which is developed at the German Space Operations Center (GSOC), timelines are defined over the rational numbers to avoid introducing rounding issues due to a fix grid size or the use of IEEE floating point numbers. To make this possible, we are using the high-performance rational number implementation of the Spire algebra library, see [1]. One task of Plains is to determine the set of possible timeline entries of an activity from which the most suitable timeline entry may be chosen to be added to the timeline. In this way, Plains resembles other planning systems like most of those mentioned in [7]: APSI in [10], ASPEN in [6], EUROPA from [3], flexplan in [12,13], Mexar2 from [5], MUSE in [16], Pinta/Plato from [8,18] and SPIKE in [15, 22, ch.14]. As each timeline entry consists of a start-time and an end-time, timeline entries are in fact points in the two-dimensional plane with start-time mapped to the x-axis and duration = end-time − start-time mapped to the y-axis. Selecting a good data structure to represent such sets of timeline entries therefore, is very important.
In the first section of this paper, we present the Polygon-Stack, which is used in Plains to efficiently represent such sets of timeline entries. The PolygonStack supports efficient Boolean operations to allow combining the impacts of multiple constraints, it supports checking whether a timeline entry belongs to it and it supports selecting an element according to a proper criterion. A useful property of the PolygonStack is that it uses a compact representation with a canonical choice, i.e. there is a preferable way to represent a given set of timeline entries. This has advantages for determinism of the calculation as well as the ability to speed up complex constraint computations using the process of memoization.
Contrary to existing concepts for representing twodimensional polygons, a solution set for planning must be able to efficiently represent point solutions (an activity can be planned at exactly one point in time and duration), line solutions (e.g., an activity can be scheduled in a certain time range, but only with a fixed duration), area solutions (e.g., 1 3 an activity can be scheduled within a time range and a duration range) or any arbitrarily complex combination thereof.
Following the approach of [20, ch. 5.1] (see also [23]), we associate with every point in the solution space a positive integer value. Set membership can, thus, be easily expressed using a convention like 0 for true and ≥ 1 for false. Additionally, having an integer value at each point in the solution space gives us more options to combine solution sets and simplifies implementing Boolean operations. Another benefit of [20 ch. 5.1], compared to most other existing concepts of polygons, such as [4,11,14,24], is that we do not consider sorted sets of edges or vertices but just a non-sorted collection of rays. In contrast to [20, ch. 5.1], however, we need to distinguish between values within the inner part of a polygon and the values at its edges and vertices.
In the second section, we introduce the concept of Sliders and Offsets, which extends the capabilities of common planning modeling languages by allowing to formulate a constraint not only relative to the start-time or the end-time of a timeline entry but also relative to any time in between or even outside the timeline entry. Benefit of this new feature is that we may avoid splitting an activity into sub-activities in case multiple constraints refer to different time ranges relative to the activity. For example, a radar image acquisition may require power during its image observation phase; the on-board data compression mechanism, however, may block the on-board memory for twice the time of the image acquisition duration. With our new approach, both constraints may be defined on the same activity, even if the activity's duration is variable.
The downside of this new feature is that it creates additional work as for each constraint we need to convert the set of available timeline entries into the set of constraint interval start-times and end-times before we can apply the constraint restriction and thereafter convert back the result. The main part of this section, therefore, presents the generic formulas required to implement this conversion.
To clarify how these formulas may be applied, we present the implementation on PolygonStacks. Using selected examples for the conversion, we highlight what problems occur and how these can be solved. Thereafter, we present a worst case estimation for the complexity of the Polygon-Stack operations.

Polygon stacks
A timeline entry comprises a start-time and a duration, both of which shall take rational values. Therefore, one can identify a timeline entry with a rational point in the upper half plane ℍ , where the x-axis corresponds to the start-time and the y-axis to the duration of a timeline entry implying y ≥ 0 . To represent a set S of rational timeline entries, we use functions p ∶ ℍ ∩ ℚ × ℚ ⟶ ℕ 0 such that For our purpose, we can further restrict to the future of some base time X 0 ∈ ℚ yielding a domain D ⊂ ℍ ∩ ℚ × ℚ defined by We define functions p ∶ D ⟶ ℕ 0 , called PolygonStack, by finite sums where each ray r = Ray(x r , y r , s r , d At,r , d Above,r ) with defines a function r ∶ D ⟶ ℚ as follows: -If s r = ∞ , for any E = (x, y) ∈ D -If s r ∈ ℚ , for any E = (x, y) ∈ D The difference to boost's version of the PolygonStack (see [20, ch. 5.1]) is that we distinguish in between d At and d Above and that we support a ray with infinite slope. This way we can specify different values for vertices, edges and inner parts of two-dimensional polygons. Figure 1 shows a PolygonStack consisting of one ray with finite slope and one ray with infinite slope. Figure 2 shows a PolygonStack with the shape of a parallelogram.

Examples
x > x r and y r + s r (x − x r ) = y d Above,r x > x r and y r + s r (x − x r ) < y 0 otherwise 1 3

Operations
To evaluate this representation of a PolygonStack as a set of rays, we need to describe our use cases.

Planning horizon
To simplify some calculations, we will need PolygonStacks which have value 1 outside a bounded region. For this, we introduce the ambient value which is a constant C ∈ ℕ 0 added to all points, denoted by PolygonStack(C, {Rays}) , e.g., denotes the (non-bounded) polygon stack with corresponding function D ⟶ ℕ 0

Addition
As mentioned above, we need to consider multiple constraints, each of which restricts the set of consistent timeline entries. Such a restriction shall be represented by a PolygonStack with value greater than zero for all timeline entries which have a conflict with respect to this constraint. The PolygonStacks of all constraints, therefore, need to be added to specify all conflict free timeline entries as those with value 0. Adding two PolygonStacks requires summing up the ambient values, collecting the rays of the two PolygonStacks and merging rays of same x, y and slope to one ray with d At and d Above set to the sum of the respective values.

Evaluation
To evaluate a PolygonStack P on a timeline entry E = (x, y) , we need to consider all rays r = Ray(x r , y r , s r , d At,r , d Above,r ) of P with and add the respective d At or d Above . Geometrically, this corresponds to rays whose line lies at or below the timeline entry E.

Scan for value
When asking which timeline entries an activity may be given, we are not interested in the precise set of violated constraints but only in the region where timeline entries are conflict free. We, therefore, provide a function to simplify a PolygonStack such that it only takes values in {0, 1} . More precisely: given a PolygonStack P, we derive a PolygonStack Q with values For this task, we first need to determine all vertical scanlines x 1 < ⋯ < x n where either a ray starts or two rays cross. For all scan-lines x i , we then need to consider all rays with finite slope starting before x i and all rays with infinite slope starting at x i . For all open intervals (x i , x i+1 ) , we need to consider all rays with finite slope starting before x i . For each ray r = Ray(x r , y r , s r , _, _) let y(r, x) = x r + s r (x − x r ) denote the y value of the crossing point of r's line and the scan-line 0 if x > 0 and y ≥ 0 1 otherwise.  x. Traversing the rays ascending in y(r, x) and s r , one can derive the regions of values within the considered x-axis interval and build up the resulting PolygonStack Q. Note that multiple rays with equal y(r, x) and s r can be considered as effectively one ray by summing up their d At and d Above . Rays belonging to the same line in this way occur quite often, because most rays need to be canceled at a later x, e.g., for bounded PolygonStacks. When implementing this operation, one can significantly improve performance by considering the hints provided in [20, ch. 5.1].

Find value
From now on, we consider a PolygonStack P as synonymous with the set of points E with P(E) = 0 . Also, we emphasize again that our PolygonStacks are assumed to be finite. Since a PolygonStack represents a set of timeline entries satisfying some constraints, we would like to select a specific timeline entry from within that set by some configurable algorithm. We choose to define an ordering by specifying a directed line L 1 . Two points in the plane are compared by comparing their perpendicular projections on L 1 . The points which are mapped to the first point on L 1 w.r.t. its direction are considered best points. Since this step might result in a set of best points, we require a second directed line L 2 , which is not parallel to L 1 , yielding a unique result for any non-empty, bounded, closed PolygonStack, see Fig. 3.
In Fig. 3, L 1 corresponds to earliest end-time (i.e., smallest sum of start-time and duration) and L 2 corresponds to minimum duration. Note that the best point does not need to exist in case the PolygonStack has excluded edges or vertices or is unbounded. In this case, the algorithm must choose a value within the PolygonStack which is close to the best point of the closure of P. For the following lemma, we restrict, thus, to closed PolygonStacks.

Lemma 1 For closed PolygonStack s, the best point is either the starting point of a ray or the crossing point of two rays.
Proof For a point E which is neither part of a scan-line nor part of a ray's line, there exists a (2-dimensional) open neighborhood contained in the PolygonStack with the same value, which, when perpendicularly mapped to L 1 , is mapped to a (1-dimensional) open neighborhood of the image of E, which means that E is not best w.r.t. L 1 . For a point E, which is on a scan-line or on a ray's line and which is not a starting point of a ray or a crossing point of two rays, there exists an open neighborhood on the respective line with the same value. If this neighborhood is mapped to a neighborhood of the image of E, E is again not best w.r.t. L 1 . If the neighborhood of E is not mapped to a neighborhood of E, it must be mapped to the same value as E, which means that all points of the neighborhood of E are equally good w.r.t. L 1 . In this case, L 2 applies and this time the neighborhood must be mapped to a neighborhood of E, because L 2 is not parallel to L 1 , and again E is not a best point. ◻ We, therefore, can restrict the search for the best point to the finite set of starting points and crossing points.

Modeling example
To understand how this data structure shall be applied, we consider an example for which our planning library shall be suitable: an on-ground fire detecting satellite shall perform observations according to on-ground defined target regions. The corresponding on-board procedure might be defined as follows: 1. 10 s before image acquisition, the ACS (Attitude Control System) starts acquiring the required start position. 2. Thereafter, image acquisition is performed. The duration of the image acquisition depends on the target region and, therefore, is variable. 3. Thereafter, image analysis is performed to detect hot spots within the image. The duration of the image analysis is proportional to the duration of the image acquisition, since image analysis is proportional to the amount of data. In this example, we assume that image analysis and image acquisition have same duration.
In our model, we want to define an activity detectFire, which starts at image acquisition start and ends at image analysis end. For this activity, we want to formulate the following constraints: 1. during the interval start − 10sec, start + 1 2 duration the ACS system is allocated, i.e., no other ACS relevant activities may be performed 2. during the interval [start, end] the memory unit is allocated, i.e., no other memory relevant activities may be performed With our approach of Sliders and Offsets, we can directly formulate both constraints. In traditional planning systems (see [21]), we only have the possibility to define constraints of types 1. at start the condition must hold at the activity's starttime (possibly plus some predefined constant offset), 2. at end the condition must hold at the activity's end-time (possibly plus some predefined constant offset), 3. over all the condition must hold during the activity's time interval (possibly adapted by predefined constant offsets) or 4. in dur the condition must hold for some subinterval of duration within a given interval , where the interval bounds of may refer to timeline entry start or end plus some constant offset.
Even with the concept of relative ordering ( [21], section 5.1) we cannot directly refer to a linear combination of start-time and end-time, which means that in traditional planning systems we have to define at least two activities: one representing the ACS activities and one representing the memory allocation, including the image acquisition and the image analysis. These two activities need to be coupled by the information ACS activities last 10 seconds and end in the middle of a memory allocation start.
Blowing up the model to be able to formulate proper constraints is rather awkward, the main drawback about this solution, however, concerns the algorithm: To begin with, as no constraint may refer to the middle, this information must be considered by the algorithm, violating the concept of separation of algorithm and constraint modeling. Above all, however, heuristic reasoning about the valid timeline entries is much easier if all constraints are defined on one activity, because you can intersect the valid timeline entries of each constraint of the activity. If you need to consider multiple coupled activities, you can not consider one after another, unless you implement a complex repair algorithm or a sophisticated preview mechanism.
With the concept of Sliders and Offsets, we provide a simple way to model such linearly coupled constraints. To intersect constraints with different sliders (domain filtering), we need to introduce the Polygon Stack Conversion, which we describe in the remaining section of this paper.

Sliders and Offsets
In order to model the above-described example (see 3.1), one may introduce two resources, acsInUseIndicator and memoryInUseIndicator, both of which are given an initial constant value 0 and an upper bound 1. Each activity which uses ACS (including the activity detectFire) is given a constraint which increases the value of acsInUseIndicator by 1 wherever the activity is planned. This way planning two activities in parallel, which both use ACS, would cause a conflict, because the resource acsInUseIndicator would have value 2 during times where two activities overlap. Similarly all activities, which read from or write to memory, are given a constraint to increase the memoryInUseIndicator, which prevents two such activities from being planned in parallel. Note that the modification profiles of the constraints are not absolute time-based profiles but duration-based profiles, which still need to be mapped to the time axis via the activity's timeline entry (see [8]): only when we know where the activity starts and ends, can we derive the time profile, which is added to the resource profile. As stated in 3.1, the traditional mappings at start, at end and over all are not sufficient to specify the mapping we desire in our example. Instead, we define a start-reference and an endreference each of which consists of a slider ∈ ℚ and an offset ∈ ℚ . Each reference (slider, offset) transforms a timeline entry E = (start-time, duration) to a time T via an affine transformation In our example, we want to formulate that the constraint shall apply starting 10 s before the timeline entry until the middle of the timeline entry. With our definition, we can achieve this by setting: Note that the type of the resource and the effects on it have nothing to do with the concept of Sliders and Offsets. In our example, we chose constraints, which allocate a boolean resource, but we could also add another constraint referring, e.g., to the state of charge of a battery, where the effect of planning the activity could be that the resource's profile is reduced by a constant rate, starting and ending at times, specified by one Sliders and Offsets each.
Also note that the concept of Sliders and Offsets may be applied to time dependencies, too, where one slider is defined for both predecessor and successor and one common offset specifies the minimum separation in between the two times derived from the activities' timeline entries. As described in Sect. 3.1, the benefit of introducing Sliders and Offsets is that it simplifies the planning model and the planning algorithm. Unfortunately, this introduces significant complexity within our main use case, finding the set of conflict free timeline entries for a given activity. For this, each constraint must produce a PolygonSet indicating the set of conflicting timeline entries, which now needs to reflect slider and offset. In addition to this, the performance of resource dependency calculations may be improved significantly by cutting off time intervals which are out of scope due to other constraints. This cut-off, however, is not obvious due to the use of sliders.
To solve this challenge, we distinguish in between two different domains, the Timeline Entry Domain, which represents sets of timeline entries and the Constraint Domain, which represents sets of profile intervals, and we provide a conversion in between them.

Timeline Entry Domain
The Timeline Entry Domain consists of all PolygonSets (i.e., PolygonStacks with values in {0, 1} ), which represent timeline entries. An entry of the form (x, y) T with y ≥ 0 , therefore, represents a timeline entry with start-time = x and duration = y.

Constraint Domain
The Constraint Domain consists of all PolygonSets, whose values represent the start-times and durations of constraint intervals, i.e., an element (a, b) C of a PolygonSet in Constraint Domain represents the interval [a, a + b) to which the constraint's duration-based profile is mapped to. For our example of an upper resource bound with start-reference ref s = (f s , o s ) and end-reference ref e = (f e , o e ) , an element (a, b) C of a PolygonSet in the Constraint Domain represents the start-time and duration of a timeline entry after it has been transformed using the two references. This means, given a timeline entry E T = (x, y) T , the corresponding constraint interval E C = (a, b) C is given by The reverse relation can be easily obtained from (3) and (4) as for f e ≠ f s . Note that in case f s = f e , the constraint profile interval's duration is constant, no matter how long the timeline entry lasts. This case needs to be handled separately; however, it turns out that it can be easily solved using (3).

Domain filtering
Provided we can convert in between these two domains, we may apply the domain filtering of one constraint (i.e., reducing the set of allowed timeline entries) as follows: When provided with this conversion, the implementation of the constraint may omit the Sliders and Offsets and, therefore, is as simple (or complex) as without them.

Example
As an example, let us consider an upper resource bound with a constant profile 0, where the profile start is included and its end is excluded (extending our original example, this constraint may belong to an activity, which requires ACS to be inactive). The constraint's implementation without slider and offset returns a PolygonStack containing all (a, b) such that the resource's profile remains less than or equal to zero during the time interval [a, a + b) . To find the set of timeline entries, which do not violate this constraint, we need to convert this PolygonStack from Constraint Domain to Timeline Entry Domain.

Converting PolygonStacks in between Timeline Entry Domain and Constraint Domain
Whereas Sect. 3.2.2 describes how to convert one element of a PolygonSet, the main challenge is to convert rays and, thus, PolygonStacks from one domain to the other. This shall be described in this section.
Note that in case f s = f e , the duration of the constraint interval is constant for all timeline entries. It turns out that this special case can easily be handled separately, we, therefore, assume in the remaining part of the paper that Also note that the transformation is affine linear and, thus, maps lines to lines.

Lemma 2 Let s T denote the slope of a line in Timeline Entry Domain, then the corresponding line in Constraint Domain has slope s C with
Proof Let define a line in the Timeline Entry Domain passing through (x, y) with slope s T . According to (3) and (4), its image L C in the Constraint Domain consists of ( , ) ∈ ℚ × ℚ with In case f s s T = −1 , we see that is constant and according to (7) takes all values in ℚ , thus L C is a vertical line and has infinite slope. For f s s T ≠ −1 , we obtain for points ( , ) ∈ L C where = (1 + f s s T ) , yielding the slope (8). ◻ = a(x, y) + and

Lemma 3 A line with slope s C in Constraint Domain corresponds to a line with slope s T in Timeline Entry Domain, where
Proof Let denote a line through (a, b) with slope s C in the Constraint Domain. According to (5) and (6), its image L T in the Timeline Entry Domain is given by ( , ) ∈ ℚ × ℚ such that If f e = f s (1 + s C ) we see that is constant and takes all values in ℚ , thus L T is a vertical line and has infinite slope. In case f e ≠ f s (1 + s C ) , we obtain a slope ◻ Now that we know how half lines transform under this conversion, we can derive how rays are converted from Timeline Entry Domain to Constraint Domain and back. Notice, however, that it is not enough to map the half line defining the ray via this map since we are actually interested in the subset of the domain D that is defined by this ray. As this area is also bounded by the implicit vertical line above the base point of the ray, it is clear that the image of the area of a ray under such a conversion might need to be described by multiple rays. This will be shown in various examples in Sect. 3.3.2. Furthermore it is possible that the references are such that the resulting image lies in outside of the domain D, for example start-time reference = (0, 1) and end-time reference = (1, 0) will result in a constraint interval with negative duration for time intervals of length smaller than 1. Thus a conversion of a PolygonStack P in D in any direction actually means that we map the subset of D described by P to the other domain and then intersect it with D. Therefore, these conversions are not bijections of D and by mapping forth and back we introduce so-called implicit constraints as we might remove parts of the PolygonStack. This will also be explained by some examples in Sect. 3.3.2.

Converting rays
The formulas (3)(4)(5)(6) and (8)(9)(10)(11) show how the half line of a ray is transformed. It remains to consider 1. cutoffs on the left and bottom, since we don't support rays starting at e.g. x = − ∞ or rays affecting the region below their half lines, 2. the special cases of slope = ∞ and 3. whether the region above a ray's half line is mapped to the region above or below the transformed half ray Regarding 1, recall that our domain D was bounded from below (as durations are non-negative) and from the left (since we consider the whole problem only after a base time X 0 ). Since both, timeline entries and constraint intervals, can not have negative duration, values below y = 0 are considered out of scope, too. To describe the remaining two issues, one has to distinguish various cases from the different relations of startand endfactors , i.e. and for the slopes of the considered rays where S ∈ ℚ denotes the critical slope, i.e., the one which is mapped to ∞ [see (9), (11)]. For the conversion from Timeline Entry Domain to Constraint Domain, the critical slope is given by and for the conversion from Constraint Domain to Timeline Entry Domain, the critical slope is given by As stated in (7), we will not consider the case f s = f e . However, we still need to investigate 2 × 4 = 8 cases for both conversions. In the following, we pick a few examples for demonstrations. Figure 4 shows the conversion start-reference = 1 2 , 0 , end-reference = (1, 0) from Timeline Entry Domain to Constraint Domain, applied to Ray 1, 2, − 1 2 , d At , d Above which has slope greater than the critical slope. The point (1, 4) T in Timeline Entry Domain is mapped to (3, 2) C in Constraint Domain; therefore, the region above the Timeline Entry Domain's ray is mapped to the region within the dashed line and the half line starting at (2, 1) C and passing through (3, 2) C . Thus, the result of the conversion consists of two rays, the dashed line and the upper edge of the mapped region: This is an example of a PolygonStack described by a single ray in Timeline Entry Domain that is mapped to another PolygonStack in Constraint Domain that needs two rays for description. Figure 5 shows the same conversion but from Constraint Domain to Timeline Entry Domain, applied to Ray(2, 1, − 1 3 , d At , d Above ) . The point (2, 2) C in Constraint Domain is now mapped to (0, 4) T in Timeline Entry Domain; therefore, the region above the Constraint Domain's ray is mapped to the region above the continuous with Y 0 = 2 + 2(1 − X 0 ) , i.e. the ray passes (1, 2) T . Another example in Fig. 6 shows the conversion of a ray r with slope = critical slope : the converted region

Examples for conversions of rays
Ray(1, 2, −2, 0, −d Above ), would have to start at y = −∞ . To solve this, we introduce a helper-ray Ray(2, 0, −2, −d At , −d Above ) illustrated by the dotted line. As y can not take values smaller than 0 in the PolygonStack, we know that there must exist further rays on the same line, all of which start at or above y = 0 , such that all rays of the line sum up to 0 for all x > 2 . Thus, the helper-rays we introduce for all of these rays on the same line within the PolygonStack sum up to 0, which means that by introducing the helper-rays, we do not modify the PolygonStack. We, therefore, can convert the ray together with its helper-ray. The result consists of four rays In Fig. 7 one can see the conversion of a ray r with slope < critical slope . Similar to the preceding case depicted in Fig. 6, we need to introduce a helper-ray. This time the result of converting the ray and its helper-ray consists of 5 rays where the last one merely corrects the value at point (3,2), which must evaluate to 0. In case the slider of the end-reference is greater than the slider of the start-reference, complexity is introduced mainly due to the fact that rays can not point to the left and that they can not specify the value below their half line.
In case the slider of the end-reference is smaller than the slider of the start-reference, however, the rays are also mirrored, see Fig. 8. This means that a ray Ray 1, 2, 1 2 , d At , d Above with finite slope may transform to a region below a half line. However, in this case there exists a natural bound on the duration of a timeline entry to keep the constraint interval well defined. In our case, no timeline entry may have a duration greater than 6; otherwise, the constraint interval's end-time lies before its start-time. We consider such a combination of time references as an implicit duration constraint and therefore, we can restrict our PolygonStacks to those obeying the upper bound.
We now define a helper-ray H 1 which cancels the values above the upper bound, and-if applicable-two helper-rays H 2 and H 3 canceling H1 and the original ray at the crossing point of the upper bound and the to-be-converted ray, see the upper right corner of Fig. 8. Since we know that the Poly-gonStack has the ambient value above the upper bound, the helper-rays again need to sum up to 0. When mapping the ray and its helper-rays, we obtain the region below and including the dashed line, which we can represent using 4 rays To understand this mapping visually, you have to start with the upper bound helper-ray, which adds −d Above above its half line. The half line is mapped to the x-axis and as it is mirrored, the values at and above the mapped half line must be increased by d Above , which, therefore, starts the region of the mapped PolygonStack. The ray itself is mapped to the dashed line and-as it is mirrored-no longer adds d At and d Above but instead adds d At − d Above and −d Above to set the values on and above the half line.
To understand a conversion from Constraint Domain to Timeline Entry Domain as depicted in Fig. 9, one has to consider the mapping of three points: (2, 1) C → (0, 2) T , (2, 2) C → (2, 0) T and (6, 2) C → (6, 0) T . Thus, the vertical border of the ray's affected region, i.e., the vertical line above  (2,1), is mapped to the half line starting at (0, 2) and passing through (2,0). The dashed line is mapped to the upper border of the mapped region. The ray Ray 2, 1, 1 4 , d At , d Above C , therefore, is mapped to Note that in this case, we do not have to introduce helperrays because we can represent the result with two rays. Figure 10 shows the same conversion as preceding Fig. 9 but this time converting a Ray 3, 1, − 1 2 , d At , d Above which has critical slope. Again, we only need two rays to represent the result of mapping the ray from Constraint Domain to Timeline Entry Domain: Note that this time we do not need to add helper-rays either, even though the ray falls below y = 0 . We only introduced the helper-rays to be able to represent the result as a Poly-gonStack and as we can represent the result of converting this ray as a PolygonStack of two rays, everything is fine.

Performance
This paper shows how the concept of Sliders and Offsets may be handled computationally, which is a prerequisite for usage in a planning modeling language. To see whether this method is useful, we estimate briefly the asymptotic complexity of all involved operations in the following.

Internal structure
As mentioned in Sect. 1, we want the representation of a PolygonStack as collection of rays to be unique. In the following, we present two possible solutions, both of which assume the following: No two rays of the same PolygonStack may be equal in x, y and their slope s simultaneously.

Ordered set of rays
A simple internal representation of a PolygonStack is a sorted set of rays, where sorting takes place in lexical order of Note that according to the assumption 4.1, the rays of a Poly-gonStack are strictly sorted by this criterion. This representation is used by [23], a suitable sweep-line algorithm for operations is described in [20].

Lines of rays
The sweep-line algorithm as proposed by [20] needs to consider all crossings of rays, the number of which is of the order O(n 2 ) , where n is the number of rays. In our use case, we restrict to bounded PolygonSets. Within the underlying bounded PolygonStacks, each ray must be canceled by some ray emanating from a larger x. The ray canceling a given ray must reside on the same line as this ray. We, therefore, group the rays by lines; this way we only need to determine the crossing points of the lines instead of all rays. Sorting by lines introduces a complexity of O(n) ⋅ C , where C is the complexity of inserting an element into the collection of rays of the same line. For the remaining part, we assume choosing a simple balanced tree with complexity of look up and insertion being C = O(log(n)) . The sorting therefore is of complexity O(n ⋅ log(n)) . However, the benefit for the calculation of crossing points for bounded PolygonStacks is in the order of O(( n 2 ) 2 ) = O(n 2 ) . Although the overall complexity remains O(n 2 ) , we choose this representation for our estimation of complexity.
We define the precise representation as follows: 1. All rays are grouped by lines, i.e., all rays, which belong to the same line, are stored in the same group. 2. These groups are split into two types that are stored separately, namely

Addition
To add two polygon stacks G and H of size n, we need to 1. identify the set L of lines occurring in both G and H which has complexity O(n ⋅ log(n)) , and then 2. merge the groups of rays g l ∈ G and h l ∈ H which belong to the same line l. Note that merging two rays with the same x, y and slope is of order O(1) . In total, we have a complexity ∑ l∈L ∑ r∈g l log(�h l �) ≤ n ⋅ log(n) , i.e., O(n ⋅ log(n)). 3. At last, we need to create a new PolygonStack from the resulting lines which has complexity O(n).
The total complexity for this operation is, therefore, O(n ⋅ log(n)).

Evaluation
Evaluating a polygon stack at a point (x, y) may require to consider each ray in the PolygonStack. The complexity is, therefore, O(n).

Scan for value
Recall from Sect. 2.2.4 that a scan-line is a vertical line containing a ray's start point or a crossing point of two rays. In a general PolygonStack of size n, the number of crossing points is of order O(n 2 ) . To scan for a value, we need to 1. find all scan-lines which has complexity O(n 2 ) and then 2. for every scan-line s, determine the effect of all rays on s as well as the interval between s and the succeeding scan-line and then aggregate the corresponding rays. This has a complexity per scan-line of order O(n ⋅ log(n)).

Find value
To find the best value according to some linear optimization problem as described in Sect. 2.2.5, we need to check the starting points and crossing points of all rays, see Lemma 1. As there are O(n 2 ) of these points, the complexity of this operation is O(n 2 ).

Polygon Stack Conversion
As every ray needs to be converted separately, the complexity of the Polygon Stack Conversion is O(n) . This holds for both directions.

Comparison with resource calculation complexity
Our main use case is to allow resource constraints supporting Sliders and Offsets. We, therefore, compare the complexity of the PolygonStack operations with the complexity of other resource profile operations required by a planning algorithm.
A typical example of a resource operation is adding a modification profile. This may be to update the state-ofcharge profile of a satellite's on-board battery when adding an activity to the timeline. In general, this operation requires updating the whole resource profile, beginning at the time where the modification starts. The complexity of updating such a profile is O(m) , where m is the number of profile segments, i.e., intervals where the profile has constant slope and no jumps.
According to the results in Sect. 4.2, the complexity of intersecting the results of different constraints is dominated by the operation scan for value, which has to be performed once. The polygon stack calculation, therefore, has complexity O(n 3 ⋅ log(n)) , where n denotes the number of rays in the PolygonStack.
The value of n, however, does not correspond to the number of segments m of a resource. Instead, it is determined by comparing a given value b with the values of a resource. Suppose, for example, that a timeline entry may be placed only in such a way, that the resource value beginning with the timeline entry is above a certain bound, e.g., there must remain sufficient energy for all future activities. 1 To represent the set of consistent timeline entries for this query, we do not have to create one ray per segment of the resource profile, because we don't care how much energy is left, as long as there is sufficient energy left. The number of rays n, therefore, does not correspond to m but only to the number of times the profile crosses b. In practice, this value is far less than the number of segments. The O(n 3 ⋅ log(n)) complexity is, therefore, less problematic than one might think.
Nevertheless, it remains an important task of the planning engine to apply the constraints in a good order, such that large sections of complex resource profiles may be omitted due to restrictions of less complex constraints.

Summary and outlook
The main result of this paper is given by Lemmas 2 and 3. These equations allow converting timeline entry intervals into constraint intervals and back again, which forms the basis of Sliders and Offsets as introduced in Sect. 3.2 within the planning model. Although we heavily rely on Polygon-Stacks when describing why and how the conversion works, the same formulas should be applicable to any representation of sets of timeline entries, although the conversion's implementation will most likely be more complex to implement.
We selected some of the 16 cases one needs to distinguish when dealing with Polygon Stack Conversion. Using these, we have been able to demonstrate how to implement the Polygon Stack Conversion and how to handle all obstacles which occur, mainly due to the non-symmetric representation of PolygonStack.
We also justified that we do not need to fear run-time issues when introducing this kind of representation. However, the theoretical complexity of O(n 3 ⋅ log(n)) clearly indicates where to proceed when improving the run-time behavior: Step 2 in Sect. 4.2.3, where traversing from one interval to the next might re-use the result of the preceding interval.
Another interesting question and topic of future work is to apply the concept of Sliders and Offsets in algorithms based upon Temporal Networks, as e.g. in [2,9,17].