C. Coordinates Shifts

There are many places in the various output results of OP where the words SHIFT or COORDINATE SHIFT will appear. In each case the word SHIFT implies from one value to another value. Typically, the “from” value is the output of the prior adjustment, and the “to” value is the output of the current adjustment. If the user is following the sequential adjustment process outlined in Section 12, the coordinate shifts reported in different parts of the output will differ accordingly.

In general, there are 6 major steps in OP where one can expect to see the words “shift” or “coordinate shift:”

  1. Session Processing Results

  2. Preliminary Adjustment

  3. Horizontal Free Adjustment

  4. Horizontal Constrained Adjustment

  5. Vertical Free Adjustment

  6. Vertical Constrained Adjustment

C.1. Session Processing Results

The coordinate shifts from session processing are found in several places. They are most easily found in the summary results provided within the body of the email sent to the project manager. They are also in the Processing Report. This file can be accessed by clicking on the Show File button on the Manager’s Page and selecting the Processing Report, as shown in Fig. C.1.

The Show File selection bar providing access to all processing output

Fig. C.1 The Show File selection bar providing access to all processing output

The file is also included as the *.txt email attachment. There are two places to examine in the output. The first and most useful is the table of shifts near the top of the output file, called “MARK ESTIMATED - A PRIORI COORDINATE SHIFTS”, as shown in Fig. C.2.

Table of coordinate shifts resulting from session processing

Fig. C.2 Table of coordinate shifts resulting from session processing

The shifts are between the estimated (adjusted) coordinate and the a priori coordinate. At this stage in the project, the a priori coordinates can arise from two sources. A priori coordinates for CORS are their published coordinates. The same is true for user marks with published coordinates. User marks that do not have published coordinates will take their a priori coordinates from the first OPUS solution seen by OP once the user has opened the project. OP automatically sorts all observations sequentially by time, so if all observations are loaded prior to opening the project, the a priori coordinates for new marks will effectively come from the first observation. If the user uploads a first observation file for a given user mark (it could be from the very last occupation), and thereupon opens up the project in OP, the a priori coordinates for that mark will come from that very same OPUS solution, regardless of its order in time. Check the Marks page to confirm which OPUS solution has been designated the a priori.

Note that the mark selected as a constraint should have minimal shift (or as much as is allowed by the constraint preferences). The remaining marks should exhibit small shifts. A larger shift for a given mark can typically arise from three causes, a flawed occupation, data file, or a priori coordinate. The table does not tell which flaw, if any, is present. Another possibility is where most of the shifts are larger than expected. Consider a constrained mark whose published coordinate does not match its actual position on the ground. In such a case, the solution will have large shifts for many marks, all caused by constraining the one flawed coordinate.

Further down in the output after a section called UNCONSTRAINED MARKS, is another section called CONSTRAINED MARKS. In session processing, there is typically only one mark constrained (the hub). The shift indicated here for the constrained mark is the same as was given in the earlier table and is shown in Fig. C.3.

Coordinate shifts on a constrained mark shown in the results of session processing

Fig. C.3 Coordinate shifts on a constrained mark shown in the results of session processing


C.2. Preliminary Adjustment

The “MARK ESTIMATED - A PRIORI COORDINATE SHIFTS” table, as shown in Fig. C.4, is very similar to session processing, but now the shifts are computed in an adjustment using all the occupations in the sessions included in the preliminary adjustment setup. As before, the shift is between the estimated (adjusted) coordinate and the a priori coordinate. The a priori coordinates either come from published datasheets (CORSs and user marks with published coordinates) or from the first OPUS solution seen by the project (user marks that do not have published datasheets).

Coordinate shifts between the Preliminary Network Adjustment and the a priori coordinates

Fig. C.4 Coordinate shifts between the Preliminary Network Adjustment and the a priori coordinates

Shifts should be small. A larger shift for a given mark can arise from three causes (similar to session processing): a flawed occupation, data file, or a priori coordinate. The table does not tell which flaw, if any, is present. As before, if larger than expected shifts are seen across many marks, the cause may be the constrained mark’s published coordinates not matching well with the observed data. Users will need to consider each possible cause to find the problem. Careful inspection of session-by-session processing results (see Solution Statistics in Section 11.5; pay attention to the P2P values) and session-by-session vector comparison (*.vec email attachments from session processing) may reveal the source of the problem. If the shifts are out of tolerance for the project’s specifications, they will not get any better with subsequent adjustments. It is best to find the source of error (an offending observation?) at this stage.

The same shifts are also seen later in the output, in the section called “CONSTRAINED MARKS”, as shown in Fig. C.5.

Coordinate shifts between the Preliminary Network Adjustment and the a prior coordinates on a constrained mark

Fig. C.5 Coordinate shifts between the Preliminary Network Adjustment and the a prior coordinates on a constrained mark


C.3. Horizontal Free Adjustment

The Horizontal Free adjustment provides the shift between the adjusted coordinates from the Horizontal Free adjustment and those from the Preliminary Adjustment, shown in Fig. C.6.

Coordinate shifts between the Horizontal Free and the Preliminary Network Adjustments

Fig. C.6 Coordinate shifts between the Horizontal Free and the Preliminary Network Adjustments

The shifts should be small. A larger shift for a given mark can arise from the same three causes explained earlier (flawed occupation, data file, or a priori coordinate). Also, if the user selects a different constraint in the Horizontal Free Adjustment than was used in the Preliminary Adjustment, it is logical to expect a shift from the a priori coordinates. Another possible scenario is where the shifts are larger than expected across many, if not most of the marks. Consider a constrained CORS or user mark whose published coordinate does not match its observed position on the ground. In such a case, the solution will have large shifts for many marks, all caused by constraining the one flawed coordinate. Users will need to consider each possible cause to find the problem. As before, careful inspection of session-by-session processing results or session-by-session vector comparison may reveal the source of the problem.

Further down in the Processing Report (*.txt attachment) is a section on CONSTRAINED MARKS (there should only be one such mark in the Horizontal Free adjustment, as shown in Fig. C.7). As before, these shifts are between the Horizontal Free adjustment and the Preliminary Adjustment.

Coordinate shifts on a constrained mark shown in the results of the Horizontal Free Network Adjustment

Fig. C.7 Coordinate shifts on a constrained mark shown in the results of the Horizontal Free Network Adjustment


C.4. Vertical Free Adjustment

In the Processing Report for the Horizontal Constrained adjustment, two different types of shifts are given: shifts between the adjusted coordinates from the Horizontal Constrained Adjustment and the Horizontal Free Adjustment, and between the adjusted coordinates from the Horizontal Constrained Adjustment and the published coordinates.

C.4.1. Shifts between the adjusted coordinates from the Horizontal Constrained Adjustment and those from the Horizontal Free Adjustment

Coordinate shifts between the Horizontal Constrained and the Horizontal Free Network Adjustments

Fig. C.8 Coordinate shifts between the Horizontal Constrained and the Horizontal Free Network Adjustments

At this stage in the sequential adjustment process, a larger shift for a given mark can arise from two causes: a flawed a priori coordinate from the Horizontal Free adjustment, or a flawed constrained coordinate for a given mark. The table does not tell which flaw, if any, is present. The Horizontal Constrained Adjustment will almost always have several constraints, so it is logical to expect a shift from the Horizontal Free coordinates, as shown in Fig. C.8. A possible case may arise where most of the shifts are larger than expected. Consider a constrained CORS or user mark whose published coordinate does not match its observed position on the ground. In such a case, the solution will have large shifts for many marks, all caused by constraining the one flawed coordinate. Users will need to consider each possible cause to find the problem. Careful inspection of session-by-session processing results or session-by-session vector comparison may reveal the source of the problem.

C.4.2. Shifts between the adjusted coordinates from the Horizontal Constrained Adjustment and the published coordinates

Coordinate shifts between the Horizontal Constrained Adjustment and published positions

Fig. C.9 Coordinate shifts between the Horizontal Constrained Adjustment and published positions

Fig. C.9 shows a table of coordinate shifts between the Horizontal Constrained Adjustment and published positions. Large shifts here are often indicative of suspect Input constraints.


C.5. Coordinates Shifts

In the Vertical Free adjustment, coordinate shifts are between the Horizontal Constrained adjustment and the Vertical Free adjustment, as shown in Fig. C.10.

Coordinate shifts between the Vertical Free and the Horizontal Constrained Network Adjustments

Fig. C.10 Coordinate shifts between the Vertical Free and the Horizontal Constrained Network Adjustments

At this stage in the sequential adjustment process, a larger shift for a given mark can arise from two causes: a flawed a priori coordinate from the Horizontal Constrained adjustment, or a flawed vertical constraint. The table does not tell which flaw if any is present. The vertical shifts are often similar in magnitude and sign even if they are small. This is because the Vertical Free Adjustment is constraining a single Orthometric Height, rather than several Ellipsoid Heights. A few centimeters is to be expected. Another possible case is where most of the vertical shifts are larger than expected. Consider a constrained mark whose published orthometric height does not match its actual position on the ground. In such a case, the solution will have large shifts for many marks, all caused by constraining the one flawed height. Users will need to consider each possible cause to find the problem. Careful inspection of session-by-session processing results or session-by-session vector comparison may reveal the source of the problem.

Further down in the Processing Report is the section on CONSTRAINED MARKS. The shifts indicated here are between the Vertical Free adjustment and the Horizontal Constrained adjustment, but only for the coordinates constrained in the Vertical Free adjustment.

Note that the mark “e087” was constrained vertically, so the shift is only given in the vertical dimension (orthometric height), as shown in Fig. C.11.

Shift in the vertical dimension (orthometric height) shown for the mark held vertically constrained in the Vertical Free Network Adjustment

Fig. C.11 Shift in the vertical dimension (orthometric height) shown for the mark held vertically constrained in the Vertical Free Network Adjustment

Similarly, the shifts in the mark “gode”, as shown in Fig. C.12, are only given in the horizontal dimension, as the mark was constrained horizontal-only.

Shifts in the horizontal dimension shown for the mark held constrained horizontally in the Vertical Free Network Adjustment

Fig. C.12 Shifts in the horizontal dimension shown for the mark held constrained horizontally in the Vertical Free Network Adjustment


C.6. Vertical Constrained Adjustment

Similar to the horizontal constrained adjustment, two tables of coordinate shifts are provided in the Processing Report (and in the email) for the Vertical Constrained adjustment. The first table provides the geometric (3D) coordinate shifts between the vertical constrained and the vertical free network adjustment. The second table provides the shifts in the orthometric heights between the vertical constrained and vertical free network adjustments.

C.6.1. Shifts between the adjusted coordinates from the Vertical Constrained Adjustment and those from the Vertical Free Adjustment

Coordinate shifts between the Vertical Constrained and Vertical Free Network Adjustments

Fig. C.13 Coordinate shifts between the Vertical Constrained and Vertical Free Network Adjustments

At this stage in the sequential adjustment process, the horizontal shifts can be ignored. The vertical shifts should also be small, as shown in Fig. C.13. A few centimeters is to be expected. If most of the vertical shifts are larger and in the same direction than expected, this could be due to a bias in the published heights for one or more vertically constrained marks.

C.6.2. Shifts between the adjusted coordinates from the Vertical Constrained Adjustment and the published coordinates

Shifts in Orthometric Heights between the Vertical Free and Vertical Constrained Network Adjustments

Fig. C.14 Shifts in Orthometric Heights between the Vertical Free and Vertical Constrained Network Adjustments

The shifts specifically refer to orthometric heights, and the source of the published heights are given to the right of the shifts. See Fig. C.14 for several examples, including “FGCS LEVELING IN NGSIDB,” “GPS HEIGHTS: 2CM/5CM STANDARDS,” and “FGCS LEVELING NOT IN NGSIDB.”

Further down in the Processing Report is the section on CONSTRAINED MARKS. The shifts indicated here include all of the vertical constraints, as well as the horizontal constraint. The values presented here are between the Vertical Constrained adjustment and the Vertical Free adjustment.

Orthometric Height shift for a mark held constrained vertically in the Vertical Constrained Network Adjustment

Fig. C.15 Orthometric Height shift for a mark held constrained vertically in the Vertical Constrained Network Adjustment

Geometric (3D) coordinate shifts for a mark held constrained geometrically in the Vertical Constrained Network Adjustment

Fig. C.16 Geometric (3D) coordinate shifts for a mark held constrained geometrically in the Vertical Constrained Network Adjustment

Note that in the case of the mark “bell” (see Fig. C.15), only the vertical shift is given, since the mark was only constrained vertically. In the case of the mark “brun”(see Fig. C.16), the mark was constrained 3D, so shifts in all three coordinates are given.