Georeferencing Tools

Your drone captured centimeter-accurate data, but it doesn't match your surveyor's control points. Or you need to deliver in State Plane when your cloud is in UTM. These are the two problems Viizor's Georeferencing Tools solve.

Introduction

Viizor Desktop's georeferencing tools solve two critical problems in professional point cloud work:

1. GCP Alignment: Align a point cloud to ground control points when the cloud doesn't match field-surveyed coordinates. Even with RTK GPS, drone data can deviate centimeters or decimeters from total station measurements.

2. CRS Converter: Convert a point cloud from one coordinate reference system to another—for example, from WGS84 geographic coordinates to UTM projected coordinates, or from UTM to State Plane.

Both tools preserve the internal geometry of your point cloud while transforming its position in space.

GCP Alignment: Align to Ground Control Points

What Problem It Solves

When you fly a drone with RTK or PPK GPS, the coordinates depend on GPS precision. Even with RTK corrections, systematic errors can cause deviations of centimeters or decimeters compared to ground control points measured with a total station or high-precision GNSS.

GCP Alignment applies a 7-parameter Helmert transformation to adjust the entire point cloud to match your GCPs.

Helmert Transformation Parameters

The Helmert transformation (also called a similarity transformation) adjusts seven parameters:

This transformation is rigid—it preserves relative distances between points. It's ideal for correcting systematic GPS errors without distorting the cloud's internal geometry.

Step-by-Step Workflow

Requirements

• Minimum 3 GCPs with known coordinates (5+ recommended)
• CSV or TXT file with GCP coordinates
• Point cloud loaded in Viizor
• Knowledge of the GCPs' coordinate system (EPSG code) and units

Step 1: Prepare the GCP File

Create a CSV file with your control point data:

The system automatically detects:

• Delimiter (comma, semicolon, tab, or space)
• Whether the file has a header row
• Column types (coordinates, names, descriptions)
• Probable coordinate system based on value ranges

Step 2: Import GCPs

1. Open Tools > Georeferencing Tools
2. Select the point cloud to align
3. Click Import File...
4. Select your CSV file

Viizor displays a professional import modal with:

• Column Mapping: Assign which column is X (Easting), Y (Northing), Z (Elevation), and Name
• GCP EPSG: The EPSG code of your GCPs' coordinate system
• GCP Units: Meters, International Feet, or US Survey Feet

Step 3: Pair GCPs with Points in the Cloud

After import, GCPs appear as red markers in the 3D viewer.

For each GCP:

1. Click on the red GCP marker
2. Click on the corresponding location in the point cloud where that control point is physically located
3. A green marker (observed point) appears, connected to the red marker by a yellow line

The GCP list shows the status of each pair:

Each paired GCP displays its residual error—the distance in meters between the GCP coordinate and the observed point before transformation.

Step 4: Calculate Transformation

With 3 or more pairs created:

1. Click Calculate Transformation
2. Viizor computes the optimal Helmert parameters and displays:
   • RMSE (Root Mean Square Error): Overall accuracy metric
   • Max/Min Error: Largest and smallest individual residuals
   • Helmert Parameters: Scale factor, rotations (degrees), translations (meters)
   • Per-point errors: Residual for each GCP to identify outliers

Step 5: Apply Alignment

If the RMSE meets your accuracy requirements:

1. Click Align Cloud
2. Confirm the output file location
3. Viizor generates a new LAS/LAZ file with transformed coordinates
4. Option to automatically import the aligned cloud into the viewer

The original file remains unchanged—alignment always creates a new file.

Automatic Height Detection

If your CSV contains both Elevation (orthometric) and Ellipsoidal Height columns:

1. Viizor compares both heights against the Z value in the point cloud at that location
2. Recommends which height type to use based on the smaller discrepancy
3. Displays the difference for each option versus the cloud

This is critical because:

• Drone GPS (RTK/PPK) typically captures ellipsoidal height
• Traditional surveying usually provides orthometric height (above mean sea level)
• The difference can be 20-40 meters depending on geographic location

Professional Tolerances

Application	Acceptable RMSE
Construction	< 3 cm
Topographic Survey	< 5 cm
Mining/Stockpiles	< 5 cm
Cadastral	< 10 cm
Agriculture/Forestry	< 15 cm

If RMSE exceeds expectations:

1. Verify the EPSG code of your GCPs is correct
2. Check units (meters vs feet vs US Survey feet)
3. Confirm observed points are accurately placed in the cloud
4. Review individual residuals—consider removing GCPs with anomalously high errors
5. Ensure orthometric/ellipsoidal height is correctly specified

CRS Converter: Coordinate System Transformation

What Problem It Solves

You need to combine point clouds from different sources:

• A drone cloud in WGS84 (EPSG:4326)
• A terrestrial scanner cloud in UTM Zone 17N (EPSG:32617)
• Reference data in State Plane (EPSG:6570)

CRS Converter transforms an entire point cloud from one coordinate system to another, preserving precision.

Conversion Workflow

Step 1: Select Cloud and Detect CRS

1. Open Tools > Georeferencing Tools
2. Click the CRS Converter tab
3. Select the point cloud to convert

Viizor reads the LAS file metadata and displays:

• Detected EPSG
• CRS Name
• Units

If the CRS isn't detected, you can search manually by EPSG code or name.

Step 2: Select Target CRS

The selector shows contextual suggestions based on the source CRS:

If source is geographic (lat/lon):

• Suggested UTM zone calculated from cloud center
• Adjacent UTM zones
• Web Mercator (EPSG:3857)

If source is projected:

• WGS84 Geographic (EPSG:4326)
• Web Mercator
• Other common systems

Step 3: Advanced Options

Transform Z (Height):

• Default: Only transforms X, Y coordinates
• With checkbox enabled: Also transforms Z (required when changing ellipsoids or datums)

Step 4: Execute Conversion

1. Click Convert Cloud
2. Confirm parameters
3. Viizor generates a new file: original_EPSG{target}_{timestamp}.laz
4. Option to automatically import the converted cloud

Common Use Cases

Combine Drone + Terrestrial Scanner

Export for Google Earth

Meet Client Deliverable Requirements

Technical Concepts

EPSG Codes

An EPSG code uniquely identifies a coordinate reference system. Common examples:

EPSG	System	Common Use
4326	WGS84 Geographic	GPS, Google Maps
4269	NAD83 Geographic	North America
32617	WGS84 UTM Zone 17N	Florida, Georgia, South Carolina
6570	NAD83(2011) SC (ftUS)	State Plane South Carolina
3857	Web Mercator	Web maps (Google, Bing, OSM)
26917	NAD83 UTM Zone 17N	NAD83-based UTM

To find your EPSG code: epsg.io

Units

• Meters: Most metric systems (UTM, most international CRS)
• International Feet: 1 ft = 0.3048 m exactly
• US Survey Feet: 1 ft = 0.3048006096 m (slightly different)

Geodetic Transformations

When changing datums (e.g., WGS84 to NAD83):

• This is not a simple coordinate conversion
• Requires geodetic transformation parameters
• Viizor uses pyproj (PROJ library) with official transformation grids

Ellipsoidal vs Orthometric Height

• Ellipsoidal: Height above the mathematical ellipsoid (WGS84, GRS80)
• Orthometric: Height above the geoid (mean sea level)
• Geoid Undulation (N): Varies globally from -20m to +80m

Viizor can query the GEOID18 model (NOAA) to obtain N values for locations in the United States.

Complete Workflow Example

Scenario: Drone survey over a construction site. You need to align the cloud to the topographer's GCPs and deliver in the client's required coordinate system.

Input Data

Drone point cloud: site_20241210.laz

• System: WGS84 UTM 17N (EPSG:32617)
• Units: Meters
• Height: Ellipsoidal

Surveyor's GCPs: control_points.csv

• System: NAD83(2011) State Plane SC (EPSG:6570)
• Units: US Survey Feet
• Height: Orthometric (NAVD88)

Workflow Steps

Troubleshooting

GCPs Appear Outside the Point Cloud

Probable cause: Incorrect EPSG code for the GCPs

Solutions:

1. Verify the actual EPSG of the GCPs (ask your surveyor)
2. Check units (meters vs feet)
3. If coordinates are large numbers (> 1000), they're not lat/lon (EPSG:4326)
4. Compare coordinate ranges—UTM Eastings are typically 166,000–834,000

RMSE Too High (> 50cm)

Probable causes:

1. Incorrect EPSG code
2. Observed points placed inaccurately in the cloud
3. Errors in the CSV file
4. Mixing orthometric and ellipsoidal heights

Solutions:

1. Verify EPSG for both cloud and GCPs
2. Zoom to each GCP and verify placement
3. Recalculate and review individual residuals
4. Remove GCPs with anomalously high errors
5. Verify height type selection

CRS Conversion Drastically Changes Position

Probable cause: Source CRS incorrectly detected

Solutions:

1. Verify the EPSG that Viizor detected
2. If incorrect, use the manual search
3. Compare with the original file's coordinates

Z Height Incorrect After Conversion

Probable cause: "Transform Z" not enabled

Solutions:

1. Re-convert with "Transform Z" checkbox enabled
2. Or apply geoid correction separately

Best Practices

1. Always verify EPSG before any transformation—this is the #1 source of errors
2. Document the coordinate system of each file in the filename or metadata
3. Use 5+ GCPs distributed evenly across the site
4. Review individual residuals before accepting an alignment
5. Keep original files—transformations always generate new files
6. Verify units especially with US data (feet vs meters)
7. Check heights when combining data from different sources
8. Test with known points after transformation to verify accuracy

Technical Specifications

Alignment Algorithm

Component	Specification
Method	7-parameter Helmert transformation
Rotation algorithm	Kabsch (SVD-based)
Library	NumPy + SciPy
Precision	Float64 (double precision)

Coordinate Conversion

Component	Specification
Library	pyproj (PROJ 9.x)
Database	Official EPSG database
Transformations	Includes datum shift grids when available

Supported Formats

Type	Formats
Input	LAS 1.2-1.4, LAZ
Output	LAS (same version as input), LAZ if input was LAZ
Metadata	VLRs preserved (except COPC structure, which is regenerated)
GCP import	CSV, TXT (auto-detected delimiter)