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.

B.1. Scenario 1

In the first scenario, three marks observed twice in one day, and a fourth mark is observed all day long (Figure B-1).

Scenario 1: Three marks observed twice in one day, one mark observed all day long

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.

Session A, from 6 am to 12:00 noon

Fig. B.2 Session A, from 6 am to 12:00 noon

Session B, from 12:00 noon to 6 pm

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 precisely 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 show the same data of Scenario 1, but with the addition of CORS data:

Visualization of GNSS occupations with respect to CORSs 24-hour continuous data

Fig. B.4 Visualization of GNSS occupations with respect to CORSs 24-hour continuous data

Session A: 6 am to 12:00 noon

Fig. B.5 Session A: 6 am to 12:00 noon

Session B: from 12:00 noon to 6 pm

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.

Scenario 2: Three marks observed twice in one day, three other marks observed once later in the day, and one mark observed all day

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. 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:

  1. “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

  2. splitting the CORS data between the B and C sessions which weakens the CORS estimate.

Session A from Scenario 2

Fig. B.8 Session A from Scenario 2

Session B 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, we’ll see how OP splits up the CORS data to match each individual observation session.

Scenario 3: One mark observed at four different times in one day

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.

Scenario 3 Session A

Fig. B.11 Scenario 3 Session A

Scenario 3 Session B

Fig. B.12 Scenario 3 Session B

Scenario 3 Session C

Fig. B.13 Scenario 3 Session C

Scenario 3 Session D

Fig. B.14 Scenario 3 Session D