Matt Morris

Tip of the Week #11 - Intermediate epoch handling in Trimble Mobile Manager

Blog Post created by Matt Morris on Jul 1, 2020

As we know, any field data we collect with accuracy delivered by a real-time correction source will inherit the geodetics of the correction source. That is, the points, lines and polygons that we collect will be referenced to the datum of the correction source. 

 

In many parts of the world, VRS and other real-time networks broadcast their corrections referenced to a local datum at its reference epoch. That is, the point in time where that datum (and/or realization of it) is explicitly defined. For example, in the United States, that is often NAD83 (2011) epoch 2010.00. This is the complete datum statement as it includes the epoch as the decimal year representation of January 1st, 2010. In some cases, the epoch information may be left off and the reference epoch is assumed.

Note: The epoch should always be confirmed as a missing epoch can also imply current epoch, or the current date. This is more common with global datums such as ITRF2014 and satellite correction sources like Trimble RTX or SBAS.

 

However, in certain, often tectonically active regions such as California, VRS and real-time networks may use an intermediate epoch, or a date more recent than the reference epoch. Currently, these networks in California use 2017.50 (e.g., CRTN), 2020.00, or even newer. Some networks will even adjust their reference once or more per year.

 

Typically, the high-accuracy field data you collect will be stored in a GIS system that has been setup with a datum (or more generally, a coordinate system) and the assumption of a fixed, or constant epoch. That way, you can compare data or measure distances accurately over time. But what happens when the data was collected with a real-time correction source that uses an intermediate epoch as we just discussed? What if that intermediate epoch changes over the course of your data collection efforts? Your new data will shift each time the network is adjusted.

 

The proper way of handling this is to shift the data (positions) in time using time-dependent datum transformations. In this way, we can account for the tectonic movement between epochs (specifically between intermediate and reference epochs) and store our data referenced to a consistent, constant datum and epoch. This feature is available in various Trimble software products including Trimble Mobile Manager (available in the Google Play Store) and can thus be utilized in various field data collection workflows (e.g., ArcGIS Collector).

 

In order to configure a correction source that uses an intermediate epoch in Trimble Mobile Manager, open the GNSS Configuration screen and locate the GNSS correction source set of controls at the top.

Note: The screenshots below illustrate configuration of a CRTN correction source for Southern California that uses an intermediate epoch of 2017.50.

  • For the GNSS correction source, pick Custom local and use the Server parameters controls to specify the necessary information to connect to your real-time network (protocol, URL, port, mount point, username, password, etc.).
  • For the GNSS source reference frame, pick the specific datum that your real-time network corrections are referenced to. Picking Auto will generally use the most recent realization of the "official" local datum in your region (when it connects to the GNSS receiver). Note that the Epoch control is now populated with the reference epoch value.
  • To set an intermediate epoch, use the Customize epoch toggle to enable the Epoch control for editing. Specify the intermediate epoch value in decimal year format.
  • To set the datum (at reference epoch) that you want to use in your data collection application, locate the GNSS output set of controls at the bottom. In the Detection mode control, you have 3 choices: Same as source (transformation off), Auto, or Select from list.
    - Choosing Same as source will prevent any datum transformation and will send positions to the data collection application directly without horizontal adjustment.
    - Choosing Auto will select the output datum (using reference epoch) using the same logic described above; if the input and output datums, or epochs, are different, one or more datum transformations will be used when sending data to the data collection application.
    - Choosing Select from list will enable the Frame control where you can select the specific datum. Remember that here, the reference epoch will always be used. If the input and output datums, or epochs, are different, then one or more datum transformations will be applied.
    You can also specify a Geoid for calculating orthometric heights as described in an earlier blog post.

 

For an in-depth discussion of datum and epoch issues (in the context of California), take a look at this xyHt article from earlier this year.

Outcomes