2.3.7. The Control and Publish Page

The last page. Here you say which points have known coordinates, choose the datum, and hand the accepted baselines to the network adjustment.

2.3.7.1. The Control Grid

One row per point that appears in the baseline network.

Column	Meaning
Point	The point name, as set on the Files page.
Control	Tick if this point has known coordinates that should be held.
Easting / Northing / Height	The known coordinates, in the project’s grid system.
Constraint	How the point is held: 3D (fully fixed), 2D (position held, height free) or Height only (height held, position free).

Import from project fills in the coordinates of any point the open project already has a station for, and reports how many it filled. Use it rather than retyping coordinates that are already in the file.

Note

What you type in this grid is held in memory, not saved with the project. It is used when you publish and when you apply a datum; if you close the module without doing either, the entries are discarded. The coordinates themselves, once applied, live on the project’s stations.

2.3.7.2. Publish Settings

2.3.7.2.1. Covariance scale

Every published baseline’s covariance is multiplied by this factor. Default 3.0, range 0.1 to 100.

The reason it is not 1.0 by default: the formal covariance a GNSS processor reports is famously optimistic — it describes the precision of the mathematics, not the accuracy of the setup, and takes no account of antenna centring, height measurement or multipath. Publishing raw formal covariances gives the adjustment a wildly over-confident weight for every baseline, and the residuals then look like blunders.

Raise the factor if your adjustment shows an unreasonably high variance factor; lower it only if you have evidence that your covariances are pessimistic.

The value is stored with the project.

2.3.7.2.2. Allow FLOAT baselines

Unticked (the default), only FIX baselines are published. Tick it to publish FLOAT ones as well.

Leave it unticked for control work. Tick it only when a point is reachable by no other route, and expect the adjustment residuals to show it.

2.3.7.2.3. Datum

Mode	What is held
Free check (hold one point)	Exactly one control point is held. The network is then minimally constrained, so the adjustment reveals the internal consistency of your baselines without your control coordinates distorting it. This is the diagnostic run.
Constrained (hold all control)	Every ticked control point is held at its coordinates. This is the production run, and it is where a disagreement between your control coordinates and your GNSS network shows up.

The normal practice is to run the free check first, satisfy yourself the baselines agree with each other, and only then constrain.

Apply datum sets the constraint on the project’s stations. It touches stations only — it never adds, removes or alters an observation — so you can flip between the two modes as often as you like while reviewing a job, with no risk of duplicating or dropping anything.

Warning

A control point that has no station row in the project cannot be held — there is nothing to hold. This happens routinely: a point reachable only through FLOAT baselines gets no station at all from a FIX-only publish.

Rather than report a comfortable total, Apply datum counts only the stations it actually held and names the control points it could not find. If you see that message, publish first (or allow FLOAT), then apply the datum.

2.3.7.3. Publishing

Publish copies the accepted baselines into the project’s network observation table as GPSBaseline observations.

Before anything is written you get a preview of what will happen: how many baselines will be published, how many will be skipped and why, and which stations will have to be created. Nothing is written until you confirm.

A baseline is published when it is included, its state is ok, and its solution quality is acceptable (FIX, or FLOAT if you allowed it). Everything else is skipped, and the skips are counted separately — “excluded or unsolved” and “unacceptable fix quality” are different problems calling for different actions, so they are never pooled into one number.

2.3.7.3.1. Stations

Publishing creates a station for any point the network does not have yet, positioned from the other end of the baseline plus the vector, so the adjustment starts near the answer.

An existing station keeps the coordinates it already has. Publishing observations is not a coordinate import, and it will never overwrite coordinates you entered.

2.3.7.3.2. Orphaned points

A point can appear in the baseline list and still end up with no published observation at all — for instance when every baseline touching it came back FLOAT and FLOAT is not allowed.

Such points are counted and named in the publish log. Counting skipped baselines is not enough to catch this: a point can accumulate nothing but skips, disappear from the network entirely, and never stand out among the totals.

If a point you surveyed is reported as orphaned, it is not in your adjustment. Either re-solve its baselines to a fix, or allow FLOAT deliberately and knowingly.

2.3.7.3.3. Re-publishing

Publishing twice does not duplicate anything. Every row this module writes is stamped with the baseline it came from, and a re-publish replaces exactly those rows.

The stamp is also what protects your other data: the replace step can only ever touch rows this module wrote, never an observation you entered by hand or imported from a total station.

2.3.7.4. Going On to the Adjustment

Open Network Adjustment opens the Network Adjustment module on the same project file, so the baselines you have just published are already there — there is no export and no import in between.

From that point on the work is ordinary network adjustment: check the variance factor, look at the residuals and the redundancy numbers, and treat a GPS baseline exactly as you would any other observation.