# Understanding and Applying Scale Factors in Scanning Workflows in Trimble Business Center

*Prepared by Richard Hassler, Joe Blecha, Troy Brown, Ed Ryan*

**If you would like to download the pdf version, click here.**

## Introduction

Trimble Business Center (TBC) survey office software integrates data from multiple hardware sensor types, such as GNSS receivers, total stations, and laser scanners, into a single project. The purpose of this paper is to explain how TBC utilizes mathematical concepts like scale factors and projections to transform and align different field data types. With the data aligning seamlessly in TBC, surveyors can confidently deploy the best hardware tool(s) in the field to complete their tasks and deliver the highest quality deliverables to their clients.

## Today’s Surveying Tools, Projections, and Grid-Ground Relationships

Surveyors use many different tools to complete their tasks, including GNSS receivers, robotic or mechanical total stations, digital levels, terrestrial laser scanners, and unmanned aerial vehicles (UAVs). These tools work on or near the surface of the earth.

Total stations and scanners provide distance measurements that agree with the same measurements you would make between points using a measurement chain or tape. These are called *ground measurements*. A simple X,Y,Z Cartesian coordinate system is the basis for the trigonometric calculations for angles and distances for these types of devices. To integrate these measurements with those from other devices, including GNSS receivers, aerial imaging systems, and mobile mapping solutions, it is necessary to look to geodesy and mapping projections to combine the data types. The underlying mathematics to integrate the data is far more involved than when using just total stations or scanners; but once combined, the final results can be provided in any desired coordinate system.

Global Navigation Satellite Systems (GNSS) solutions, and systems that include GNSS receivers to produce results (for example, mobile mapping and aerial imaging systems), require the use of a global model to be able to make measurements that can be related to the earth’s surface. An ellipsoidal model of the earth, such as the Geodetic Reference System 1980 (GRS80) or World Geodetic System 84 (WGS84), is the basis for the measurements. This curved surface is standardized to represent an average fit over the entire globe and it is centered and oriented to match the earth and its rotation axis. Also, it rotates with the earth, so a point on the ellipsoid relates to a point on the earth. This is called an *Earth Centered Earth Fixed (ECEF)* system. Positions related to this model are provided as latitudes, longitudes (see Figure 1), and heights above or below the ellipsoid. The orbits of the GNSS satellites can be related to the ECEF ellipsoid and then used in sophisticated computations to produce precise differences in position between GNSS receivers that are located on or near the earth that are collecting common satellite data.

*Figure 1 – Lines of Latitude and Longitude on the earth*

Using differences in latitude, longitude and height in calculations to describe differences in positions on the earth is mathematically challenging and non-intuitive, so to simplify analysis for surveyors it is necessary to generate coordinates that are more easily understood and used in calculations. To do this the latitudes, longitudes and heights are first projected to some form of standardized grid with a reference elevation. If required, it is then possible to rotate, scale, and translate those projected coordinates into a localized ground-based coordinate system. These coordinate projections and transformations make it possible to relate the GNSS-derived coordinate differences to directly-made ground measurements, like those from total stations and scanners.

Surveyors are tasked with making measurements for many kinds of projects, from small construction surveys to large scale control networks covering vast regions. Depending on the purpose of the survey, the final results may need to be reported relative to a ground-based coordinate system or related to a standardized projection grid. The form of the required final results may guide the surveyor to employ one measuring solution over another; but it is not uncommon to combine measurements from different solutions on a single project.

## Ground-Based Coordinate Systems (“Ground”)

Ground-based coordinate systems provide distances that match measurements made directly on a site. They are typically used for projects that involve construction of localized sites and buildings. Construction plans for a site are usually related to a ground-based coordinate system to take advantage of this simplicity. Because of this, it is important that the measurement solutions used on the site use ground-based coordinate systems to report distances that match the plans.

A disadvantage of this kind of simple X,Y,Z coordinate system is that measurements don’t fit together well over large distances. The impact of the curvature of the earth and large elevation differences across the site are not addressed in such a simple system. For geographically larger or more complex projects, and projects where different measuring solutions are used, a more complete geodetic solution must be employed that addresses the complexities of fitting measurements made on a curved earth into a rectilinear system that can be represented on maps and in computer software solutions.

## Grid or Map Projections (“Grid”)

For geographically larger projects, and projects where the results must fit together with other projects across municipalities and larger geographic areas, a grid (or map) projection is introduced to produce values that are consistent with the project’s location on the earth.

Grid projections are flattened approximations for the curved surface of the earth. Two common types of projections in use are the Transverse Mercator (usually applied to regions that are elongated in the North-South direction shown in Figures 2 and 3) and the Conical Lambert (usually applied to regions elongated in the East-West direction shown in Figures 4, 5, and 6), which use a cylinder and cone, respectively, to approximate the curvature of the earth over a particular region.

### Transverse Mercator Projection

*Figure 2 – Transverse Mercator Projection uses a cylinder*

*Figure 3 – Flattened Transverse Mercator scale differences*

### Conical Lambert Projection

*Figure 4 – Conical Lambert wrapped around the earth*

*Figure 5 – Conical Lambert Projection uses a cone*

*Figure 6 – Flattened Conical Lambert scale differences*

## Scale Factors – The Great Equalizer

Combining data types from different hardware, projections, and measurements requires the strategic application of grid and elevation scale factors. Both have their own purpose and together define a combined scale factor to properly position, display, and model multi-source data types in a single-project environment.

### Grid Scale Factor

Neither a cylinder nor a cone will perfectly agree with the curvature of the ellipsoidal model of the earth. Each of these grid surfaces approximate the curvature of the ellipsoid in one direction but deviate from it in the perpendicular direction. The choice of which type of grid surface to use depends on the geographic shape of the region to which it will be applied. Thus the shape and fit of the projection surface is designed to minimize distortions between the projection and the curved ellipsoid.

For commonly used grid projections and their placement relative to the ellipsoid, there are areas within the projection boundaries where either the cylinder or cone lies beneath the surface of the ellipsoid and there are areas where it lies above it. The illustration below shows that distance measurements projected onto the grid will differ from the distances measured along the surface of the ellipsoid itself, which are called geodetic distances. This difference is called the grid scale factor, defined as the ratio of the projected distance on the grid projection to the geodetic distance along the ellipsoid:

Grid Scale Factor = (Grid distance / Ellipsoid distance)

For most grid projection types, there are lines where the projection surface intersects the ellipsoid. Along these lines of intersection, there is no difference between a geodetic distance and its corresponding grid distance. These lines have a grid scale factor of 1.0 as shown in Figure 7. Since most survey points in a project do not lie exactly on a line of intersection, scale factors must be applied to measured geodetic distances to project them onto the grid surface properly. Each point in the project will have a slightly different grid scale factor depending on where it lies on the grid surface with respect to the lines of intersection with the ellipsoid.

*Figure 7 – Map projection as it relates to the earth’s surface and ellipsoid surface*

### Elevation Scale Factor

The elevation scale factor is the ratio of the ground-based distance between two points divided by the geodetic distance measured along the ellipsoid between those points’ projection onto the ellipsoid.

Elevation Scale Factor = (Ellipsoid distance / Ground distance)

Many ellipsoids, such as GRS80 or WGS84, are designed to roughly approximate mean sea level globally. For points that lie on the earth’s surface near sea level, the ground-based distance measured between points will closely match the geodetic distance measured along the ellipsoid. The elevation scale factor will be nearly 1.0 for these points. If the project site lies significantly above sea level, the ground-based measurements there will be much longer than their grid equivalent near sea level.

An example relationship between distances measured relative to the ground, ellipsoid, and grid is illustrated below in Figure 8.

*Figure 8 – Ground, ellipsoid, and grid relationships*

It should be noted that the elevation scale factor for points will vary if the elevation changes significantly across the project. Imagine designing a road that extends up the side of a large mountain. The elevation scale factor at the top could differ dramatically from the scale factor at the bottom of the mountain. For projects containing large elevation differences, consideration should be given to separating the project into smaller pieces. The division should leave each piece with less elevation difference within it, to keep the elevation-induced distortions to a minimum.

### Combined Scale Factor

To properly model ground distances for a given grid projection, the appropriate grid scale factor and elevation scale factor must be incorporated. The product of these two is called the combined scale factor and it is the ratio that is employed in geodetic software packages like TBC to make the ground-based observations fit properly onto the grid projection. The computation of the combined scale factor is as follows:

Combined Scale Factor = Grid Scale Factor * Elevation Scale Factor

= (Grid distance / Ellipsoid distance) * (Ellipsoid distance / Ground distance)

= Grid distance / Ground distance

Note that while the combined scale factor is influenced by heights above the ellipsoid and elevations, the combine scale factor value only applies to horizontal distances, as the equation above shows.

The combined scale factor and its proper application is the critical step for TBC to align different types of raw survey, scan, and point data. The rest of the paper introduces how TBC uses these geodetic computations and how the combined scale factor impacts supported data types.

### Side Note: Grids At Elevation

As depicted in the grid projection illustrations above, many grid projections employ a cone or cylinder that directly intersects the model ellipsoid itself. This places the grid at or near sea level for most ellipsoids in use.

Modern projection systems may include placement of the grid projection at a more appropriate elevation to the geographic region it represents. This reduces the elevation-induced distortion described in previous sections.

*Figure 9 – Low-distortion projections compared to the earth’s surface*

For example, grid projections in Colorado in the United States could be placed at an elevation of approximately one mile (5280 feet or approximately 1609.34 meters) above sea level because the majority of the population lives near this elevation in the three Conical Lambert zones that fit the state. Rather than projecting measurements onto a grid placed at the ellipsoid, this projection would be to a non-intersecting grid at the elevation of the region of interest as shown in Figure 9 (image source: NOAA's National Geodetic Survey). This would minimize the impact of the combined scale factor as the elevation differences would be small between the grid projection and survey projects done on the earth’s surface near the population centers.

This type of low distortion projection is employed by some government agencies today. They tend to be applied to smaller regions (for example, counties in the United States) to allow for the selection of appropriate grid elevations that reduce the distance distortions for the areas of interest. Defining the projection to cover too large of a region could negate the improvements seen by placing the grid near a target elevation, if the surface elevations across the region vary greatly. The United States National Geodetic Survey (NGS) currently is giving consideration to this kind of projection for the modernized State Plane Coordinate Systems to be used with the National Spatial Reference System (NSRS) 2022.

## Theory Meets Practice in TBC

TBC is a unique CAD platform because it uses the combined scale factor for computation and display of survey data, creating a true geodetic environment, rather than simple Cartesian grid-coordinates used by other survey CAD packages. At first launch, TBC presents its default Plan View as a simple grid – Northing (Y) and Easting (X) as shown in Figure 10.

*Figure 10 – TBC at first launch looks like an ordinary Cartesian CAD grid*

TBC, as a geodetically-based product, requires a coordinate system be used. A local Transverse Mercator system can be created automatically for the project by choosing the Default coordinate system and importing data, or a pre-defined coordinate system can be selected from the library provided by Trimble. Alternatively a coordinate system can be custom-defined using the included Coordinate System Manager application, shown in Figure 11. The Coordinate System Manager interacts with the coordinate system library that is used by many Trimble applications including TBC and Trimble Access field software. This library ensures that the coordinate systems are consistent when reused across different applications.

*Figure 11 – Coordinate System Manager – where TBC gets its geodetic start*

Each point from a GNSS observation, station setup, or other survey measurement in TBC has a combined scale factor based on its position. For projects across a small site, like a new commercial building, the differences between the combined scale factors for the unique points are so small they are not noticeable (for example, decimals out to the seventh or eighth decimal place). But for projects near the edges of a map projection, projects that encompass a large site (for example, stakeout of several miles of a linear corridor), or projects that include large elevation differences (for example, a topographic survey through a mountain canyon), the combined scale factors produce visible differences in the data.

Depending on the coordinate system selected in the Project Settings, TBC will use appropriate combined scale factors and orientations for grid display of the field data based on its location within the project. If field data is moved by changing a station’s coordinates or by georeferencing, the appropriate combined scale factor for the new location will be applied to display the data correctly on the grid. This is the best way to correctly merge data from different sources. In TBC there is not a single combined scale factor universally applied across the entire project. Even the Default system has a defined scale factor (usually 1.0) at the origin. Data located away from the origin uses the appropriate combined scale factor for computations based on its position.

Once field data is imported into TBC, a variety of tools is available to inspect and interact with the raw field measurements, such as the GNSS Vector Spreadsheet or the Total Station Optical Spreadsheet. Each measurement or station setup in the field computes a point in TBC that can be viewed in the Point Spreadsheet. Along with a point’s ID and coordinates, it is possible to display its current grid scale factor, elevation scale factor, and combined scale factor by turning each to 'Show' in the Project Settings, illustrated in Figure 12, resulting in the Point Spreadsheet in Figure 13.

*Figure 12 – Project Settings to turn on Grid/Ground Properties in the Point Spreadsheet*

*Figure 13 – TBC’s Point Spreadsheet with scale factors shown*

## GNSS and Total Station Survey Data in TBC

TBC imports GNSS field data collected with Trimble and supported third-party hardware and creates a station at each base and VRS position. From these stations, GNSS vectors flow to the other static or rover positions where points are created, shown in Figure 14.

TBC imports total station field data from Trimble and supported third-party hardware and creates a station at each setup position. From each of these stations, total station observations flow to measured positions where points are created, shown in Figure 15.

In both TBC (and Trimble Access), points are automatically positioned from the raw field measurements from GNSS receivers and total station instruments by using geodetic calculations dependent on the coordinate system. The raw measurements from the instruments and the chosen coordinate system parameters are written into the field file, such as a *.jxl or *.job from Trimble Access. When the field file is imported, TBC compares the coordinate system used in the field with the active coordinate system in the TBC project. If they differ, there is an option to decide which coordinate system to use and TBC automatically transforms the data into the selected coordinate system. This assures that grid positions are consistent between the field and office software.

*Figure 14 – GNSS vectors (blue) and Vector Spreadsheet in TBC – Notice the “from point” and “to point” columns*

*Figure 15 – Total station observations (green) and Optical Spreadsheet in TBC – Notice the “from point” and “to point” columns*

## Digital Level Data in TBC

TBC imports digital level data collected with Trimble or supported third-party hardware via the Level Editor in Figure 16, where elevations can be adjusted and closure errors minimized. Once adjusted and imported into TBC, points are created with elevation components only.

Since the combined scale factor affects the horizontal component of distances only, digital level data alone is not impacted by the combined scale factors.

*Figure 16 –Trimble DiNi data in TBC’s Level Editor*

## CAD and Point Files in TBC

Combined scale factors are not applied to CAD files (such as *.dwg or *.dxf’s) and point files imported into TBC. This ensures that the imported coordinates and geometry values from the source files are maintained. A combined scale factor is computed from each survey point from a CAD or point file just like survey points imported from field devices and controllers, such as a *.jxl from Trimble Access. These combined scale factors are viewable in the Points Spreadsheet.

CAD files can be dragged-and-dropped into TBC and are positioned per the units and values stored in the file. If the units cannot be read, the files are imported as “unitless” which may lead to a mismatch, for example between metric and US imperial units.

To correctly import points into TBC, there must be an import definition that matches the format of the point file. TBC includes many standard import formats, such as (PointID, N, E, Elev, Code) or (PointID, E, N, Elev, Code). Customized formats can also be created in the Import Format Editor, which includes an option (highlighted in Figure 17) to import points as survey points that are transformed with coordinate system changes, or as grid-only points that do not transform with coordinate system changes. The points in these files (for example *.csv or other ASCII formatted files) are imported at the coordinates written in the file.

For each of these file types, TBC assumes that the coordinate system for the imported file matches that of the active coordinate system in the TBC project, otherwise the grid positions of the imported point(s) may not agree with expectations.

*Figure 17 – TBC’s Import Format Editor option to import as grid-only points*

## Aerial Imaging and Mobile Mapping Data in TBC

TBC supports the creation and processing of:

- Aerial imaging data from unmanned aerial vehicles (UAVs) written into a *.jxl or other supported file format
- Mobile mapping data from Trimble’s MX9 hardware system

Since imported aerial and mobile data in TBC often includes GNSS positions (either with Autonomous quality positions that need to be post-processed in TBC, or with Survey quality positions that have already been processed), all pertinent coordinate system transformations and calculations are applied similarly to those applied to GNSS data. TBC reads the coordinate system parameters written into the field files and can transform the data to any user-selected coordinate system, just like for GNSS field data.

Points, such as ground control points (GCPs) used for georeferencing, are imported using a *.csv or other ASCII file format, same as the point file import process detailed in the previous section.

Point clouds created from aerial images in TBC are georeferenced during the image adjustment steps, so after creation they are already positioned and scaled according to their positions within the coordinate system based on the GCPs, as illustrated in Figure 18.

*Figure 18 – High-precision UAV data from a fixed wing drone in TBC*

When TBC creates mobile mapping point clouds from the Trimble MX9 hardware sample project shown in Figure 19, the long project distances (projects can be hundreds of kilometers in length) are handled differently from other point clouds. In the computations, TBC divides the point cloud into shorter sections, then applies the same combined scale factor to each section’s centroid. This single combined scale factor is computed from the overall mobile mapping run and reduces any distortion from the map projection across the length of the point cloud, particularly at the extreme ends. The application is diagrammed in Figure 20.

*Figure 19 – Mobile mapping data from Trimble’s MX9 mobile mapping system*

*Figure 20 – Trimble MX9 data is broken into smaller divisions for scale factor application*

## Scans and Point Cloud Data in TBC

### From Trimble Equipment + Supported Formats

When scans from Trimble’s optical and scanning hardware, such as the Trimble SX10 total station or the Trimble X7 laser scanner, are imported into TBC, they are related to their station. The station information allows TBC to position and scale the scan data automatically. This ensures that no input parameters are needed and data is positioned and aligned with other station-based survey data just like data from a GNSS receiver or optical total station. There are two types of station-based point clouds - those based on survey stations and those based on scan stations.

Scan data collected with a Trimble SX10 using a survey station (a station setup or a resection, for example) will be registered properly after import into TBC using the same station position and orientation as the survey data from the total station. If the stations to which the scans are attached are moved, the scan data will be automatically re-positioned and oriented to match survey data and scaled based on the new station positions in the survey.

Scans collected with a Trimble X7 or other supported laser scanner that are registered in the field are imported into TBC as scan stations using the field derived station positions and orientations. Typically, this means that they will be positioned near (0,0,0) in the project coordinate system and the field registration will be maintained. Scan data imported into TBC is scaled based on the positions of the scan stations in the project. It is up to the user to georeference or position the Trimble X7 scan data in TBC, which will move the scan stations. If the scan stations are moved by georeferencing or another registration, the new station positions are used to re-scale the scans.

Data collected using a supported scanner that is not registered or georeferenced prior to import is also related to the station. The scans are initially positioned in TBC based on the position, if any, that was set in the field, and on which data, if any, already exists in the TBC project. For example, scan stations from the Trimble SX10 might be positioned in Trimble Access. If so, then TBC will import the scan stations with point clouds at the position from the field file. If no position is set in the field, with a Trimble TX8 for example, TBC will import the scan stations at (0,0,0). Like the above scenarios with Trimble SX10 survey stations and in-field registered Trimble X7 scan stations, scan data imported into TBC is scaled based on the positions of the scan stations in the project. Once imported, point clouds can be georeferenced or registered, which will move the scan stations. If the scan stations move, the new station positions are used to rescale the scans. Also the scan stations themselves will receive a slight change in orientation due to grid convergence effects. These changes are mathematically necessary to ensure that the scans are located and oriented correctly to match the project data. The net result is that any existing scan registrations will be altered and need to be re-checked after the move. Registration between scan groups and refinements within scan groups need to be verified after georeferencing the scans in TBC.

### From Third-Party Formats

TBC supports importing industry-standard point cloud file formats such as *.e57, *.las, *.laz, and others. These point clouds could come from any sensor or software; TBC does not know their source. For example the file could contain a non-georeferenced point cloud straight from a terrestrial scanner, or a point cloud georeferenced to a grid coordinate system projection, like a Universal Transverse Mercator (UTM) coordinate system.

So to properly position the point cloud in TBC’s geodetic environment, TBC provides import options from which to choose, shown in the Figure 21 below:

*Figure 21 – TBC’s Point Cloud Scale Factor Import Options*

Selecting the correct option, based on what is known about the data in the imported file, is important. Otherwise there is a risk that the point cloud will be positioned incorrectly and scaled so that it does not match the other data in the project. These incorrect scaling effects on the data could be obvious or unnoticeable.

When importing point clouds into TBC or any CAD package, these questions need to be answered:

- What sensor collected the point cloud data?
- Is the point cloud georeferenced, registered, or scaled already?

The import menu options shown in the Figure 21 above accommodate the most common point clouds imported in TBC. Selecting the “More Options” check box as shown in Figure 22, exposes additional choices that support less common situations, like importing a point cloud georeferenced in a coordinate system different from the project coordinate system in TBC.

*Figure 22 – The More Options checkbox supports additional import scenarios*

When selecting either the “Non-georeferenced, ground-scaled” or “Georeferenced” option, TBC reads the point cloud and computes its centroid, where it will apply the combined scale factor. Just like any survey data, this combined scale factor is dependent on the coordinate system and position of the point cloud within the TBC project. By handling point cloud data and survey data the same in TBC’s unique geodetic environment, data from GNSS and total stations will align with point cloud data from any source as shown in Figure 23.

*Figure 23 – TBC assures that point cloud data and survey data will align properly*

If it is unclear which option to choose, the TBC Help topic “Select Scale Options When Importing a Point Cloud File” depicted in Figure 24, is linked directly in the dialog via the ”Help” button. This topic provides additional examples and more details to aid in importing the point cloud correctly.

*Figure 24 – TBC’s help topic features more guidelines to assure proper point cloud import*

### Exporting from TBC

When exporting data from TBC for use in other software, it is important to consider how the data will be used and in what type of package. For example, exporting points from TBC in a simple *.csv file is straightforward, as the coordinates in the exported file will match those in TBC. If the coordinate system and units in the downstream package do not match those of the original TBC project, the exported file could be positioned well outside of the expected project area. This is a small but important detail that surveyors and construction professionals may think of as common sense, but this is the simplest export case and can be overlooked, particularly near map projection boundaries and when crossing between regions using US Survey Feet and International Feet units.

For geometry exports – linework like 2D/3D polylines, circles, polygons – the risks are similar to point files. TBC exports dimensions and positions that match those displayed in the project. It is up to the user to maintain consistency in the future import.

Point clouds exported from TBC’s geodetic environment are not as simple and it is critical to understand in which software the point cloud will be used and how that software handles data. To assist with exporting from TBC, follow these guidelines:

## Glossary

*Cartesian coordinates* – A set of three coordinates based around a fixed reference point (the origin), each representing a perpendicular distance along a plane which intersect the origin at a right (90 degree) angle.

*Combined scale factor* – The ratio of grid projection distances to ground distances, used to compute ground distances in TBC’s geodetic-based grid projections and align different types of raw survey, scan, and point data.

*Earth Centered Earth Fixed (ECEF)* – A coordinate system with its origin based at the earth’s center of mass with components expressed in latitude, longitude, and heights with one of its axes matching the earth’s axis of rotation and the others rotating with the earth.

*Elevation scale factor* – The ratio of the ground-based distance between two points, divided by the geodetic distance measured along the ellipsoid between those points’ projection onto the ellipsoid.

*Ellipsoid* – A mathematical “best fit” model of the earth formed by rotating an ellipse around its polar axis. The ellipsoid is centered and oriented to match the earth and its rotation axis.

*Geodetic distances or measurements* - Distances measured along the surface of the ellipsoid.

*Grid or map projections* - Flattened approximations for the curved surface of the earth.

*Grid scale factor* – The ratio of the projected distance on the grid projection to the geodetic distance along the ellipsoid.

*Ground-based coordinate systems* – Provide distances that match measurements made directly on a site. They are typically used for projects that involve construction of localized sites and buildings.

*Scan station* – A station in TBC whose position and orientation are computed by Cartesian calculations. These calculations could come from scan georeferencing or registration. A Trimble X7 or TX8 laser scanner setup is a scan station in TBC.

*Station-based point cloud* - A TBC term for a point cloud that has an associated scan station, which is represented by an associated Point node and Scan station node in the Project Explorer. The position of the scan station can be thought of as a reference position (that is, the position that is used to compute the combined scale factor (CSF)). As a station-based point cloud is moved horizontally and vertically, the CSF is automatically changed. Generally speaking, station-based point clouds are desirable because various automatic functions are enabled for them.

*Survey station* – A station in TBC whose position and orientation are computed using geodetic calculations. Field measurements originating from a survey station are also computed using geodetic distances. A Trimble S7 total station setup is a survey station in TBC.

For more information on Trimble Business Center, click here.

We also have a variety of online resources to help you get up to speed using Trimble Business Center.

##
Download Trimble Business Center

Thank you for your interest in Trimble Business Center! You should receive an email soon with further instructions.

### About the Author

Trimble Geospatial provides Land Surveying, GIS, Scanning, Mobile Mapping, Remote Sensing, Photogrammetry and Forensics professionals with industry leading hardware and software solutions.