B. How OP Arranges GNSS Observations into Sessions
OP always attempts to arrange GNSS observations into discrete, repeated sessions. In this appendix, three scenarios are explored as a means to help explain how OP might arrange a user’s sessions. The scenarios are meant to be hypothetical in nature: real-life situations would include break-down and transit times between deployments. In addition, best practices would be to allow sufficient time between occupations for satellite geometries to change, resulting in somewhat more independent samples.
B.1. Scenario 1
In the first scenario, three marks observed twice in one day, and a fourth mark is observed all day long, as shown in Fig. B.1.
Fig. B.1 Scenario 1: Three marks observed twice in one day, one mark observed all day long
Marks A, B, and C are observed twice on a given day, in repeated 4-hour sessions: 8 am to 12 noon and then again from 12 noon to 4 pm. However, mark D is observed all day long. To prevent duplication of data/results in the network adjustments and to fulfill the requirements of bluebook, OP will attempt to create two sequential sessions on Day 1. Session A will extend from 6 am to 12:00 noon; Session B will extend from 12:00 noon to 6 pm, as shown in Fig. B.2 and Fig. B.3.
Fig. B.2 Session A, from 6 am to 12:00 noon
Fig. B.3 Session B, from 12:00 noon to 6 pm
The reason OP does not group all of the observations for mark D in, say, Session A is because OP is designed to allow users to deploy temporary GNSS reference stations (“temporary CORS”) to serve as local hubs in session and network processing. When OP brings CORS data into the project, it always tries to use the maximum possible data from a CORS in a 1 day (or 2 day) period without re-using observations. The figures below (Fig. B.4, Fig. B.5, and Fig. B.6) show the same data of Scenario 1, but with the addition of CORS data:
Fig. B.4 Visualization of GNSS occupations with respect to CORSs 24-hour continuous data
Fig. B.5 Session A: 6 am to 12:00 noon
Fig. B.6 Session B: from 12:00 noon to 6 pm
B.2. Scenario 2
Three marks observed twice in one day, three additional marks observed only once, one last mark observed once all day long, as shown in Fig. B.7.
Fig. B.7 Scenario 2: Three marks observed twice in one day, three other marks observed once later in the day, and one mark observed all day
In this scenario, marks E, F and G are different marks (no reoccupation of A, B, C or D). Although the user may attempt to fit marks E, F, and G into their own session, OP will consider them as part of the second session, along with the repeat observations on A, B, and C, this is shown in Fig. B.8 and Fig. B.9. Effectively, they are all just observations in the time span of a second session. To put E, F and G in their own session would require either:
“splitting” D if it is serving as a temporary CORS and omitting data from E, F and G because of the requirement for mutual visibility from mark - HUB or
splitting the CORS data between the B and C sessions which weakens the CORS estimate.
Fig. B.8 Session A from Scenario 2
Fig. B.9 Session B from Scenario 2
B.3. Scenario 3
One mark observed four different times in one day:
In this example, shown in Fig. B.10, we’ll see how OP splits up the CORS data to match each individual observation session.
Fig. B.10 Scenario 3: One mark observed at four different times in one day
Since there are four independent sessions, OP will correctly identify the sessions, and use as much independent CORS data as possible for each session. This means that sessions A and D will have more CORS data available compared to sessions B and C. This is illustrated in Figures Fig. B.11, Fig. B.12, Fig. B.13, and Fig. B.14 below.
Fig. B.11 Scenario 3 Session A
Fig. B.12 Scenario 3 Session B
Fig. B.13 Scenario 3 Session C
Fig. B.14 Scenario 3 Session D